🚀 go-pugleaf

> ... good except for the case
> where files are moved without changing their modification time.  Then
> the files will not show up on the incremental backup but the file in the
> former directory will be removed.

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.

> 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.  Yes, we have lost filesystems and restored them
perfectly from full+incremental backups.

It is quite possibly true that incrementals are basically useless on a
System V using cpio for backups.
-- 
Support the International League For The Derision Of User-Friendliness!

				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,decvax,pyramid}!utzoo!henry

In article <150@ttrda.UUCP> dwd@ttrda.UUCP (Dave Dykstra ) writes:

> ...except for the case
> where files are moved without changing their modification time.  Then
> the files will not show up on the incremental backup but the file in the
> former directory will be removed.

Ah!  But the *creation time* is changed when you move the file.
(Creation time is a misnomer;  the real meaning of this field is
"last change to inode").

Thus, the following find command will pick up all files for a daily
incremental backup:

	find / -mtime -1 -print -o -ctime -1 -print ...

or, if you have the mods to find that allow switches like -newercm, use

	find / -newercm /.lastinc -print -newermm /.lastinc -print

(I think I have the character order right;  it might be -newermc).
-- 

	Geoff Kuenning
	{hplabs,ihnp4}!trwrb!desint!geoff

> 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

> > ... dump based on the most recent of the mod time and the change time...
> 
> 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.

This is true if you are positive that all Unixes and Unixoids and Unixish
systems will get this fine point right.  It costs little to be paranoid
and check both, which is presumably why the V7 dump does it that way.

> Also, the rename problem is deeper than inferred; what about all of
> the file pathnames which change when a directory is renamed?

With the old-style dump/restor approach, this is a null issue.  When you
restore the parent directory, which changed when its child was renamed,
it has a link to the child under the new name.  Hence the child is known
by the new name and its files and subdirectories are available via the
new path.  It is sufficient to note that their names have changed; it is
not necessary to dump them again.

> 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.

For most ordinary Unix purposes, this algorithm should be reliable.
There is, however, a more subtle problem which can arise.  Things like
database systems may well be in an inconsistent state when backed up.
There can be race conditions even if all relevant files appear to change
simultaneously,	since the backup algorithm does not process them
simultaneously.  The only way to produce a backup tape which is an exact
snapshot of the system is to require everybody to hold still while you take
the snapshot.  (It is admitted that backups which are not exact snapshots
may still be a useful form of backup.)
-- 
Join STRAW: the Society To	Henry Spencer @ U of Toronto Zoology
Revile Ada Wholeheartedly	{allegra,ihnp4,decvax,pyramid}!utzoo!henry