/u/guests/jc/Mail/inbox/406
From discuss-bounces@blu.org Wed Nov 14 11:12:30 2007
Date: Wed, 14 Nov 2007 11:06:15 -0500
From: Kent Borg <kentborg@borg.org>
To: discuss@blu.org
Subject: Re: untested backups
X-Spam-Score: -0.0 (/)

I am a big fan of rsync's "--link-dest" feature.  It allows one to do a
backup that is both incremental and full.

You give rsync the source location, the destination, and the link-dest.
For an "incremental" backup the link-dest would point to the previous
backup.  If rsync would normally create a new file in the destination if
it is identical to the corresponding file in the previous backup, it
instead creates a hard link to the file.  You now can have two (or more)
hard links to the same file.  Old backups can be deleted, but the file
will remain for as long as the last hard link to it exists.

So you can have a whole series of backups, each "complete", but with
only a single copy of common files (from sequential backups).  This will
take directory space, you might want to tune your file system creation
appropriately.

Also, on the subject of speed to restore, I am a big fan of a mountable
file system.  Presto, your data can be available with no copying of
data.  Just access the data you want.

All very cool.  In fact it is so cool it seems Apple is using something
very much like it for their new "time machine" backup feature.

Finally, because it is a disk file system, each new backup is a test
that the previous backups are (at least somewhat) functional.

At a previous job I set up the server with auto-rotating, same-disk (but
different partition) backups, on top of software raid 1.  That was my
version time-machine, to save people from mistakes and provide some
hardware protection (raid 1 will catch them in a disk failure, but not
flood, theft, lightning, etc.).

Then, a pair of external disks were used as alternating, encrypted,
offsite backups of that.

My specific design was only suitable for a fairly small system, mostly
because rsync doesn't scale up that gracefully, though backing up more
frequently (and so biting off smaller chunks) helps.  And I didn't do
anything special for backing up databases (there was no SQL beast there)
nor being certain the backup was self-consistent--data that is changing
during the backup can be "smeared", a snapshot feature (a la LVM) would
help there.  I ran it after hours to minimize the problem.  Understand
your data.

-kb

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss