rdiff-backup-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Ben Escoto
Subject: Re: [rdiff-backup-users] A "digest stand-in" Option?
Date: Sun, 19 Jan 2003 11:30:52 -0800

>>>>> "KB" == Kent Borg <address@hidden>
>>>>> wrote the following on Sun, 19 Jan 2003 09:28:34 -0500

  KB> I guess that also brings up a question of missing files.  What
  KB> happens if I do a backup on day one, on day two create a bunch
  KB> of files, and then do a restore back to day one.  Do the created
  KB> files get deleted in the restore?  If so, how are they
  KB> differentiated from excluded files that never go backed up?  Or
  KB> do excluded files also get deleted in restores?

Right, as it is there is no difference between an excluded file, and a
deleted file (i.e. a file that just isn't there, but that would be
included if it were there).  So if you exclude a directory when
backing up, when you restore, anything in that directory will get
deleted.

This approach seemed necessary earlier because rdiff-backup was
supposed to make a mirror, and restoring happened solely from that
mirror.  If a file isn't in the mirror, it just isn't in the mirror.
A file can only be missing in one way, not in a deleted way and in
a separate excluded way.

But now that constraint seems to have been relaxed a bit, since as of
0.11.1, information not in the mirror can still be read from the
metadata file.  So maybe files could be tagged in the metadata file as
deleted or as excluded.  Or since excludes can be regular expressions
and such, maybe the exclude options could be written down in a
separate file.  Hmm, this is starting to sound complicated...

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.


-- 
Ben Escoto

Attachment: pgpZZye4jpGbR.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]