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
--
-------------------------------------------------------------------------------
Leland C. Best | When stupidity is considered patriotism, it is unsafe
[email protected] | to be intelligent.
| -- Isaac Asimov
-------------------------------------------------------------------------------
