Xref: utzoo comp.unix.questions:10033 comp.unix.microport:1948
Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!elroy!cit-vax!mangler
From: mangler@cit-vax.Caltech.Edu (Don Speck)
Newsgroups: comp.unix.questions,comp.unix.microport
Subject: Re: dump/restore
Summary: restor
Keywords: cpio is not a real backup program
Message-ID: <8470@cit-vax.Caltech.Edu>
Date: 1 Nov 88 00:06:17 GMT
References: <178@celerity.UUCP> <12433@steinmetz.ge.com> <77@usl-pc.usl.edu> <8373@alice.UUCP>
Organization: California Institute of Technology
Lines: 27

In article <8373@alice.UUCP>, debra@alice.UUCP (Paul De Bra) writes:
>	     since there is no way to reset the create-time on a Unix system
> (except by setting the date and resetting it but that's awful and can never
> be used in a multiuser environment) there are NO backup programs that can
> restore the disk to the state it was at the time of the backup

restor (counterpart of V7/SysIII/4.1bsd dump) would restore ctimes,
inode numbering, holes, blocks past EOF, link counts, and even
unreferenced files to the state at the time of the (incremental)
backup.  It could restore 100% full disks.  It did not preserve
the disorder of the free list.

It was ugly and horrible (it wrote the raw device) but it CAN be done.

AT&T and Berkeley both dropped it due to the difficulty of porting to
filesystems whose blocksize may differ from the (fixed) tape blocksize.

Berkeley sacrificed the ctimes, and wrote restore, which is much cleaner.

AT&T gave up on incremental backups, and wrote volcopy (a glorified 'dd').

When we got a System V machine, nobody had the patience to mount 7 tapes
per volcopy every day.	After the first head crash, I ported restor.  I
regret this; it should have been restore.  I can stand loss of ctimes.

What do Amdahl UTS and Cray Unicos use?

Don Speck   speck@vlsi.caltech.edu  {amdahl,ames!elroy}!cit-vax!speck