A good incremental backup for system V

[Mark Brukhartz]

In article <151 at ttrda.UUCP>, dwd at ttrda.UUCP (Dave Dykstra ) writes:
> I now see that a good incremental backup for system V is possible.
> 
> With the above suggestion of Henry Spencer, I put in a quick addition to
> find(1) to look for files that are newer based on change time instead of
> Now all I need is the change to cpio that was formerly suggested to have
> an option to remove files which no longer exist.  All it needs to do (I
> think) is to save the complete contents of directories which have been
> changed and unlink the files which aren't in the directories upon restore.

Directories are recursive. A change to the root directory would turn the
next incremental backup into a full one. When "filehog" removes the vnews
core file from his home directory (:-), all of his files will be backed
up again. Ugh!

> How about adding the option [to remove files] to afio, Mark Brukhartz?  

I've thought about this for the past several months. It's easy to remove
files when reading the archive.  How does one tell afio (when writing the
backup) which files are to be removed? Note that order is significant; it
is neccessary to remove a directory (and, of course, its contents) before
creating a file of the same name.

	o Name a file containing the list. This requires that the list
	  be generated before afio is invoked, preventing pipelineing of
	  incremental backups.

	o Assume that nonexistent files are intended to be removed. This
	  sounds dangerous... It's too easy for a mortal user to "backup"
	  and "restore" a mode 777 directory containing inaccessible mode
	  400 files, inadvertently removing the files. Yes, it's possible
	  to distinguish "no permission" from "no such file" errors, but
	  the possibility for bugs and other problems is disturbing.

	o Add a "key" as the first character of each input pathname, with
	  ">" meaning "copy" and "<" meaning "remove". This would have to
	  be Yet-Another-Option* to preserve what little cpio invocation
	  compatibility remains. Consider, too, of all of the other keys
	  which could be added by future featurefesters (...say that five
	  times quickly!).

Lacking other ideas or suggestions, I'll probably go with the "key" scheme.
None of the present alternatives sound very inviting, though.

						Mark Brukhartz
						Lachman Associates, Inc.
						..!ihnp4!laidbak!mdb

* Yet-Another-Option ought to be trademark of the
  Regents of the University of California at Berkeley