corrupt backups and what lessons to learn from it

["jan teichmann googlemail com" <jan teichmann gmail com>]

Dear Deja-Dup developers,

Firstly and most importantly, thank you all very much for maintaining a great backup software. In my opinion a simple and convenient backup solution is crucial for the success of the gnome desktop.

The reason why I'm writing you is because I had to learn the hard way what it means when backups fail. I use Deja-Dub to do daily backups of my PhD data to a network drive within the university (Fedora 17 with Deja-Dub 20.2 and duplicity 0.6.18)

Unfortunately, I lost the data on my hdd due to hardware failure but knowing that I have backups gave me piece of mind. But when I tried to restore my data I had a rather terrible surprise: The backups are corrupt and I have "SHA1 hash mismatch for file" errors. The real problem is that literally all backups are not usable as at least one volume file has an invalid hash.

When I decided to use Deja-Dub for my backups I trusted the software to be reliable. Now I am of course rather frustrated and losing important data is in this case not fully without consequences for me. I cannot change the fact that parts of my data are gone and I don't think you are to blame for it but I would like to suggest some improvements to the software. Keeping in mind that a backup solution is a very sensitive piece of software which should be well tested and function reliably the most important question is 1) why were all backups corrupt with plenty of volume files having invalid hash.

2) Deja-Dub needs to be more verbose on what it is doing. I would like to illustrate that with a screenshot:

This is rather confusing: It says the backup failed (which is serious) but the only additional information deja-dub provides is "Success". I hope the purpose of deja-dub is not secretly failing backups ;)

3) Deja-Dub should have an option to verify backups. To find out the hard way that the backup is corrupt isn't helpful when you try to restore data.

4) I think Deja-Dub should verify any previous backup before it does incremental backups.

5) When restoring files and one of the volume files is corrupted it is not very user friendly to just fail the restoring process. Instead Deja-Dub should show which files are effected by the damaged volume file and check whether a version could be restored from a preceding backup. The user should then have the option to restore selected files from older backups if he/she wishes to do so. 


I wish I could contribute with own code but I would break more than improve it ;)
I'm sure most of my points are not new to you and probably already on the roadmap of a coming version. Nevertheless did Deja-Dub fail its job here. And that the loss of data wasn't all for nothing I hope I was able to raise the importance of making backups more reliable than just simple. 


With the best regards,
Jan