Re: Archive integrity/corruption question.

"Leland C. Best" <[email protected]> Sat, 7 Feb 2026 13:56:29 -0700
Newsgroups gmane.comp.sysutils.backup.rdiff-backup.general
Message-ID <[email protected]>
Hi Eric, et al,

Thanks for the info.  Mostly, I just wanted to make sure I wasn't 
missing something in my understanding of how 'rdiff-backup' works, or 
that there some little-known ... something ... that I wasn't aware of 
that might hlp.  [Actually, Patrik _did_ point out something very 
interesting but I'll reply to that later.] Fortunately, I found the 
problem (with  my server) before I needed to restore anything.  But now, 
at least can confidently assess the scope of the damage.

Again, thanks for taking the time to reply.

Cheers
Leland

On 2/7/26 2:45 AM, Eric L. wrote:
> Hi Leland,
>
> everything you write is correct.I would have expected the backup 
> action to detect when something gets corrupt, at time of writing, but 
> that's difficult to reproduce and test, so no guarantee (if you know 
> which file, you could check in past backup logs). But even if it's the 
> case, that doesn't help you anymore.
>
> The only way to address this would be to create a new repository from 
> time to time, to save a new baseline.
>
> KR, Eric
>
> On 04/02/2026 07:48, Leland C. Best wrote:
>> Hi All,
>>
>> First, I've used 'rdiff-backup' for a long time (20 years?). I've had 
>> to use my backups to recover everything from a few accidentally 
>> deleted files to complete system restores to bare metal (although 
>> other tools are also needed to do the latter). As such, I want to 
>> thank everybody who has contributed, and is contributing, to this 
>> outstanding project.
>>
>> I have a question about the integrity of a backup archive under 
>> certain conditions.
>>
>> As I understand it, the current (i.e. most recent) backup is simply a 
>> "mirror" of the source directory.  The next most recent backup can 
>> then be reconstructed by applying a set of diffs (an "increment"?) to 
>> the current backup.  Another (additional) set of diffs applied to 
>> that would reconstruct the next most recent backup.  And so on.
>>
>> Lets suppose that, somehow, the current backup (the mirror) becomes 
>> corrupted.  Given how I think things work in 'rdiff-backup', it seems 
>> to me that that would mean the _entire_ archive would be corrupted.  
>> That is, doing a 'rdiff-backup regress' would _not_ recover the 
>> previous backup.  Is that correct?
>>
>> I'm asking because my backup server has developed _very_ intermittent 
>> memory errors.  I only discovered this _because_ an 'rdiff-backup 
>> verify ...' on the most recent backup failed.  [I ultimately verified 
>> it was a memory problem via 'memtest86+'.] The error was of the form
>>
>>     ERROR:   Computed SHA1 digest of file <some file>
>>     '4e45b5128111db53558b1135898386bbaac5c4b2' doesn't match recorded
>>     digest of 'a671cd065bd97e16b6c5a3cf789e37447fa13fa9'. Your backup
>>     repository may be corrupted!
>>
>> The point being that, if I'm understanding correctly, then at this 
>> point the entire archive is now basically lost.  Again, is this correct?
>>
>> Thanks in advance for any info.
>>
>> Cheers
>> Leland
>>
>
>