Ross asked: > on a typical Linux server, if you just do an rsync of the entire > drive at 2 AM, and the live hard drive bites the dust next day, if > you restore the dead drive from the rsync'd backup: > > a) What sort of things are not going to just magically work, and > b) What sort of things are going to possibly have data loss because > the drive was not read-only when rsync'd?
In general, I'd recommend only doing backups of data (e.g., /home) versus backups of the entire system (e.g., / or /dev). The backup system needs to have the OS installed anyway, so why copy it wholesale from the primary? With this model, when the primary goes down hard, you've got a (relatively recent) copy of the data and your backup is already running, so it's probably just a matter of switching a few configuration files (IP address, maybe?) and starting the appropriate services. Voila, you're in business. Thus, (A) becomes an issue about whether corrupt data files will trash an application, rather than whether some weird device file in /dev works. And that leads into (B). Dumping a database to an SQL file is definitely better than rsyncing the live data files, so you should be covered there. Better still, use replication (MySQL is cake to setup, and I assume Postgres is as well) so if the primary dies, you've got a copy on the backup that's up-to-date within seconds. If you use a maildir-enabled MTA, there aren't any worries about losing e-mail messages because they're written to disk in the "tmp" directory and only after a successful write are they moved into "new". Moving a file isn't a data-corruption risk. Thus, rsync-ing a maildir area will be fine. AFAIK, using rsync on the backup won't cause any serious issues with applications when you bring it up as the primary. I'd restart the apps, just to be sure-- better yet, leave them inactive *until* you need them. For example, if you're running a web server, keep Apache off on the backup and when you do the switch, start it. That way you're sure you're getting all the latest configuration information (remember to copy your httpd.conf file as part of the sync!). I've used rsync on paired production servers for years and when things go haywire (fortunately very rarely) I've never had trouble bringing up the backup and getting back online in a matter of minutes. YMMV, Jeff
pgpPdM2A6Np6U.pgp
Description: PGP signature
/* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
