> To do a safe backup you run 'dump' in single user mode (or some near
> equivalent), or with the source filesystem unmounted.

Yes, but then, you can equally well use tar, or pax, or cpio, or any of
tons of other programs.

>> Try the Zwicky tests on it.  I expect it to do far worse than my tar.
> That's pretty much impossible, at least with FFS, unless perhaps
> you've invented some new (and almost certainly incompatible) archive
> format....

I extend tar format slightly, to support arbitrarily long names; I
invented a different extension to support sparse files.  (I considered
using the GNU tar format extensions, but I couldn't find any doc on
them other than the source, and the source was too convoluted and
poorly documented to figure out the extensions from it.)  Between the
two of them, plus the direct-disk-reading code, I believe it's a
serious contender.  At least one large (for a university) site I know
of used it for their backups, and quite possibly still does.  (Live
backups, too; its "best effort" both is usually quite good and tells
you when it fails, at least if you ask it to.)

> Zwicky's original test results already show that none of the
> implementations of 'tar' or 'cpio' or 'pax' that were tested can even
> come close to producing backups as good as those any true
> implementation of 'dump' can,

Not that dump did that well either, running into length limits too
soon.  And I have on other systems had dump and restore end up
appending junk to file names; I have no idea what bug was behind that,
or whether it's present in any other dump variant, but it makes me
extremely leery of trusting dump to DTRT.

It's been a few years and a handful of changes since I last ran the
Zwicky tests on my tar.  (I don't have perl installed, and I don't care
enough about the Zwicky tests to install perl just for that.)  But at
the time, with a suitable mix of options, it did as well as possible -
it passed all the static tests, and the dynamic tests it failed on it
failed in reasonable ways and with reasonably descriptive messages.

> and given the failures demonstrated by those tests it's pretty
> obvious that the fundamental flaws are in their archive formats,
> something inherently solved by 'dump' and 'dump' alone.

...or my tar.  Or probably others; I know there are a number of
commercial backup suites with private formats out there, and it would
surprise me if none of them had archive formats that dealt with this
issue.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B