Hi David,
As always, thanks for taking the time to reply. See below ...
On 2/7/26 12:45 PM, David Croll via Any discussion of rdiff-backup wrote:
Hello Leland,
I would also like to confirm what you've written. Also, in case of an
SHA sum mismatch, rdiff-backup recreates an empty file - either from
the mirror, or an increment. And you can't apply an increment to it.
And the gzipped increment files won't unpack either if there's a
CRC-32 mismatch.
Patrick pointed out 'rdiff-backup-delete' which I hadn't known about.
It sounds like that should, at least, make the archive usable again.
However, after that there will be no indication, in the archive, that
the deleted file(s) ever existed. One would need to make a note of that
somewhere I suppose.
So, some redundancy is in order...
Heh. Redundancy. It seems to me that, in the most abstract view of
things, "deduplication" and "redundancy" are very much opposites. In
terms of data (including backups) deduplication seeks to reduce the
amount storage needed (at the risk of greater data loss when things go
wrong), while redundancy seeks to reduce the risk of data loss at cost
of increasing storage requirements. Just back-of-the-napkin thinking
here. No, not even that. :)
Don't laugh, but as a private user I've simply taped three external
HDDs together, and I randomly rdiff-backup to one of these.
I'd be the last to laugh. Believe me.
David
Cheers
Leland
--
-------------------------------------------------------------------------------
Leland C. Best | When stupidity is considered patriotism, it is unsafe
[email protected] | to be intelligent.
| -- Isaac Asimov
-------------------------------------------------------------------------------
