Xref: utzoo comp.unix.questions:10012 comp.unix.microport:1918
Path: utzoo!attcan!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.unix.questions,comp.unix.microport
Subject: Re: dump/restore
Keywords: cpio is not a real backup program
Message-ID: <377@auspex.UUCP>
Date: 1 Nov 88 19:00:35 GMT
References: <178@celerity.UUCP> <12433@steinmetz.ge.com> <77@usl-pc.usl.edu> <44433@beno.seismo.CSS.GOV> <8373@alice.UUCP>
Reply-To: guy@auspex.UUCP (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 27


 >>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

That's "inode change time", not "create time"; neither the V7/S5 file
system, nor the 4.2BSD file system, stores the create time.

 >(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.

You completely missed the point.

I can live with the inode change time not being restored.  I'd rather
not live with a full restore done from a full and an incremental backup
restoring files that had been deleted by the time the incremental was
done - I want those files gone.  I don't *have* to live with that if I
use "dump" and "restore"; I do if I use "cpio" or "tar" for incremental
dumps. 

(Oh, and by the way, although the 4.[23]BSD "restore" restores to a
mounted file system, the V7/S3/4.1BSD "restor" restored to a raw disk,
so it could set the change time to whatever it wanted.)