some ppl have already started working on this and there's been activity on the mailing list lately about this topic.

however it's a dangerous feature to add in (backup tools should never screw up their storage, and this feature goes and removes things) so a lot of care is needed.

the boring answer is: it's coming, and we need a lot of help for vetting patches and testing them out.

I think naming backups and archiving the old files should be separate applications - that could be generic to whatever backup tool you decide to use.

And the reason they are not in bup is that those two things are the only hard things in a backup.

So they did the easy parts and skipped the hard parts.

Hardly a perfect backup.

I'm not sure a backup with all three of: delete old backups, encryption, and upload only differences even exists.

I think it might be one of those "pick any two" things, but if anyone knows of a backup with all three let me know.

Tarsnap does all of these.

At present I need backup software, not a backup service.

How are you calculating a diff of an encrypted file? I looked through the technical documentation but if it explains it I missed it.

Tarsnap splits data into context-dependent chunks, then compares them via their hashes to figure out what new data needs to be uploaded.

This is interesting, because the size of a file's encrypted chunks now leaks information about the file's plaintext. I suppose you have some minimum chunk size, and that's one way to keep from leaking too much information as a fraction of the overall file size. But if a file is modified many times, it seems to me that you'd have to be very careful not to leak a substantial amount of data to a clever attacker.

Have you thought about how to quantify this tradeoff?

I suppose you could pad each encrypted chunk so they're all the same size, but then if you don't want to waste a ton of space you'd have to restrict your chunking algorithm to output chunks with relatively similar sizes, at which point you lose some of the benefits of chunking.

The chunking is done using parameters generated from a secret key, and I haven't been able to see any way for it to be computationally feasible to extract meaningful information from the resulting block sizes.

That doesn't mean that it's impossible, of course; just that it would require someone smarter than me. ;-)