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
_______________________________________________
rdiff-backup-users mailing list at [email protected]
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
