4.2BSD restore(8)

[Dave Martindale]

In article <1631 at wucs.UUCP> nz at wucs.UUCP (Neal Ziring) writes:
> > > I have also noticed that after a restore all the files marked as
> > > changed and will go on the next dump.  [ ... ]
> > 
> > If you really did just spend hours restoring the file system, then you
> > have restored all or virtually all of the file system. If you don't
> > want to do a level 0 dump, simply edit /etc/dumpdates to reflect
> >  ...
>
>In fact, this problem is due to a quirk in a dump/restore, the
>restored files have the correct modification time, but their creation
>times are the time of the restore!
>
>Repeat-By:
>	Put a file system on a dummy partition, and do a level 0
>	dump(8) of it.  Wait a few minutes.  Then, trash the partition
>	and restore it fully from your dump.  Change one file.
>	Now, do a level 1 backup with dump(8).  The backup should be
>	extremely small (one file) but it isn't!  It is the whole
>	filesystem!
>
>To Fix:
>	Change dump so that it looks only at the modification time, not
>	the creation and modification times.
>

If you think of a dump as "all the files that have changed *contents* since
the most recent higher-level dump", then you do indeed want to dump
according to modification times.  But this is **not** what dump was
written to do.  It is intended to write out *all* the information needed
to restore *all* changes made to the filesystem, including changes
in permissions or link count of a file.  These latter things change
the inode's "di_ctime", which is really "change" not "create" time.

So, if you want to use dump and restore as a method of completely restoring
the state of a filesystem, not just getting back all the contents of the
files, don't change the algorithm.

And if you run 4.[23] BSD, you will still have to do level 0 dump after
doing a full restore.  No way of avoiding it.

	Dave Martindale