[afnog] Good backup software

Phil Regnauld regnauld at x0.dk
Tue Nov 29 13:18:02 EAT 2005


On Tue, Nov 29, 2005 at 10:05:08AM +0000, Brian Candler wrote:
> 
> Did anybody mention dump -L yet?

	Apart from the fact that it's terribly slow...  it works ok.

> Looking at the Bacula docs: it looks like it can't rebuild a server unless
> you've taken special care to record some information by hand first. In fact
> you are supposed to burn a separate recovery CD-ROM for every machine you're
> backing up.

	In practice I've never needed it -- I just install a minimal OS and
	then restore from there.

> Furthermore, it can't rebuild a Windows box at all without some third-party
> software, or doing raw partition backups while the server is down.
> http://www.bacula.org/rel-manual/Disast_Recove_Using_Bacula.html#SECTION0004018000000000000000

	That's a bigger issue, same goes for backup of open files (common
	problem on Windows).  In practice it will be the same as for UNIX:
	reinstall, patch, restore.  With regards to the registry, the best
	is to take a nightly dump of that to a file then backing it up --
	bacula has support for pre- and post- jobs, both server and client side.

> So beware of this, and make sure you test recovery of a system completely,
> onto a fresh machine. The fact that Bacula says it successfully backed up a
> machine does not by itself mean that you could rebuild it if it fails.

	That goes for any backing system, eh :)

> I'd like to see backup software which records _all_ the information
> necessary to rebuild or clone a machine itself, so there's nothing you can
> forget. Once the machine has died, it's too late :-(

	That would be dd or dump, as you put it.

> I'd also like to see software which records crypto hashes of all files and
> uses them to avoid duplicates - so when you're backing up 100 machines with
> the same O/S, you don't get 100 copies of every file in the operating
> system...

	http://phk.freebsd.dk/Stow/	

	From the README:

Stow is a permanent file archiving facility, based on contents
addressable storage.

When you run stow(1) (the client program) on a directorytree, the
mtree(1) program is used to generate a table of contents.  The
output from mtree(1) contains all the meta-data about the files and
directories, size, modification-times, owners &c &c, just like when
you run ls -l,  but it also contains a cryptographic hash of the
contents of the files.

The mtree(1) output is sent to the stow_stevedore(1) (the server
program), which can reside on the same or on a different host.  The
stow_stevedore(1) will store the mtree(1) output and record its
existence in an index file, along with the name-tag given and a
timestamp.

The stow_stevedore(1) then parses the mtree(1) output and for each
file, it determines if it has already stowed a file with the same
cryptographic hash.  If another file with the same hash code exists
in the hold, we ignore the vanishing small chance that the files
are different and assume that we already have this file stowed.

[...]




More information about the afnog mailing list