Restoring incremental dumps - summary of responses

[Mark Callow]

There are a couple of incorrect facts in this list of woes with
dump/restor.

>	Doesn't really matter, does it, since Berkeley dump does use
>	the normal file system mechanisms.
4.2BSD dump still dumps the old way using inodes.  Therefore dumps must
still be done on quiescent file systems.  We actually do level 0
(monthly) and level 1 (weekly) dumps in single-user mode and do other
levels (daily) multi-user but early in the morning.

4.2BSD "restore" is a completely rewritten "restor".  The "e" was added
to emphasize the difference.  It operates through normal file system
operations.  This means that it can be used to move filesystems from
one partition to another even when the destination is smaller than
the source (provided of course that the data will fit!).  It has some
other nifty features too, such as being able to restore files into
a real filename instead of one named for the inode and having an
interactive mode where you can move through the hierarchy on the dump
tape like you move through a disk file system hierarchy.

	>> What is not explicit here is that you have to read in the
	>> incremental dump *immediately* after the full dump.  As
	>> Robert Perlberg (rdin2!perl) points out, dump/restor work by
	>> dumping and restoring files as inodes (i.e. identified by
	>> their inode number, not their file names).  Restoring an
	>> incremental dump tape will not overwrite an existing inode
	>> unless that inode was modified between the base dump and the
	>> incremental dump.  However, if you create some files (inodes)
	>> between reading the base tape and the incremental tape then
	>> one of these newly created files could easily use the same
	>> inode as some file that was created between the time of the
	>> base dump and the time of the incremental dump.

    >  What Tom isn't considering here is that a lot of mixing up of
    >  the filesystem can take place between dumps which would result
    >  in reassigning of inodes.
Come on now.  If inodes change then the information will be
recorded on the incremental dump tape.  The point is that if some
indoes change between the *restor* of the level 0 dump and the *restor*
of the incremental dump then the second restor operation doesn't
know about the changes and the result can be a mess.
-- 
>From the Tardis of Mark Callow
msc at qubix.UUCP,  decwrl!qubix!msc at Berkeley.ARPA
...{decvax,ucbvax,ihnp4}!decwrl!qubix!msc, ...{ittvax,amd70}!qubix!msc