SUMMARY: Backup while in multi-user mode

[Richard Todd]

peter at ficc.ferranti.com (Peter da Silva) writes:

>What I don't understand is why people are still using "dump" to do backups?
>A pretty minimal script using "find -newer level-file" and "cpio" works just
>fine on active file systems.

1. "dump" preserves the access times on files, and "restore" restores the
files with the access times set correctly.  "cpio" neither records the access
times in its archive nor leaves the access times of the files on disk 
unaffected.  Thus, "cpio" screws up any schemes one may have for locating 
user files that haven't been accessed in, say, 6 months and automatically
moving them off to tape and deleting them.  

2.  "dump" handles files with holes in them correctly (the holes don't take
up space on the backup, and "restore" restores the files with holes correctly).
"cpio" doesn't.  Having all your dbm files suddenly explode in disk usage 
after having been brought back off of tape is considered bad form in some
circles...

3.  Just how were you planning to do restores of those incremental backups?
Seems to me that the naive approach (extracting the incremental cpio just
like the full cpio backups) won't work correctly on directories which have
had files deleted between the making of the full and the incremental
backup.  Say you've got a directory "foo", which had files "a","b", and "c"
in it at the time of the full backup, but between that backup and the
incremental someone deleted files "a" and "b".  In restoring the filesystem
after the crash, you read in the level-0 cpio backup, which puts "foo/a",
"foo/b", and "foo/c" on the disk.  Now you read in the incremental cpio
backup, which (because "foo" had files deleted, shows up with a newer mod
time than the level-0, and thus gets backed up) has the "foo" directory and
"foo/c" on it, and thus foo/c gets written to your disk--but "foo/a" and 
"foo/b" are not deleted.  You have not restored the filesystem to its state 
as of the time of the incremental backup.  This means that you need to do 
some extra work to make sure that all the stuff you got rid of once gets 
gotten rid of again.  (Note that if you're really unlucky, and had a lot of
old stuff deleted and new stuff added between the full and incr. backups, 
restoring the incremental cpio file will fill your disk.)  This just adds
to the hassle a sysadmin has to deal with when restoring a filesystem, when 
usually the sysadmin has entirely too much to deal with anyway...

  Basically, there's a subtle difference between the goal of "dump" and 
"cpio".  "Dump" is a *backup* program; its function is to save the state of
a filesystem in such a way that it can be restored exactly later.  "Cpio" is
an archiving program; like "tar" or "zoo", its function is to package up a
bunch of files in a halfway portable fashion so that they can be transported
about easily from one place to another, from one system to another.  You can
try to press "cpio" or "tar" into service as a backup program, but it's 
not really the same thing...
--
Richard Todd	rmtodd at uokmax.ecn.uoknor.edu  rmtodd at chinet.chi.il.us
	rmtodd at servalan.uucp