I think the hashing of the files is worth the overhead. At work we
currently keep 3 months of backups on our backup server ~ 1.4TBytes of
data.
I would like the hash values to be available for reporting against, so
that I can also do the equ of tripwire on the servers.
ie these files changed, these files were added and these files were
deleted.
At the moment I find a lot of false positives. ie a file is backed up
when it has not changed at all. When I was first reading about
rdiff-backup, and that it used rsync-lib, it seemed to be a side affect
of the rsync library. It had to do with the method that rsync figured
out what had changed.
F.
On Thu, 2005-10-27 at 13:44 +0200, Wiebe Cazemier wrote:
Ben Escoto wrote:
Another problem is that we would have to rewrite the mirror_metadata
file each time. If there was a bug in rdiff-backup or a disk
corruption, and the main file was lost, we would lose all the metadata
information. I don't have any specific worry in mind here, it just
makes me uneasy.
This is a genuine concern. Remember I corrupted my external HD severly with USB
errors? That sort of thing can happen.
Just two days ago, I had a similair situation. My computer suddenly became very
unstable, probably because I did rrmod -f on a module which I couldn't get
un-used. At first I suspected my HD, so I made a backup as soon as I could. It
crashed as well. Later, when I diagnosed my disc and restarted my system, I ran
a new backup. I was very glad the failed one got rolled back.
I know you can save a temporary mirror_metadata as a working version, but if
rdiff-backup had crashed writing the temp version over the orignal one, you are
bust. Or, power can fail suddenly. Anything can happen...
Anyway, it's good to guard against the unexpected and unprobable.
_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users < at > nongnu.org
http://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
