[rdiff-backup-users] Re: Computed SHA1 digest doesn't match recorded digest

[Daniel Miller]

This is starting to make me a little nervous. It sounds like no one  
knows (or cares?) how to fix this issue (see below), and I'm worried  
that it may eventually hit a file that is critical. The error has not  
changed at all since I started to see it, but it does continue to  
appear each day in the backup log.

The design of rdiff-backup concerns me because it seems there is no  
way to restore older backups once an increment becomes corrupted. One  
mishap and all older revisions are lost. It sounds like some people  
on this list have experienced that issue, and I am starting to worry  
about the integrity of my long-term backups. How are other people  
dealing with this issue? Do you start a new rdiff-backup series every  
now and then to mitigate the risk of corruption, or is there some  
other technique to avoiding loss of older revisions?

I do keep copies of my backup repository on multiple drives, so I am  
not vulnerable to a single drive failure. Technically this also  
protects me from the "one mishap" I mentioned above as well, but if  
some corruption sneaked by without my noticing it in the first three  
days, then all my copies would be corrupt and I'd lose all historical  
backups beyond the point of corruption--very bad.

I've started to look at StoreBackup as an alternative, since it  
claims that "each backup set is totally complete, independent, and  
autonomous". However, StoreBackup seems to be even less popular than  
rdiff-backup, and therefore has less of a community to provide  
support. Am I missing something big in that assessment? I'm also a  
little concerned that I have not been able to find any well- 
documented examples of running StoreBackup on OS X, although I'm not  
afraid to get my hands dirty getting it to work. Some other concerns  
with StoreBackup are:

- support for file meta-data such as ACL's and resource forks on OS X  
(notably, rdiff-backup does not support ACL's on OS X)
- ability to maintain multiple copies of the backup repository. This  
must be possible in a fairly short amount of time, since I will need  
a complete copy of the repo each day (currently I use rsync to dup my  
rdiff-backup repo, and since I'm updating an image that is only three  
days old, it's reasonably fast).

Granted, StoreBackup may not be quite as space efficient as rdiff- 
backup (which has performed AMAZINGLY in that regard), but space is  
not a huge issue for me at the moment, so I'm moving that below long- 
term reliability on the priorities list.

Your thoughts/experience are greatly appreciated. Thanks in advance.

~ Daniel


On Aug 3, 2009, at 9:27 AM, Daniel Miller wrote:

> Recently I got an error message during the verify phase of my backup:
>
> Warning: Computed SHA1 digest of usr/local/pgsql829/data/base/ 
> 16417/104934
>    0520c6624e91386b43c6bdcdaddfb8df0617ec86
> doesn't match recorded digest of
>    f1629023c48ff184d702ea59d07fdd88f55fad03
> Your backup repository may be corrupted!
>
> I have continued to receive the same error on subsequent backup/ 
> verify cycles. Lucky for me this file is probably not of critical  
> importance -- it is a PostgreSQL system data file (I have a  
> separate pgdump archive that would be used to restore the database  
> if needed).
>
> However, I would like to put the repository in a state that does  
> not produce this error on verify. How to I recover from this error?  
> Is there any way to restore the integrity of my repository?
>
> System details:
> Mac OS X Server 10.5.7
> rdiff-backup 1.2.8
> Python 2.6.2
> librsync-0.9.7 (patched with librsync-largefile.patch)
> xattr-0.4
>
> ~ Daniel