Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site kobold.UUCP
Path: utzoo!linus!security!genrad!grkermit!masscomp!kobold!tjt
From: tjt@kobold.UUCP
Newsgroups: net.unix-wizards
Subject: Re: How do I restor a set of incremental dumps?
Message-ID: <258@kobold.UUCP>
Date: Sun, 15-Jan-84 16:32:15 EST
Article-I.D.: kobold.258
Posted: Sun Jan 15 16:32:15 1984
Date-Received: Wed, 18-Jan-84 06:21:15 EST
References: <341@rdin.UUCP>
Organization: Masscomp, Westford, MA
Lines: 79

Rest assured: it IS possible to restore a filesystem from incremental
dumps, although the manual is not explicit about various caveats that
must be observed.  Quoting from the 4.1BSD manual (I don't have a V7
manual handy, but I believe the V7, 4.1BSD and the System III manual
entries for restor(8) are fundamentally the same):

    The r option should only be used to restore a complete dump tape
    onto a clear file system or to restore an incremental dump tape
    onto this.  Thus

	/etc/mkfs /dev/rrp0g 145673
	restor r /dev/rrp0g

    is a typical sequence to restor a complete dump.  Another restor
    can be done to get an increment dump in on top of this.

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.

The manual also makes a reference to running "icheck -s" between tapes
of a multivolume dump if restor is interrupted.  The icheck program is
considerably less thorough than fsck and only performs what fsck calls
phases 1 (checking blocks in inodes), 1b (rescanning for duplicate
blocks) 5 (check free list) and 6 (rebuild free list).  The command
"icheck -s" is used to rebuild the free list, which is required since
restor allocates blocks for files from the file system free list but
doesn't update the super block until the entire restore is completed,
hence the requirement for running "icheck -s" IF the restor was
interrupted.

Curiously enough, icheck is *not* part of system III since for most
purposes, fsck is better.  In the absence of icheck (or an improved
fsck) you would have to answer no to all entreaties during phases 2
(check pathnames), 3 (check connectivity) or 4 (check reference counts)
to remove, reattach, clear or otherwise tamper with your inodes.
Of course, you should get no bad or duplicate blocks in phase 1, and
you will probably get a bad free list in phase 5 and should rebuild the
free list.

As to *why* restor works this way:

The list of inodes is a nice, contiguous array on the disk while
dumping files by name requires walking the directory tree.  If you
prefer, it is fairly easy to use find and cpio to perform incremental
dumps by name.  The advantage of dump/restor is that a standalone
version of restor is available in case you clobber your root file
system.   There is no inherent reason for not having a standalone
version of cpio, but I'm not aware of any.  Going through the file
system to do your dumps (e.g. using cpio) will have the side effect of
changing the "last accessed" time of the file.  Changing the "last
accessed" time back using the -a option of cpio has the possibly worse
side effect of changing the "last changed" time of the file.

In the past, various people have noted other problems with doing dumps
of an active file system which are consequences of dump avoiding the
normal file system mechanisms of opening and reading files.  In
particular, when unix's in-core inode is inconsistent with the inode on
the disk, it is possible to interpret ordinary file blocks as indirect
blocks (consider what happens if a file is deleted and one of its
former indirect blocks gets reallocated as an ordinary file block, and
the new file block gets written to the disk *before* the inode (now
empty) gets updated).  Since this is also a potential problem if the
system crashes, it should be fixed by modifying the system to
synchronously write deleted inodes to the disk before adding the
indirect blocks to the free list.  I don't recall offhand whether the
changes made in 4BSD to improve the file system reliability included
this change or not.
-- 
	Tom Teixeira,  Massachusetts Computer Corporation.  Westford MA
	...!{ihnp4,harpo,decvax}!masscomp!tjt   (617) 692-6200 x275