Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!rdin!perl
From: perl@rdin.UUCP (Robert Perlberg)
Newsgroups: net.unix-wizards
Subject: How do I restor a set of incremental dumps?
Message-ID: <341@rdin.UUCP>
Date: Sat, 21-Jan-84 08:10:06 EST
Article-I.D.: rdin.341
Posted: Sat Jan 21 08:10:06 1984
Date-Received: Sun, 15-Jan-84 02:46:11 EST
Lines: 35

I had the unpleasant task recently of restoring a system
from a set of incremental dumps.  On each file system, the
level 0 dump restored cleanly (no fsck errors).  However,
each of the following dumps caused fsck to run amok!  Files
were deleted and relegated to lost+found by the hundreds!
There was nothing wrong with the dumps.  Files that were
discovered missing were capable of being restored
individually.  There was also a great deal of directory
corruption.  Lots of files showed up in the wrong
directories under the wrong names.  Whole directories
disappeared.

My question is: is this an isolated case?  My experience
with and knowledge of dump and restor tells me that the
system simply cannot work any better because of how it was
designed.  When restoring a filesystem (restor r) the inodes
stored on the tape are loaded back into the same inodes on
the disk.  This is a ridiculous way to restore files!  What
if there is already a file in that inode?  Of course, the
reason for this is to maintain the validity of directories.
But that's just as ridiculous; and it doesn't work anyway!
Why doesn't restor just create empty directories where
necessary and update them as it restores files?

Surely I am not the first to run into this situation.  The
manual explicitly states that a filesystem can be restored
from incremental dumps.  Can anybody shed some light on this
problem for me?  I hate to think that all of the incremental
dumps I make every day will be worthless in the event of
another system crash.

Robert Perlberg
Resource Dynamics Inc.
New York
philabs!rdin!rdin2!perl