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
