Subject: Re: Removing GNU tar and GNU cpio from src?
To: NetBSD Userlevel Technical Discussion List <tech-userlevel@netbsd.org>
From: Greg A. Woods <woods@weird.com>
List: tech-userlevel
Date: 01/26/2003 22:02:30
[ On Sunday, January 26, 2003 at 21:44:07 (-0500), der Mouse wrote: ]
> Subject: Re: Removing GNU tar and GNU cpio from src?
>
> > On NetBSD Amanda does just fine with proper 'dump' backups which of
> > course face none of these silly issues because 'dump' is a proper
> > backup program.
>
> Including the locking you were talking about? I doubt it.
Locking? What locking? I wasn't talking about locking per se, but
rather about noticing or avoiding events which almost certainly
guarantee that what went into the archive will not match what is (now)
on the disk. Note that there's no way possible for the archive program
to know where in the file the data on disk was modified, or of course
what impact such modifications might have on the integrity of the
archive as a whole.
To do a safe backup you run 'dump' in single user mode (or some near
equivalent), or with the source filesystem unmounted. If you don't then
you get the very same "best effort" that everyone but me seems to be so
fond of. If you use 'dump' for your backups then you should already
know that you cannot possibly get high-integrity backups if you try to
dump a live filesystem.
> 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....
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, 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.
--
Greg A. Woods
+1 416 218-0098; <g.a.woods@ieee.org>; <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>