Re: Archive integrity/corruption question.

Hi Leland,

I want to add a couple of important points to Eric's response:

Regarding the hardware issue, this type of corruption would affect ANY 
backup software when the underlying hardware has memory errors. It's not 
specific to rdiff-backup. Any tool would write corrupted data when 
running on faulty RAM. This is exactly why using ECC memory on backup 
servers is so critical. Data integrity depends on reliable hardware, and 
ECC memory can detect and correct these errors before they corrupt your 
backups on disk.

Also, your archive is NOT entirely lost. Unlike blob-based backup 
software (like Borg, Restic, etc.), rdiff-backup stores the current 
backup as a normal mirror of readable files. This gives you several 
recovery advantages:

 1.

    All uncorrupted files are immediately accessible. You can copy them
    directly using standard file system tools without needing
    rdiff-backup at all. Only the specific corrupted file(s) are
    affected, not the entire archive. But I think you already know that.

 2.

    You can surgically remove the problematic file using
    |rdiff-backup-delete <corrupted_file_path>| to completely delete the
    history of just that corrupted file from the repository. This should
    eliminate the verification error entirely while preserving
    everything else.

So to answer your question directly: No, the entire archive is not lost. 
You can recover all non-corrupted files immediately, and you have 
options to repair or remove the corrupted file's history.

That said, Eric's suggestion about creating a new baseline periodically 
is still excellent practice for long-term backup hygiene, but with good 
hardware, I can recover files from a 15 years old backup without problem.


On 2/7/26 04:45, 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
>>
>
>
-- 
Patrik Dufresne
IKUS Software
https://www.ikus-soft.com/
514-971-6442
St-Colomban, QC J5K 1T9