Two questions:
1) are you planning to better handle renamed files? That's killin' me.
I have thought about this, and I don't think it would be too hard to implement
this using inode tracking. However, it might incur more memory overhead. Input
is welcome.
I'm a former rdiff-backup user who gave up rdiff-backup for several
reasons that people have mentioned, including the renamed file problem
and difficultly recovering after the program aborted. I never took my
name off the mailing list because I wanted to see what would happen. I
ended up using storeBackup
(http://savannah.nongnu.org/projects/storebackup), which checksums every
file to find duplicates or renamed files, and uses hard links to avoid
storing multiple copies of identical data. When you have files 250GB and
larger, this is very important.
The list of checksums lets you verify the backup, which turned out to be
critically important for me. A bad stick of RAM was causing random bit
errors in the backup, and without that verification, I would have never
known (I learned my lesson and will be using ECC ram going forward). I'm
also working up a program to take advantage of the checksum list to help
me track down duplicate files
_______________________________________________
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
