Incremental dumps using cpio

[Sam Kendall]

In article <1729 at brl-tgr.ARPA>, bzs at bostonu.csnet (Barry Shein) writes:
> Sure, we do [incremental dumps using cpio] as a regular shell procedure
> on our 3B5 ....
> [shell procedure essentially "find filesystem -mtime 7 -print | cpio"]
> P.S. The above procedure ignores empty directories, FIFOs and device
> files ....

It also ignores:
(1) files that have been linked, chmod'd, or backdated (using tar or
    cpio);
(2) contents of directories that have been mv'd; and
(3) files that have been unlinked (i.e., restoring a full dump, then an
    incremental dump, will leave in their old place files which were
    rm'd or mv'd in between the dumps).

Using "find -ctime" instead of "find -mtime" will solve (1).  This makes
the backups okay for the purpose of restoring accidentally deleted
files, but (2) and (3) make it messy for restoring a lost filesystem --
things won't be quite the same after the restore.  Take it from me, this
"near restoration" is annoying as hell.

Both find and cpio are underpowered for this application.  find becomes
awkward here when you have one filesystem mounted under another mounted
filesystem (e.g., /usr and /usr/spool), and its granularity of 1 day
with -ctime is annoying.  -newer has a finer granularity, but doesn't
deal with change times.  As for cpio, it should have an option to cope
with (3) by recording the contents of directories.

Backup tools, even more than interactive debuggers, have traditionally
been neglected under UNIX.  (Backup *devices* have also been neglected
by (super)micro manufacturers, of course, but now that cartridge tape
drives are getting cheaper, that is changing.)  I have gotten mailings
for the "UBACKUP" tools from Unitech Software, but I don't know much
about them.

----
Sam Kendall			     allegra \
Delft Consulting Corp.		seismo!cmcl2  ! delftcc!sam
+1 212 243-8700			       ihnp4 /
ARPA: delftcc!sam at nyu.ARPA