tjt@kobold.UUCP (01/16/84)
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 x275thomas@utah-gr.UUCP (Spencer W. Thomas) (01/16/84)
Well, I know this isn't an answer for your case, but the 4.2 restore (note the 'e' on the end) program must be run on a MOUNTED disk, and creates the new files using the standard creat and mknod calls. Really helps to leave your disks in a more consistent state. (At least, this is my understanding of what it is doing.) I recently switched to 4.2, and in the process, modified the disk layout drastically (splitting what was previously 2 filesystems into 4). Since neither of the old filesystems would have fit into the new slots, I just created symbolic links to the parts I wanted to put on another filesystem, and it all worked! E.g., put /usr/src on /w/src: mount /usr and /w appropriately mkdir /w/src ln -s /w/src /usr/src cd /usr restore r ... wait a long time ... :-) =S
guy@rlgvax.UUCP (Guy Harris) (01/18/84)
The manual pages for V7, 4.1BSD, and S3 "restor" are pretty much the same
as those three versions of "restor" are 99% the same, so what applies to one
applies to all (some bugs were fixed in the 4.1BSD version, so if you have
either V7 or S3 and access to the 4.1BSD version, bring that one up).
Guy Harris
{seismo,ihnp4,allegra}!rlgvax!guyperl@rdin.UUCP (Robert Perlberg) (01/21/84)
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
henry@utzoo.UUCP (Henry Spencer) (01/24/84)
Sounds like what used to happen to us, back when we did our dumps
while running multi-user, when we foolishly tried to restor an
incremental in on top of a full. The contents of a dump tape made
on a non-quiescent file system are unreliable, period. It usually
turned out that one could restor a full backup without *too* much
trouble, but chaos and madness were guaranteed if one tried to bring
in an incremental on top of it.
The problem went away, completely, when we started insisting that our
dumps be done single-user. We had to put up with screams of outrage
for a little while until people got used to the downtime, but we've
done multi-level restors several times since and they work perfectly.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry