What's the point? Tarsnap is modestly cheap and extremely secure, and there other backup services which are equally cheap and almost as secure. Use at least 2x services always, so Tarsnap going down or bust (heaven forbid) isn't a big deal. There is never a perfect real-world solution, but risk mitigations that reduce risk at a higher levels of abstraction is how to get real, production-grade fault-tolerance the easier way than dredging up edge-case issues without offering usable alternatives.

SpiderOak uses end-to-end encryption, but I wouldn't trust it completely https://spideroak.com/opendownload

rsync.net is also pretty usable, but I wouldn't trust there is any in-flight or at-rest security http://www.rsync.net/

Tahoe LAFS provider https://leastauthority.com/ (it's possible to run your own Tahoe LAFS servers on cloud/colo boxes on several providers)

The best-practice mitigation to allow backups on less secure providers is encrypt locally (end-to-end encryption effectively) and distribute restore keys to a decent quorum of managers/founders/supervisors.

Having done offsite LTO tape vaulting and formal disaster recovery / business continuity planning at the organization level, it's a whole lot cheaper, easier and more flexible to use multiple cloud providers for most real use-cases (apart from multiple PiB datasets).

"rsync.net is also pretty usable, but I wouldn't trust there is any in-flight or at-rest security http://www.rsync.net/"

rsync.net service is only available over SSH, so there's your in-flight security.

An rsync.net filesystem is an empty filesystem for you to do with as you see fit, so encryption at rest is completely up to you.[1][2]

Related: rsync.net accepts ZFS send/recv over SSH.

As always, ask about the HN readers discount.

[1] duplicity.nongnu.org [2] https://raymii.org/s/articles/Set_up_your_own_truly_secure_e...

The point was that trusting all your backups to a one-man operation is not particularly wise, though cperciva provided more information. HA and using multiple services was not part of the conversation.

Being in a position where your off-site backups becoming unavailable is "not particularly wise" means you got _other_ problems to solve.

If my offsite backups vanished (the building they're in burnt down, for example) I'd a) know about it promptly, and b) arrange additional copies and security for my current set of on-site backups. Just the same if as if Colin gets hit by that bus and his service goes down without anyone knowing how to, or caring about, bringing it back up.

If Tarsnap is a single point of failure for you, you're doing it wrong.

Fault-tolerant backup architectures are cheaper and more reliable than depending on any one service, regardless of due-diligence outcome on them. Any shop of any sensible size/scale would mitigate risks accordingly, or risk losing all their data and going out of business within a few months.

The end.