Backup of a live filesystem revisited

[Fred Fish]

In article <1392 at cit-vax.Caltech.Edu> mangler at cit-vax.Caltech.Edu (System Mangler) writes:

[ deleted stuff ]

>the backup program reads it.  The program will either get garbage,
>or EOF, but in either case it has to write SOMETHING on the tape now
>that it has committed itself by writing out a header saying that the
>next st_size bytes are the contents of the file.

I had to deal with this when I wrote "bru" (Backup and Restore Utility).
My basic strategy was that the archive would always contain exactly the
number of bytes recorded in the archived file's header block.  If the
file actually shrunk or grew it was padded or truncated appropriately,
with a warning message.  This allows bru to always depend on the
size recorded in the file header to seek to the next file header (rather
than loop reading blocks) if it wasn't interested in the current file and
the archive device supports seeking.  A big win on table of contents...

>The insidious case, though, is when subdirectories get moved out of
>a directory that hasn't been backed up yet, and into one that has
>already been done or was being skipped.  That subtree won't be restored
>at all, and won't be on a subsequent incremental tape either, because
>the files didn't change.

Yes, any sort of movement or restructuring of the file tree can confuse
per-file type backups.  My feeling is that maintenance of the tree
structure is NOT the domain of the backup utility, but should be done
with a separate utility, that keeps track of changes in the tree.
The Unisoft vchk utility is close to this, but is oriented at keeping
two systems in sync, not keeping track of changes on a single system.

-Fred

-- 
===========================================================================
Fred Fish  Motorola Computer Division, 3013 S 52nd St, Tempe, Az 85282  USA
{seismo!noao!mcdsun,hplabs!well}!fnf    (602) 438-5976
===========================================================================