Incremental dumps using cpio

[Barry Shein]

>From: weber at nadc.ARPA
>We recently installed Sys-V, release 2 and would like to use the cpio
>command to do daily incremental dumps.  AT&T has hinted that cpio
>should be used but doesn't want to give out any more info without a
>service contract in place.

Sure, we do that as a regular shell procedure on our 3B5, although
the shell script is a little peculiar to our installation, here's
the gist of it:

	for j in 5 6 7 8	# whatever, for /usr5, /usr6...
	do
		/bin/find /usr$j -type f $duration -print >> $logfile
		/bin/cpio -oB < $logfile > /dev/rmt/0m
	done

where we set logfile to a file name that indicates the date (eg.
Jan.17.86) and the duration is going to be something like "-mtime -7"
which means back up all files modified in the last 7 days. The purpose
of the logfile is that it will end up to be one of the first files
backed up and contains the names of all the files on the tape if we
need that for reference later (could extract it and print it out as a
first step for recovering something, much faster than cpio -itB, you
could also move them to an operator's area so a quick grep will tell
you which tapeset should have a file in question.) Note that if the
system is running things will change while the find is running and
while cpio is running, we figure all that means is that you will miss
backing up some files that were just this minute created or changed
which is equivalent to having started the backups an hour ago, we'll
get it next time. For fulls (very similar code) we go single-user to
make sure we get everything. It's not 4.2's dump by any means but that
wasn't a choice. Restores can be done with the cpio pattern matching
(cpio -ivBmd '/usr5/*' < /dev/rmt/0m [restore everything on /usr5,
eg]). One more thing, when you run out of tape cpio will say something
like 'output write error; enter device name to continue', mount a
fresh tape with a write ring and type the device name again
(/dev/rmt/0m or whatever) and it will just continue, you could back up
your whole file system to one tapeset though I wouldn't recommend it
(a bad spot in one tape could ruin the set.)

Hope it helps. Needless to say do a few dry runs with whatever you choose.

	-Barry Shein, Boston University

P.S. The above procedure ignores empty directories, FIFOs and device
files, you might want to run a 'find' to at least create a file which
lists those in a file so, worst comes to worst, you could re-create
by hand or by editing the output into a shell script, I would use:

	/bin/find / -type p -a -exec echo mknod '{}' p ';' >> FIFO.jan17.86

or somesuch (the result should be a shell script which would recreate FIFOs.)