Comment 21 for bug 490188

(dammit, I hit send by accident. I will continue here)

...picked by Canonical.

But then we have all the problems that just came up in this discussion:

- Need for periodical new backups
- Not a smart usage of space or bandwidth
- No post hoc hash checking of backups (which is related to the first and to the next problems), so no ability to truly trust what's actually on the backup (and this has burned me personally in the past)
- Not using potentially available resources, like the ability to run a little code on the server side
- Keeping anterograde instead of retrograde differential backups (as explained, a-la rdiff-backup)

Coupled with a couple of other problems that are not mentioned here...

- Not directly accesible files on the backup (which is a HUGE problem when duplicity decides it doesn't want to cooperate and open the files)
- (related to the last one) the fact that, even when not encrypted, the files are packed up causing a lot of hurdles and inefficiencies in the whole process as a whole.

...makes me increasingly think that the main problem here is the back-end, duplicity. And most of those are problems that, thanks to the decisions taken when creating the software, are probably unsolvable unless a radical 180 is done to the back-end code, and the way duplicity works.

The ideal for me of course would be if Deja Dup became "simply" the front end for more powerful backup solutions, like rdiff-backup, rsync, etc; giving those sorts of programs the usability (in a "set it and forget it" kind of way) they currently lack.

Anyways, I think this turned into mindless rambling, I was a little dissapointed that the particular problem this bug is talking about doesn't really have a solution.