[Top][All Lists]

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

Re: rdiff-backup

From: Robert Nichols
Subject: Re: rdiff-backup
Date: Wed, 21 Dec 2022 15:56:33 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0

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

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.

reply via email to

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