Xref: utzoo comp.unix.questions:10022 comp.unix.microport:1933
Path: utzoo!yunexus!geac!syntron!jtsv16!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!hplabs!oliveb!olivey!jerry
From: jerry@olivey.olivetti.com (Jerry Aguirre)
Newsgroups: comp.unix.questions,comp.unix.microport
Subject: Re: dump/restore
Keywords: cpio is not a real backup program
Message-ID: <31836@oliveb.olivetti.com>
Date: 2 Nov 88 00:57:12 GMT
Article-I.D.: oliveb.31836
References: <178@celerity.UUCP> <12433@steinmetz.ge.com> <77@usl-pc.usl.edu> <44433@beno.seismo.CSS.GOV> <8373@alice.UUCP>
Sender: news@oliveb.olivetti.com
Reply-To: jerry@olivey.UUCP (Jerry Aguirre)
Organization: Olivetti ATC; Cupertino, Ca
Lines: 24

In article <8373@alice.UUCP> debra@alice.UUCP () writes:
>In article <44433@beno.seismo.CSS.GOV> rick@seismo.CSS.GOV (Rick Adams) writes:

>>A BACKUP program should be able to restore the disk to the state it
>>was at the time of the backup. It should also offer incremental backups.

>Right, and 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 since this
>is simply not possible in Unix.

Actually, as others have pointed out the "restor" (pre 4.2bsd) version
did restore the ctime and other information because it wrote to an
unmounted raw disk.

In the case of "restore" it is not enough to add some way of setting the
ctime.  The inodes are being allocated at the whim of the system.  It
uses the file "restoresymboltable" to keep track of the old to new
inode mapping between restores of different levels.

Because of this, new incremental dumps of the file system would not be
compatable with previous dumps.  You HAVE to do a new full dump.

Restore is also damn slow.