dump/restore

[Jerry Aguirre]

In article <8373 at alice.UUCP> debra at alice.UUCP () writes:
>In article <44433 at beno.seismo.CSS.GOV> rick at 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.