Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!sri-unix!hplabs!hao!noao!mcdsun!fnf From: fnf@mcdsun.UUCP (Fred Fish) Newsgroups: comp.unix.wizards Subject: Re: Backup of a live filesystem revisited Message-ID: <214@mcdsun.UUCP> Date: Wed, 24-Dec-86 14:48:37 EST Article-I.D.: mcdsun.214 Posted: Wed Dec 24 14:48:37 1986 Date-Received: Thu, 25-Dec-86 18:38:44 EST References: <4760002@hpirs.HP> <1226@ho95e.UUCP> <1392@cit-vax.Caltech.Edu> Reply-To: fnf@mcdsun.UUCP (Fred Fish) Organization: Motorola Microcomputer Division Lines: 38 In article <1392@cit-vax.Caltech.Edu> mangler@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 ===========================================================================