Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Jul 2002 13:07:31 -0700
From:      Daniel Brown <djb@unixan.com>
To:        freebsd-stable@FreeBSD.ORG
Cc:        Mattias Pantzare <pantzer@ludd.luth.se>, jackstone@sage-one.net
Subject:   Re: Poor Mans Software raid 1 on root partition?
Message-ID:  <20020716130731.73e01b80.djb@unixan.com>
In-Reply-To: <20020716190324.GA1042@skalman.campus.luth.se>
References:  <20020715225138.V82789-100000@mail.allcaps.org> <3.0.5.32.20020716083905.0117a758@mail.sage-one.net> <20020716190324.GA1042@skalman.campus.luth.se>

next in thread | previous in thread | raw e-mail | index | archive | help
Wrote Mattias Pantzare:

> > seems to be on the "backup" and very little on the restore -- and I'm
> > speaking more from the disaster recovery -- to get back up and running
> > within minutes. In raising the question about that, I have noticed few have
> > ever "tested" any sort of backup plans to see if they really can restore,
> > or how quickly they can restore.
> > 
> > I for one would sure like to hear more about recovery plans..... mine is to
> > use two identical HDs on each server and run DD frequently, with tars for
> > incremental. Thus, I have found it very simple to shut down, pull the bad
> > HD, move HD #2 up and re cable it -- then boot and voila! I'm back up.
> > THEN, add back any incremental while running in the meantime....
> 
> What will hapen if the HD crashes while you are copying it? You can end 
> upp with bad content in files without you knowing it.
> 
> rsync is probably better than dd.

Indeed, 'dd' also has the problem of copying a live filesystem whose
metadata may change right under you.  It is best to simply partition
your second drive the same way (you can, in fact, pipe the 'disklabel'
output of one drive into the 'disklabel -R -B /dev/stdin' for an
identical drive), add appropriate /etc/fstab entries, then do periodic
software updates.

However, rsync is a VERY poor choice for backing up an entire
filesystem; as it loads a "worklist" in memory prior to making its
moves, it becomes very memory and CPU intensive.  This is both slow
and annoyingly affects response time for services on the machine.

Try mirrordir (good, has problems with socket nodes, not found in
ports), ssync (ok, but doesn't do devices/etc), pax -rw (ok, but
doesn't delete removed files), or rdiff-backup (nice, but hardlinks
not respected, not found in ports, never tried it on FreeBSD).  Or
search for other similar tools -- keep an eye for low resources use,
incremental updates, and few/no problems with "special" filetypes.

If you go with mirrordir (the sockets problem is inconsequential as
unix-domain sockets need to be deleted before listening on them
anyways), you need to --exclude both your destination directory as
well as any filesystem (like /proc) that you don't want backed up,
then re-create those mount points afterwards.  For instance, assuming
/backup is where your mirror drive is:

/usr/local/bin/mirrordir --exclude /backup --exclude /proc / /backup
mkdir /backup/backup
mkdir /backup/proc

If you want to keep a log of what it is copying, add --verbose and
direct the stdout appropriately.

I've used this solution on numerous production machines, and it works
out the best of every similar solution I've run into in the past 2
years.

      -Daniel

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020716130731.73e01b80.djb>