Re: [rdiff-backup-users] Restarting development ... or starting over

[Daniel Miller]

>>> 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

This is getting off-topic, but FWIW my "new version" of rdiff-backup keeps a 
checksum of every single file it writes (including "meta" files that contain 
rdiff-backup specific repository information). This information is kept to 
allow fast, full repository verification. I also plan to have rdiff-backup 
verify each file during a restore operation so you will know that the restored 
data is exactly what was backed up. Well, at least to a very high degree of 
probability ... SHA1 hash collisions can happen, but then again ECC RAM is not 
perfect either.

~ Daniel