Best way to upgrade and backup a site in constant use?

[mr_nabo]

Hi,

Because I mainly work with PHP and MySQL-based CMSs like Joomla, (soon Drupal) and Concrete5, I've posted this here (let me know if there's a better place).

I've only ever had to backup sites that I can backup whenever because the users can stop using the site when I need. However, what happens when people are constantly using the site? Is there a best practice for backing up and upgrading sites like that? Is it just a matter of saying 'site down for upgrades' while you reinstate a copy of the site you've upgraded locally?

I've heard SVN mentioned a few times, but it looks very complicated.

Any ideas?

Thanks

[jatar_k]

SVN or CVS is to manage your source, to maintain versions, it doesn't really backup

preferably we don't close sites ever, backing up or not

you can back up mysql using mysqldump
you can backup files just by zipping the whole thing, though really you should have an active copy and a development copy (if needed) on some other machine as you don't, or shouldn't, do your work on live pages.

upgradiong, well that depends on how much you are changing and what they do. Most sites can be just copied via ftp, look upgraded.

If you have real software up there that needs upgrading then you would shut it down in your lowest traffic times and have a plan for upgrading and recovery, if it fails, and if you have users you would need to advise them ahead of time of the planned outage.

[mr_nabo]

Hi Jatar,

Ok, that makes sense. With SVN, presumably you would use it to upgrade a live site once you've got it upgraded and working properly locally right? I thought the benefit of SVN was to have a quick way to revert back to a previous version quickly or compare differences between code?

Sorry, SVN is a new concept to me and seems to involve a lot of command line processes.

Thanks

[jatar_k]

SVN/CVS are version tracking so if you had a release version which had been tested and QA'ed and was shiny and new and ready for the world to see you would tag your repository with the current version. for example MYSOFTWARE-1_0

you could then use the tag MYSOFTWARE-1_0 to checkout all of the code at that point in time and continue development on the same files. At some point you will find that your code has gained a new luster and your site seems dingy and dirty by comparison.

you then QA and test and tag it as MYSOFTWARE-1_1 and then check it out and copy it to your site.

if you have the unfortunate surprise that 1.1 wasn't as shiny as you thought, you can go back to CVS, check out at the 1.0 tag which was the last stable and copy that back to the site and then spend some more time polishing 1.1, possibly creating 1.1.1 when you work out the bugs.

then there is branching and merging but the basics are covered above

<added>CVS is no replacement for good habits and comunication, I have spent a significant portion of my dev life cleaning up CVS repositories after lazy, communication deficient programmers. All it does is tell you where you screwed up (you still have to fix it) and allow you to monitor versions (if you tag correctly).

[CyBerAliEn]

When it comes to handling the source code on your end... SVN/CVS are very helpful. Though they're usually only "necessary" (practical/etc) when you're working on a larger project or working with multiple developers. It just makes managing the source code (via versions) easier. This can be expanded to handling major site upgrades by using it to "deploy" the newest/greatest/stable/tested/etc version of the source code to the public site.


My preference/style on development is like so:

You have two "machines" (could be shared/virtual, could be 2 physically independent servers, could be 2 independent groups of servers, etc; depends on the situation).

"Machine 1" = public/production/live site. This is what your public/users access and interact with. It should always be loaded with stable/tested code.

"Machine 2" = development/private/test site. This is where your "code in development" is worked on. This way, changes and updates can occur with testing without affecting the public use of the site. The DEV site/server could simply be a single "source" of code, ie: the source files, that you change, upload, test, etc. Or: you could employ SVN/CVS on the DEV site to handle versions/etc.

The idea primarily being: You make changes and develop things on the DEV site. Once things are fixed and ready for public, you "launch" them to the public site. This keeps the updating relatively seamless.

The mechanism through which you do this depends on your needs/expertise. You could simply "copy/paste" the DEV source files to the public site once you reach a stable version. You could perform a sync between the sites so public matches the current/stable DEV source files. All in all, these methods are pretty good for making basic changes, updates, additions, etc to files/pages/etc.

However... if you are launching a HUGE update of an important site that requires major changes and is actively engaged by the public, you could consider this idea: deploy a new server(s) loaded with the new site/version. Through a method of choice, simply flip/route requests for the site from the old server to the new server. As far as the user is concerned, it would be instantaneous. This is a useful practice when you consider a site where multiple+ files across a site are required by the user (ie: imagine a page/software that requires tons of PHP includes, classes, etc from all over the place; updating the site via a basic copy/paste method could more easily create "anomalies" if there is a HUGE change in the site). Note that this method shouldn't be readily taken; it requires the extra expense of a new server and the network/server expertise to route the traffic.


These are my experiences in upgrading sites, small and large.


EDIT: The above primarily notes handling launching/updating the site (in a large scale situation with lots of activity). When it comes to backing up a site... your file structure SHOULD be constant. And if you employ a strategy like the above, you should always inherently possess a "copy" (backup) of the source code files. This really only leaves backing up the database. As noted by other poster, the best means for backing up the database would be to do a mySQL dump (mySQL offers this tool for you). It will dump out SQL code to regenerate your tables/structure and to populate the databases/tables with data. Many other popular databases provide similar support.

[tangor]

Upgrades are one thing... backing up is just that. I dump site modified (activity) files to an offsite machine. Keeps it short and sweet. Depending on the size/activity of the site I might do it once a week, once a day, or once every 12 hours. These are "incremental" as the underlying site has not changed... and that's already on my backup and dev machines (too).

Belt and suspenders kind of guy... but I don't heavy lift anything that hasn't changed!