Re: rdiff-backup

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.