> 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-unsubscr...@httpd.apache.org
" from the digest: users-digest-unsubscr...@httpd.apache.org
For additional commands, e-mail: users-h...@httpd.apache.org
