If you want more than 3 nines availability neither Backblaze nor Tarsnap nor any other outside service would be able to serve your needs.
Also, parent is talking about ingestion. If your backups aren't configured well and the backup process fails, then your backup may not end up durable.
I also don't think your definition of reliable is generally recognized, which I'd generally call durability. I wouldn't say the scenario above is a durability failure, but an example of the consequences of poor availability.
That's a fallacy right there. Your assumption should be that any service you rely on will be down once in a blue moon, and possibly for a day or even longer.
> Also, parent is talking about ingestion. If your backups aren't configured well and the backup process fails, then your backup may not end up durable.
Yes, indeed, you need to do your work and you don't get to point at others for not doing it right.
> I also don't think your definition of reliable is generally recognized, which I'd generally call durability.
Reliability, durability and availability are all industry terms and have very clear definitions. These are not the same definitions that you would use in ordinary conversation with laypeople but when we're talking shop those are definitely allowed.
> I wouldn't say the scenario above is a durability failure, but an example of the consequences of poor availability.
No, it is a consequence of poor engineering on the part of the user of the service, and is a completely different issue. You engineer your service to ensure that your assumptions hold true and if you fail at doing that your service will fail. When is then only a matter of time and combination of circumstances, but fail it will.
The entire service going down for 24 hours due to a reboot is not a consequence of poor engineering on the part of the user. A production service which people rely on for critical data failing on the _textbook_ example of running a live service is poor engineering on the services part.
Tarsnap makes very particular guarantees, if you look into that then you'll realize that for some applications it is very useful and for other applications it is not, or that you may have to use not one but multiple backup services to be able to serve all your needs. This can be costly.
Availability and correctness are fundamentally opposed. The word "reliable" is contextual.
A backup service that is always available but serves up garbage is not as reliable as one that serves me the correct data, but only on Mondays.
That's a cheap shot, it's been as reliable as the underlying fabric, the only thing that really stood out for me is how utterly weird HN is when it comes to determining what constitutes reliability: no data was lost other than a tiny bit that was in inbound transit which can still be recovered (and which you could not realistically protect against). Note that this is a backup service and not something that is normally found in your primary business processes. As such if it stores the crown jewels safely, allows for them to be restored if and when needed and doesn't leak them in the meantime that's mission accomplished.
> or cost effective.
That depends on your use case, and not everything is about cost. The way it is set up I think the trust factor that even Colin can't read your data and that there will always be a way to get your data back out if you should need it is what matters. Backups that don't work are a net negative, a backup that does work can be, given the right circumstances, absolutely priceless.