Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tarsnap outage postmortem

mail.tarsnap.com

Post reply on HN
Print view View original

141–150 of 338 posts

Re: Tarsnap outage postmortem

#141

Post by mekster »

RockRobotRock wrote: post #84
mekster wrote: post #29

Earlier quoted context omitted.

It's insane. Not sure how anyone can accept such a rip off pricing. Tarsnap : $0.25 / GB storage, $0.25 / GB bandwidth cost rsync.net : $0.015 / GB storage, no bandwidth cost s3 : $0.023 / GB storage, some complicated bandwidth pricing If tarsnap is built on top of s3, they're charging 10 times for the storage cost. Easy money from the uninformed?

>Easy money from the uninformed? I don't think so. Anyone who can use this software I'm sure knows what other options exist.

Then I'd like to know what they think of the benefit of spending $25/mo for just 100GB.

Re: Tarsnap outage postmortem

#142

Post by ilyt »

JimDabell wrote: post #74
crossroadsguy wrote: post #37

Earlier quoted context omitted.

Well while I use Tarsnap for a very small amount of data (due to pricing) and I quite like Tarsnap for my use-case scenario, your question might have been downvoted due to two reasons: - your comment was a very valid question but rather quip-like, offhanded, seemed off etc etc. I mean something like that… - Tarsnap is an hn darling If I have to pick one I think it’s the latter :)

There’s also the fact that he has quite publicly been repeatedly nagged to raise his prices by another “HN darling” and he has been resistant to it. It’s actually quite an interesting read that covers a lot of the things brought up in this discussion: https://www.kalzumeus.com/2014/04/03/fantasy-tarsnap/

To be fair, any backup service should probably best have model of "pay per length of backup stored".

If I want to store my 100GB of data now, and I want to have it stored for a year, I want to pay for that year's worth of storage of 100GB of data now and not worry about any money or account problems for that bit of data.

Re: Tarsnap outage postmortem

#143

Post by bombcar »

baz00 wrote: post #115
tialaramex wrote: post #102

Earlier quoted context omitted.

Ideally, the thing you do in an emergency is largely routine, so that it happens by instinct rather than being a special case you need to remember. It should not be different in arbitrary ways. For example in both trains and cars, thanks to anti-lock braking, the correct way to stop the vehicle ASAP is to brake just like normal but as hard as you can, the computers will automatically solve the much trickier problem o…

This is terrible. Instinct cannot be trusted. Write it down.

There are two types of emergencies - checklist ones, and panic ones. You need to have both, but realize that in the panic ones people do NOT operate rationally.

This is why house doors open in but business doors have to open out - if there’s a crush against a fire door it opens.

You even see this in aviation, where everything is checkisted; the pilots will first stabilize the plane in an emergency and then run the checklist. And small plane that operate unexpectedly are always higher in crash rates.

Re: Tarsnap outage postmortem

#144

Post by zetalyrae »

throwawaaarrgh wrote: post #139
ilyt wrote: post #132

Earlier quoted context omitted.

The "fancy" option here is trying to act S3 to act like database instead of simple blob storage...

Fancy would be writing an application to talk to RDS, creating an RDS instance, creating a database, creating whatever IAM link is needed for auth into the db so you don't need a second set of credentials, creating a schema, creating columns with different data types, and then modifying the application to handle edge cases for the different data types, logic to insert, update, delete rows, select items, yadda yadda y…

[flagged]

Re: Tarsnap outage postmortem

#145

Post by bluehatbrit »

Tepix wrote: post #116
mike_d wrote: post #12

Earlier quoted context omitted.

This was an extremely well written and thoughtful postmortem, but I hope to never see one from you again. :)

It was a postmortem without the mandatory "how can we prevent this in the future" steps…

I think that's a little unfair given what was in the postmortem. It may not be a separate section with the key points, but the information is all there of what the issues were and what the solutions are. I think it's fair to assume they're actually acting on those without them needing to be reiterated at the bottom of the page.

Re: Tarsnap outage postmortem

#146

Post by throwawaaarrgh »

