From: utzoo!decvax!decwrl!sun!megatest!fortune!hpda!hplabs!hao!seismo!rocheste!ritcv!kar
Newsgroups: net.unix-wizards
Title: Flames on system backups
Article-I.D.: ritcv.273
Posted: Sun Apr 10 17:23:09 1983
Received: Wed Apr 13 22:04:24 1983


Regarding a recent submission about how neither dump nor tar were suitable as
a means of backing up a system with lots of file systems.  The objections below
are quoted from the original article.

	"dump does not allow multiple filesystems on a tape."
We dump several filesystems to a single tape when we know that each of the
dumps is going to be short (i.e. they'll all fit).  Restoring was a problem
until we made the simple addition of the F option, which specifies which file
on a reel contains the dump.  This has been described in a previous submission.

	"dump does not recognize end of tape."
On our old V7 and 4.1bsd, our problem was not using the last several
hundred feet of tape rather than running out.  Dump is very conservative about
its estimated tape usage; if you are running off of the end of the reel, your
tape drive might be writing long interrecord gaps, or something like that.

	I fixed this on V7, but have not cared to mess with it on our 4.1bsd
system.  The naive approach involves changing the tape driver, and having it
return an explicit error code when the end of tape marker is sensed. 
Curiously, the hooks for doing this are all there; there is a field in the
buffer header for an error code that, if not filled in with something specific
by the driver, gets loaded with a generic error number by (I think) the buffer
manager.

	Unfortunately, this does not work for "dump".  The error code, strictly
speaking, should be returned for the first write AFTER the marker goes by,
as the previous one was actually written properly.  Dump, however, needs to
know whether it will be possible to write another block just AFTER it finishes
writing the previous one, so it can decide whether to continue writing out
files or to write the updated bit maps.  One could have the end of tape error
code returned on the write that passes the marker, but then the error code
isn't really an error.  We put in an ioctl instead that returned the status
of the drive (which, by the way, must settle down first).  Then dump can
determine (without actually trying it) whether another attempt to write will
succeed.

	"restorations on dump are painful."
The use of "dumpdir" has been discussed in previous followups, and, with a
little good old-fashioned hacking, can be at least partially automated.

	"Dumps documentation, to put it lightly, easts it."
No comment.

	"Dump also returns with non-standard exit codes."
Yes, and it played hob with one of my programs (described below) until I
fixed it.  I used to know what the number meant; I think it is number of file-
systems actually dumped, but I'm not sure.

--------

	A while back, in an effort to automate our filesave procedures, I wrote
a program called "save", which reads a table describing when various types of
dumps are to be made on assorted file systems.  I also modified "dump" and
"restor" to write a label on each tape, including multi-reel sets.

	What we do now is to run "save".  It scans its file and figures out
(based on the day of the week) which filesystems are to be dumped and what
tape sets are to be used.  It prompts the operator to mount the proper tape
and waits for a response.  Dump then checks the label on the tape and gives
the bozo another chance if s/he mounted the wrong one.

	The table we use (redundancy edited out) is shown below:

set v1root-m 3 2
set v1usr-m 3 0 v1root-m
set v1acct-m 3 0 v1root-m
set v1acct-w 4 0
work 1 mon, reset v1acct-w, dump v1root-m root b, dump v1usr-m usr 0, dump v1acct-m acct 0
work mon, dump v1acct-w acct 1 root 0 usr 1

	The "set" lines identify tape sets that are used for dumps.  For exam-
ple, the first line says that there are three "v1root-m" tapes, which are
labelled "v1root-m1", "v1root-m2", and "v1root-m3".  The next time a dump is
taken on one of these, number two should be used.  The second line identifies
another set of tapes, whose numbering should match the numbering on "v1root-m".

	The "work" lines identify work to be done on various days of the week.
The first one says that on the 1st Monday of the month, reset the counter for
tape set "v1acct-w", then dump "/dev/root" on the next "v1root-m" tape in
self-booting format, dump "/dev/usr" at level 0 on the next "v1usr-m" tape set,
etc.  The second "work" line says that on all other Mondays, the devices
"/dev/acct", "/dev/root", "/dev/usr" are all to be dumped on the next tape in
the "v1acct-w" set, at level 1, 0, and 1 respectively.

	By now, you get the idea.  I wrote this a long time ago, and have not
done anything much to it since, so I don't want any flames about my code;
nevertheless, I am willing to post the source if there is any interest.