Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site omen.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!vax135!cornell!uw-beaver!tektronix!reed!omen!caf
From: caf@omen.UUCP (Chuck Forsberg WA7KGX)
Newsgroups: net.micro.pc
Subject: Re: Xenix backup/restore on AT
Message-ID: <163@omen.UUCP>
Date: Fri, 17-May-85 13:05:37 EDT
Article-I.D.: omen.163
Posted: Fri May 17 13:05:37 1985
Date-Received: Sat, 1-Jun-85 02:15:31 EDT
References: <1967@topaz.ARPA> <161@omen.UUCP>
Reply-To: caf@.UUCP (Chuck Forsberg WA7KGX)
Organization: Omen Technology, Portland
Lines: 47
Summary: 

My previous followup failed to mention that I had tried to use dump and
restor directly (as I have on V7 and a Plexus V7 and SYS III). To clarify
things, I'm including a portion of the report I sent to IBM in December
and gave to Microsoft in Janurary.


Normal floppy disk writes do not appear to be checked either.  The best
advice is to completely read the floppies you have just written to make
sure they are readable.  Unfortunately this makes multi volume floppy
disk backups incredibly cumbersome.  Xenix desperately needs a "VERIFY"
switch `ala DOS.

Speaking of disk backups raises a sore point. ...

The documentation on restore(1) notes that "It is not possible to
successfully restore an entire active root file system." No such
warning is made in the documentation on backup(1) (`aka dump(1)).

The implication is that these programs will operate properly on an
inactive root file system, such as when Xenix is in system maintenance
mode.

When I made a level 0 backup, backup cheerfully wrote out out five HD
diskettes.  Unfortunately, dumpdir coredumps when trying to read this
archive, and restor wouldn't restore a good file system from these
disks.

Life was slightly better with the /usr file system, except that backup
skipped all files and subdirectories to /usr/lib.  The resulting
filesystem ended up with a cyclical data structure, a directory that is
indirectly linked back to itself.

After discovering (the hard way!) about backup/restor\'s problems
dealing with a root file system, I tried dd.  A first dry run
(dd if=/dev/root of=/dev/null bs=10k) seemed to work normally, but
succeeding dd commands resulted in a variable, smaller number of
records transferred and eventually core dumps.  By this time things had
gotten so far out of hand that the shell itself was tossing cookies.

(The revised disk driver on the maintenance disk seems to have cured the
core dump syndrome but not the other problem.)

OOOPS - No It didn't !!!  Just took a little longer to start tossing cookies.
-- 
Chuck Forsberg WA7KGX	..!tektronix!reed!omen!caf
Omen Technology Inc 17505-V NW Sauvie IS RD Portland OR 97231
Voice: 503-621-3406	Modem: 503-621-3746 (Hit CR's for speed detect)