> dump:  If you're doing a dump of a live filesystem, it's quite
> possible to produce an unusable dump.

This is simply a bug in dump, and should be fixed or (insistently)
reported to the relevant vendor, as the case may be.

Not that this helps you in the very-short term, unless the host you're
backing up is one for which you have source to dump (eg, NetBSD) and
you're (a) competent and (b) willing to fix it.

> gtar:  A friend who wrote a tar clone told me that the tar standard
> isn't really very standard; I don't know exactly what this means, but
> I do know he was working off the POSIX tar stuff.

I wrote a tar clone too, and my format spec was a BSD manpage.  I have
been unable to lay my hands on any newer tarfile format spec.

But I can tell you that there is a lot of variation in what various
tars generate.  Mine is (by defualt) quite strict about header format,
including things like spaces versus NULs as terminators, and I often
have to use the option to suppress that when unpacking tars from
elsewhere.

> Tar can also be slow.

Doing things in filesystem-walk order is like that.

> Tar changes the atime on files, so users show up as having read their
> email at the last backup time.

GNU tar has an option that tries to avoid this, by using utimes() on
files after reading them, but this has a race with *real* accesses and
also changes ctimes.  My tar has code to read files by going directly
to disk, below the filesystem, as dump does, but doesn't do
incrementals quite as thoroughly as GNU tar does.

> Really, I'm not sure that there is a good way to backup a live
> filesystem.  You want a tool that operates below the filesystem
> level, but which is immune to (or at least compensates for) changes
> to the filesystem that occur while it's running.  I'm not going to
> claim to know how to do this.

Me neither, mostly...but my tar comes as close as I think is possible
to passing the Zwicky backup-program torture tests, which is the
nastiest test suite for backup software I've seen.  I know of a site
using it as the workhorse of their routine backups, so *someone* is
fairly confident (and I don't even work there!).

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B