I'd assume the average compression rate to be very low, no? Don't modern cryptosystems have to encrypt then compress to avoid some forms of attack, thus making the compression not very effective?
In the recent web attack instances, it's not just known plaintext, it's using compression to discover unknown plaintext by repeatedly guessing across multiple requests and watching for the request size to change. So an attacker would need the ability to alter your filesystem and make backup requests, repeatedly, for that attack to matter to Tarsnap.
The whole point to tarsnap is to be able to safely encrypt any and all of your data, including compressed data. We wouldn't expect that a .tar.gz being backed up is somehow "less secure" than the .tar file, we'd demand the same security for both.
Compression becomes a problem when it can be used as an "oracle" into the key used for a given stream of ciphertext. The reason TLS is susceptible is because the attacker can MITM and control at least some aspects of the plaintext or shared client-server state, and iterate repeatedly to refine their guesses.
These issues simply don't apply in the same way to backing up files.
I sure there are still theoretical issues that would need to be worked through in deciding how you'd do something like this, issues which could be better explained by any of the many crypto types who hang out here. But don't cargo cult your treatment of crypto.
A strong construction should be impossible to compress because encryption maximizes bit entropy, which should make the cyphertext indistinguishable from a PRF (ie a random noise source).
MAC, decrypt, decompress.... always^9 in that order.
Right, encrypt then compress is useless. And compress then encrypt is unsafe in some cases[1]. Apparently backup isn't one of them, you need to be able to choose the plaintext.
