Re: [rdiff-backup-users] A "digest stand-in" Option?

[Kent Borg]

On Sun, Jan 19, 2003 at 11:30:52AM -0800, Ben Escoto wrote:
> So if you exclude a directory when backing up, when you restore,
> anything in that directory will get deleted.
> [...]
> Instead maybe the backup side could be left as-is, and there could
> just be options like --no-delete or --no-overwrite-newer, which make
> rdiff-backup not delete anything that's already in the restore
> directory, or not replace a newer file already present with an older
> one.

I might be getting in over my head here, but if I follow, the current
behavior for excluded files could indeed be surprising/disappointing
for some users and your idea could help.  

Wondering about the behavior of digest files, let me see if there are
clear cases:

- restore to an earlier date where a digest file matches the current
  file: do nothing.

- restore to an earlier date where the digest file didn't exist:
  delete the current file (unless a --no-delete switch says not to).

- restore to an earlier date where the digest file exists but the
  current file is missing: in a verbose mode say so for every file
  "File /usr/bin/foo can't be restored from a digest", in a
  non-verbose mode say so for whole directories when posible
  "Directory /usr/bin (42 files) cannot be restored from digests, you
  must restore from other sources."

- alter a digest file (the file now gets stored complete, both the
  original version and the altered version), restore to the altered or
  original version: the altered version gets restored.


In practice, I imagine doing a complete backup, then going back and
marking some files and directories to be digests (OS supplied things
like /usr/bin).  Now use the computer, change files, do stuff, and
also do further backups, mostly creating and deleting and changing
regular files, but occasionally changing or deleting digest files.

Now I imagine three kinds of restore "tasks":

1.  Wanting to go back in time and see how some user supplied or
manipulated file used to be.  Cool.  All those earlier versions should
be available, even for files that the user once marked as digests
(altering a digest file causes both the before and after versions to
be stored in complete detail).  Alter /sbin/ifconfig and the original
will be stored, in addition to the new version.  Digests are only for
files that are not expected to change, and, indeed, have not changed.

2.  Catastrophic failure (or maybe a security breach and installation
of a rootkit of unknown details).  Wipe the disk, reinstall the OS
from scratch (off CDs, fairly quick), get network configuration up far
enough to talk to remote computer, then do a restore to the last good
date (possibly over the internet, slower than a CD).

3.  Oops.  I typed "rm -f /sbin/ifconfig".  That was stupid.  Try a
restore from remote computer, oops, it was a digest file.  (If not a
digest file, goto case 1.)  So restore from someplace else.  Maybe
copy the remote computer's own working copy, or ftp from someplace
else, or get it from install CDs.  If I dig up a version that doesn't
match the original, the system can tell me.

Clearly the last case is a pain, but one need not use digests where
not appropriate, and the size of a "complete" backup can be shrunk
enormously if one chooses to say that OS files are not likely to need
to be restored.


I know I am requesting a significant feature, but I think the
complications it presents are not as bad as issues currently
surrounding excluded files, and to the extent it removes the need to
use excluded files, it could make improve matters.


-kb