From: utzoo!decvax!decwrl!sun!megatest!fortune!hpda!hplabs!hao!seismo!rlgvax!guy
Newsgroups: net.unix-wizards
Title: Re: Flames on system backups
Article-I.D.: rlgvax.202
Posted: Fri Apr  8 23:43:47 1983
Received: Wed Apr 13 21:49:25 1983
References: sri-arpa.814

We have substantially modified the V7/S3 "restor" to solve *some* of the
problems mentioned:

o	dump does not allow multiple filesystems on a tape.

Our "restor" has a "F" (so sue me, I'm too tired to fight UNIX's one-character
option orientation) option, which says the file on the tape to restore from
is file number "n", so that you can say

	restor XfF /dev/rmt8 3 ...

to restore from the third file on the tape (I will explain the "X" later).

o	dump does not recognize end of tape.

This may involve beating the UNIX magtape driver up a bit (believe me, with
the exception of the 4.1BSD driver, it deserves it; how many of you have
had to hack the magtape driver(s) to give it special function commands to
skip blocks/files, or write an EOF, or rewind, or rewind/unload, or...?  To
quote Monty Python, "I know I have.").

o	restorations on dump are painful.

*FIXED*!  The "X" option to our "restor" dumps the file into itself;
furthermore, if you specify a directory to "restor" with the "X" option
it restores the directory by creating it (fork and exec of "mkdir") and
restoring all its contents recursively.  I.e., if you have a directory
/usr/foo/bar, if you say

	restor X foo/bar

on the "/usr" dump it will create a directory "foo/bar" in the current
directory (so cd to "/usr" if you want "/usr/foo/bar") and pull in all
its contents.  It will create all directories needed to restore a file
by pathname, just like "tar" (which isn't surprising, considering that's
where I ripped the code off from).

We also have a "T" option which does a "dumpdir"; since "dumpdir" is just
a mutant version of "restor" (check the code out!), and since all the
stuff added to "restor" to make "dumpdir" was needed for "X", we put in
a "T".  Also, there is a "c" option which works like "r" only it works
as a read/compare instead of a write; i.e., it should be run immediately
after a "dump" so you know that you can trust the dump you just made.

Also beware of using the S3 "restor" with the "r" flag; it does *not*
maintain the s_tfree and s_tinode fields in the superblock, so you will
have to "fsck" the file system after that if you want the "ustat" system
call, and all the programs that depend on it (like "df", the RJE software,
and "ed") to work.  4.1BSD also maintains the s_tfree and s_tinode field
(although they don't provide the "ustat" call), and they fixed "restor" to
update it when restoring; our "restor" actually came from the 4.1BSD one
and therefore does this.  It also fixes a couple of bugs involving dump tapes
with files that happen to have a bit pattern that matches a dump tape header
block (this fix also came from 4.1BSD), and a number of other bugs that we
ran into along the way.

					Guy Harris
					RLG Corporation
					{seismo,mcnc,we13}!rlgvax!guy