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 >> > >