Backup of a live filesystem revisited

[Dave Curry]

We do both partial and full dumps of live file systems on a regular
basis, and have had no troubles.  The tricks:

	1. Nice yourself down as far as you can.  Like -20.

	2. Modify dump (most of the mods are in dumptraverse.c) to
	   skip any inode whose mtime or ctime is greater than
	   spcl.c_date (time of the dump).

The idea here is that you dump all files which have not changed since
the dump started.  If the file changes during the dump, it will not be
looked at, and thus the problems of removed or changed files (removed
files are the worst) go away.  You MUST make these mods to dump to get
away with this sort of thing; we found out real fast in testing that
dump (actually restore) tends to get real upset if files go away when
it thinks they should be there.

The most we've seen happen doing things this way is that when restoring
from a full dump you see a few "resync restore" messages.  But we have
never had a bad dump (non-restorable) in the 14 months or so that we've
been doing this.

NOTE: I'm not necessarily recommending this practice.  If we had our way
      we'd do dumps in single-user mode.  But shutting down 20 machines
      every morning for 30-minute partials and on weekends for 2- and
      3-hour fulls is not practical.

If you want the diffs (for 4.3BSD dump), send me mail... if I get enough
requests I'll post them.

--Dave Curry
Purdue University
Engineering Computer Network