Some thoughts on enhancing cpio(1)

[Mark Brukhartz]

> As has been known at least since the V7 dump/restor system was written
> (1978?), you should dump based on the most recent of the mod time and
> the change time.  The change time changes when the inode changes, and
> since a rename involves (temporarily) changing the link count, the change
> time will reflect it.

The change time (ctime) is always set to the present when the modification
time (mtime) is altered. Hence, it is sufficient to look at only the change
time. Also, the rename problem is deeper than inferred; what about all of
the file pathnames which change when a directory is renamed?

> 
> > For a while we were losing our filesystems on a regular basis and we
> > found that incremental backups are basically useless...
> 
> Actually they work fine if done right, i.e. using a proper dump/restor
> system rather than cpio, and done standalone so the filesystem is not
> changing underfoot.
> 
> It is quite possibly true that incrementals are basically useless on a
> System V using cpio for backups.

Incrementals appear safe as long as you compare reality to a list of full
pathnames and inode change times from a full backup. Kept ordered by path,
it's easy to generate a list of deleted, added and changed files. Even the
directory-rename case (mentioned above) is handled reasonably well; every
file in the tree is noted "deleted" with the old name and "added" with the
new name.

It is reasonable to back up active filesystems with this scheme. Races with
users generally result in doubly backed up files or innocuous "cannot open"
messages. Only an unlikely combination of renamed directories and files with
identical inode change times appear likely to break this algorithm.

We have a Sequent with three full Eagles and a couple of Cipher GCR (6250)
CacheStreamers. Full backups via dump(8) take the better part of a day. We've
been using a homegrown cpio(1) replacement (...to be posted to the net Real
Soon Now) with the aforementioned scheme for six months or so. Unfortunately
(?), we've never restored an entire real-life disk, but I see no reason why
we couldn't do so.

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