I recently implemented a new backup strategy for my production and development websites (ie: this site and the development server I run at home), and thought I'd share it here. I have multiple things I need to back up, including the actual files sitting on the webserver and data contained within the databases I use on a regular basis. I use two database servers - one on the staticred.net host, which contains two databases used for this website (and others on this domain), and one on my development server, which contains several databases for different projects. I'm paranoid about data loss, especially since I have over 6 years' worth of posts from the blog (and its predecessor) on this site.
Database Backup
On both the production and development servers, I created the following script file to create a dated backup of the database (the following is from the development server; the production server has minor differences):
#!/bin/bash
TIMESTAMP=`date +%m-%d-%y-%H%M`cd /storage/mysqlbackup/
find /storage/mysqlbackup/*.tar.gz -mtime +7 -exec rm -f {} +;
mysqldump --user=******* --password=******* --all-databases > /storage/mysqlbackup/devboxmysql.dump
tar czpf devbox.mysql.$TIMESTAMP.tar.gz devboxmysql.dump
rm -f devboxmysql.dump
This script compresses the database dump, names the file according to the time the archive was created, then moves it to a separate drive (/storage). It also ensures that only 7 days are archived so that disk space does not get consumed too quickly. A cron entry is created to run the script nightly, so I have a daily snapshot of the database's contents. At worst, I will lose a day's worth of data should a catastrophic event occur.
After the databases have been archived, a separate cron job runs to rsync the backup directories on the development server with the production server, providing off-site backup of the data:
59 5 * * * rsync -e ssh -avzp --delete backupuser@staticred.net:/path/to/mysqlbackup/ /storage/mysqlbackup/staticred
As yet another paranoia-induced step induced by a recent (accidental) rewrite of my MySQL root permissions, I also do a hot copy of the mysql database files as a cron job with the following:
mysqlhotcopy --allowold --user=****** --password=******** mysql /storage/mysqlbackup/devbox/mysql_files
This way, should I screw up my permissions again (and let's pray that doesn't happen), I can simply shut down the server, copy over the backup and restart to get them back.
Web files backup
Next, I run an rsync to synchronize the web files between my production server and development server. RSync only copies over modified files, and as such saves a good chunk of bandwidth. The --delete parameter will also look at the destination directory (the backup) and delete anything that has been removed from the source (production server). It's handy, because if I rename or remove a file, it won't keep cluttering the backup -- it's a living mirror of the production server.
59 2 * * 1 rsync -e ssh -avzp --delete backupuser@staticred.net:/path/to/webfiles/ /storage/backup/staticred
Finally, I back up the development server's web files. This is really more of a paranoia step than anything, since I already back up my active projects through the use of subversion. I use the -au option for copy, since this will only copy over modified files (saving a little disk-access and processing time) I also only perform this operation on Monday, Wednesday, and Friday, since I already have the subversion archive:
59 1 * 1,3,5 * cp -au /var/www/* /storage/backup/www/
So, what's your backup strategy? - and if you don't have one, why not?