Raid 5 (was: Mounting of Linux volumes)
jeff at neobox.net
Fri Dec 2 11:13:13 MST 2005
> 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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://plug.org/pipermail/plug/attachments/20051202/433434de/attachment.bin
More information about the PLUG