4.2BSD restore(8)

[berliner at convex.UUCP]

/* Written 11:35 pm  May  1, 1986 by dave at onfcanim.UUCP in net.unix-wizards */
> ...  If you fudge the
> dump date, you will get incremental dumps that contain changed files
> and can be used for "restore x", but they cannot be used for "restore r".
>
> So, if you want to be able to use "restore r" to fully restore a filesystem
> after a hardware failure, you *absolutely must* write that new level 0
> tape, no matter how long it takes.  If you're satisfied with only being
> able to use "restore x", why not just use tar instead of dump in the
> first place?

Ah, now I see.  So all this trauma over the need to make level 0 dumps after
a full filesystem restore only applies to the "restore r" operation and not
the the "restore x" (or "restore i" for that matter) operation!  With
4.2BSD, there is (in my opinion) virtually no need to do "restore r" to
restore a file system -- I just run newfs and do "restore x".  Yes, I get a
new I-list, but who cares.  The end result is the same, is it not?

I *am* satisfied using "restore x" and "restore i".  I have never found it
beneficial (on 4.[23] systems) to do a "restore r".  Why don't I use tar?

	o  dump will let me write to multiple tapes
	o  dump runs *much* faster than tar -- especially if you use a
	   hacked-up dumptape.c module posted to net.sources a long time ago.
	o  dump keeps a "symbol table" at the front of the first tape; this
	   makes the "restore i" extremely nice.
	o  "restore i" let's me move around the directory hierarchy and
	   selectively extract files of my choosing.  It also tells me the
	   inode number, so that I can find (immediately) which tape to load
	   for a multi-tape dump.

I do use tar, but not to backup filesystems daily.  Thanks for filling us
all in on the "restore r" operation and the need to do level 0 dumps to keep
everything in-sync -- I will remember it in the future...

Brian Berliner
Convex Computer Corp.
{ihnp4, uiucdcs, sun, rice, allegra}!convex!berliner