> On 6-Aug-2009, at 10:22, Richard Peacock wrote: >> What would be the best way to perform a full Apache backup and MySQL (I >> know it's not exactly related and understand if you can't make any suggestions for this)? > > /usr/local/bin/rsync -aCHh --stats --delete-after --delete-excluded \ > --exclude="/backup/" --exclude-from=/var/.rexcludes \ > --link-dest="${BAKLOC}.day.1" / ${BAKLOC}.day.0 > > Backups my entire system. Danger, Will Robinson! Pardon me while I nag, but... You have to be careful using filesystem copy commands with any database management system because you can easily wind up with a corrupted backup. That's particularly true if you can't control when writes happen to the system. You might be able to get it in a usable state by doing some table repairs, but then you might not. Also, if you should lose the box completely and have to install to a slightly different configuration, you're toast. MySQL files are not highly portable. So unless you're absolutely sure the database isn't being written to, you go into the database and flush the buffers, and you have a "hot spare" that is identical hardware and software ready to spin up with the rsync output, this approach may break your heart someday. The bare-bones mysql backup solution is mysqldump. It locks the database and dumps out a text file of SQL statements that are required to rebuild the database. You can transfer the file to another version of MySQL and load it up without much problem (although you should do a mysql upgrade if going up a version and there are extra flags to put on the mysqldump command if you want to be able to go to an older version. Mysqlhotcopy can be used as well in some situations but I'd just stick to mysqldump because it works for MyISAM and INNODB. Even better, get zrm backup (zmanda.com -- there's a free "community" version). Zrm is basically a wrapper for mysqldump/mysqlhotcopy. But it will autodetect when you are trying to us mysqlhotcopy when you can only use mysqldump, and it will "rotate out" backups for you (expire after a week, that sort of thing). If you've got a few bucks, spring for the enterprise solution. It's a pain to set up (I just did a couple of installations) because I had to figure out host-based ssh configuration which I hadn't used before (I always use public keys) but it has a GUI that's pretty sweet. And if you have binary logging turned on in your database configuration so that transactions are logged to disk, you can do "point in time" recovery instead of just reverting to the last time you did a mysqldump. This is true whether you do mysqldump manually or use zrm. You'll have to copy the binary logs somewhere as well (zrm will do it automatically). A "point in time" backup can be done with standard command line mysql tools, but zrm makes it easier. And for pity's sake, at minimum back up to a separate machine over the network (you can use both mysqldump and rsync this way if the two machines are configured for it), write to a DVD, etc. and keep off-site backups as well. Plus, test your backup methods occasionally with a recovery to be sure that you have it right and you don't have to figure out syntax under pressure. Document with a cheat sheet. The documentation on dev.mysql.com will tell you how to run mysqldump. Regards, Sheryl --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx