SUMMARY: Backup while in multi-user mode

Leslie Mikesell les at chinet.chi.il.us
Sun May 26 11:53:25 AEST 1991


In article <1991May24.013214.2526 at servalan.uucp> rmtodd at servalan.uucp (Richard Todd) writes:

>1. "dump" preserves the access times on files, and "restore" restores the
>files with the access times set correctly.  "cpio" neither records the access
>times in its archive nor leaves the access times of the files on disk 
>unaffected.  Thus, "cpio" screws up any schemes one may have for locating 
>user files that haven't been accessed in, say, 6 months and automatically
>moving them off to tape and deleting them.  

Most cpio's have the -a option to "fix" the disk access time to be the
same as it was before cpio read the file.  The problem is that if you
use it, it changes the ctime in the process of fixing the atime.  So
if you use ctime to test for the files that need to be put on an
incremental backup (and you should...), they all appear to be new.
The only solution I've found is to back up across a read only mount,
which isn't too difficult if you are going over an network anyway.

>2.  "dump" handles files with holes in them correctly (the holes don't take
>up space on the backup, and "restore" restores the files with holes correctly).
>"cpio" doesn't.  Having all your dbm files suddenly explode in disk usage 
>after having been brought back off of tape is considered bad form in some
>circles...

Afio (a cpio work-alike) will do this by seeking over blocks of nulls
during the restore.

>3.  Just how were you planning to do restores of those incremental backups?
>Seems to me that the naive approach (extracting the incremental cpio just
>like the full cpio backups) won't work correctly on directories which have
>had files deleted between the making of the full and the incremental
>backup. 

GNUtar is the only thing I've seen that gets this right (running AT&T
sysV, I haven't used dump/restore).  It (optionally) makes an entry
containing all the current contents of the directories as it goes by
and can (optionally) delete files that aren't supposed to be there
as you restore.

Les Mikesell
  les at chinet.chi.il.us



More information about the Comp.unix.admin mailing list