Re: rdiff-backup

[Robert Nichols]

On 12/21/22 11:04 AM, Patrik Dufresne wrote:
> I'm Forwarding your conversation to rdiff-backup mailing list.
>
> >  From Bob Nichol's answer (yesterday) I understand that restoring a given
> > version of a file is by a reverse mechanism, that is, rdiff-backup starts
> > with the latest (most recent) version of a file and then goes backwards
> > until it finds the desired version.
>
> It might not be totally true. I know rdiff-backup also generates a snapshot
> of the files. I don't know exactly the mechanic about those. Possible Eric
> Zolf may have more detail about when those snapshot get used in the restore
> process.

Indeed, when a file is deleted from the source, in the next rdiff-backup run the 
"increment" that gets stored will be a snapshot of the most recent version of the file. 
When working backward through the increments during a restore, encountering a snapshot just means, 
"Throw away whatever you have built up thus far and use this."

When restoring a file that does not exist in the current mirror, the first 
increment encountered (working backward) _must_ be a snapshot, else a fatal 
error is flagged and you see a lengthy Python backtrace with an obscure 
reference to the cause buried inside. (Don't you just _love_ those backtraces? 
Python encourages using backtraces as a principal means of reporting exceptions 
to the end user. Personally, I feel that any backtrace presented to the user 
should be considered a bug in the code.)

--
Bob Nichols     "NOSPAM" is really part of my email address.
                Do NOT delete it.