zetalyrae wrote: post #138
throwawaaarrgh wrote: post #129

Earlier quoted context omitted.

Forget about software or data architecture. S3 is the most reliable data storage mechanism in the world, and insanely simpler than a relational database. There is no operational failure mode to S3, other than "region went down". There is no instance to go down, no replication to fail, no worry about whether there's enough capacity for writes or too many connections, no thought to a schema, no migrations to manage, no…

>S3 is the most reliable data storage mechanism in the world S3 is not the problem here. The problem is building a database on top of S3 , and having to reimplement all the consistency, atomicity, transactions etc. on top. >no thought to a schema, no migrations to manage There is, in fact, always a schema. Some people choose to ignore it's there, to their detriment. >Always avoid the fancy option when it makes sense.…

> having to reimplement all the consistency, atomicity, transactions etc. on top.

Did you miss where I said it's read-after-write strongly consistent?

Re: Tarsnap outage postmortem

#147

Post by ilyt »

gnfargbl wrote: post #58
RockRobotRock wrote: post #13

Aren't these storage prices absurd? Please let me know if I'm misunderstanding.

The prices are absurdly high if your use-case is storage of large volumes of data that regularly change. It wouldn't be sensible to use Tarsnap for that, and you probably want to use one of the bulk backup services instead. Tarsnap makes a lot of sense when you benefit from the encryption and (especially) de-duplication features that it offers. For me, all of my most important personal and business data, from multipl…

That if there was zero other options that offer encrypted backups, but other software offers that too. Many also offer deduplication. And deduplication is less of a needed feature if you dont pay thru the nose for GB

Re: Tarsnap outage postmortem

#148

Post by zetalyrae »

throwawaaarrgh wrote: post #146
zetalyrae wrote: post #138

Earlier quoted context omitted.

>S3 is the most reliable data storage mechanism in the world S3 is not the problem here. The problem is building a database on top of S3 , and having to reimplement all the consistency, atomicity, transactions etc. on top. >no thought to a schema, no migrations to manage There is, in fact, always a schema. Some people choose to ignore it's there, to their detriment. >Always avoid the fancy option when it makes sense.…

> having to reimplement all the consistency, atomicity, transactions etc. on top. Did you miss where I said it's read-after-write strongly consistent?

Having those things at the base layer is not the same as having them in higher-level behaviour. This is why God invented SQL transactions.

Re: Tarsnap outage postmortem

#149

Post by rocqua »

VWWHFSfQ wrote: post #120
k8sToGo wrote: post #99

Earlier quoted context omitted.

If the data is super important you should be setting on two different providers anyways for backups.

Honestly, whose data isn't "super important"?. All my data is super important. Even the crap I just throw on my Google drive. I want to keep it. What is this mythical unimportant data that people still want to back up?

My nginx config is not super important. My old reports written for study are not super important. My pirated movie copies are not super important.

These are examples of data that I could easily live without. Where losing it would either be a matter of re-doing old work, or just forgetting about old and minor things.

Re: Tarsnap outage postmortem

#150

Post by bastawhiz »

zetalyrae wrote: post #138
throwawaaarrgh wrote: post #129

Earlier quoted context omitted.

Forget about software or data architecture. S3 is the most reliable data storage mechanism in the world, and insanely simpler than a relational database. There is no operational failure mode to S3, other than "region went down". There is no instance to go down, no replication to fail, no worry about whether there's enough capacity for writes or too many connections, no thought to a schema, no migrations to manage, no…

>S3 is the most reliable data storage mechanism in the world S3 is not the problem here. The problem is building a database on top of S3 , and having to reimplement all the consistency, atomicity, transactions etc. on top. >no thought to a schema, no migrations to manage There is, in fact, always a schema. Some people choose to ignore it's there, to their detriment. >Always avoid the fancy option when it makes sense.…

> having to reimplement all the consistency, atomicity, transactions etc. on top.

Most of those problems are moot if you're only ever writing from a single head node. If all your data is strictly ordered and you have no meaningful concurrency, this is a far, far simpler system.

Post reply on HN