Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!micomvax!onfcanim!dave
From: dave@onfcanim.UUCP (Dave Martindale)
Newsgroups: net.unix-wizards
Subject: Re: 4.2BSD restore(8)
Message-ID: <14839@onfcanim.UUCP>
Date: Fri, 2-May-86 00:35:35 EDT
Article-I.D.: onfcanim.14839
Posted: Fri May  2 00:35:35 1986
Date-Received: Sat, 3-May-86 03:02:53 EDT
References: <2066@hao.UUCP> <27300009@convex>
Reply-To: dave@onfcanim.UUCP (Dave Martindale)
Organization: ONF, Montreal
Lines: 63

In article <27300009@convex> berliner@convex.UUCP writes:
>
>/* Written by ed@mtxinu.UUCP in convex:net.unix-wizards */
>> THIS IS BOTH INCORRECT AND DANGEROUS!  It was unnecessary with
>> pre-4.2 versions of dump/restor.  With 4.2 and later versions
>> of dump/restore, it will cause incrementals made after the edit
>> to be *nearly useless* if a full restore is required at a later time.
>> 
>> Read the man pages for dump and restore for more details (or see the
>> response I posted when the original request came through).
>> 
>> DON'T just change /etc/dumpdates!
>
>If this is indeed true, you can easily fake it as follows (for dumping the
>/xxx filesystem after completely restoring it from dump tapes):
>
>	/etc/dump 0usf 30000 /dev/null /xxx >& /dev/null &
>
>This will do an effective level 0 dump and update the /etc/dumpdates file
>accordingly.  You also won't be prompted to mount tape 2 ...

No, dammit, you can't do this either.  The whole point is this: some of
the information on a dump tape is relative to inode number.  When you
restore an incremental dump over a lower-level dump, it has to delete
files that have been removed and relink things that have changed names,
not just extract new files. 

When you did a restore under non-4.[23] versions of UNIX, you get back
all files to exactly the same inode number they were before - the I-list
is the same so you don't need to do a new dump.  Handling deleted files
or link changes required almost zero work - restore just read a bit map
of inodes to clear, and rewrote all changed inodes and directories, and
presto! everything was consistent. 

With 4.2, you get an *entirely new* I-list, since all of the files'
inodes are allocated from scratch, rather than put back where they were.
And any incremental dumps you do from the new filesystem reflect this
new I-list. 

With the 4.2 restore, keeping things consistent requires a lot of work
figuring out the names of things that need to be deleted or moved or
whatever.  Restore keeps track of what is where by keeping around a
symbol table, indexed by inode number, between passes of restore -
that's what "restoresymtable" is, in case you hadn't guessed. 

If you restore from a fullsave tape, and then try loading an incremental
dump on top of it *that wasn't made relative to the fullsave you used*,
chaos will result, because the I-lists do not correspond.

The fudge suggested above will do nothing more than update /etc/dumpdates,
and that isn't good enough.  When you restore a 4.2BSD filesystem,
you *must* do a new level 0 dump onto tape, in order to have something
for you later incremental dumps to be relative to.  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?

	Dave Martindale