5 ms·
If this is purely backup data, wouldn't glacier be a better fit than either S3 or B2? Glacier is already cheaper than B2 and has the advantage of storing data
by dgemm 7y ago
If this is purely backup data, wouldn't glacier be a better fit than either S3 or B2?
Glacier is already cheaper than B2 and has the advantage of storing data redundantly across datacenters. And glacier deep archive is 4 times cheaper than that.
Full disclosure: AWS employee
- mrtesthah 7y agoRestoring anything from glacier is a pain in the ass due to all the arbitrary restrictions that apply.
- snissn 7y agoNo - the pricing on glacier makes it a steaming pile of shit
- dgemm 7y agoIt's built for off-site backup type workloads, where you write once and read hopefully never. You are probably using it wrong.
- deleted 7y ago[deleted]
- camtarn 7y agoI was pleasantly surprised to see that the previous rather crazy retrieval pricing model (price based on the peak retrieval bandwidth you used at any time in the current month) was replaced by a straight price-per-GB model a couple years back. That made my life a lot easier when pricing up Glacier vs B2 for a client.
- CherryJimbo 7y agoThey're "backups" in the sense of storing customer data, but realistically they're more like instance snapshots for various customer game servers. They're created and restored multiple times a day for every customer as they hop between games (accessed very frequently), so Glacier wouldn't be a good fit.
- hrez 7y agoIf it's that much churn, wouldn't it make sense to point new writes/updates to B2 and let s3 naturally drain/lifecycle out its data?
- Twirrim 7y agoB2 didn't used to be multiple ADs, or at least not multiple ADs over a wider geographic area, like AWS's regions. I'm not sure if that's changed at all. It used to be why B2 was able to be cheaper. You were paying for less durability and availability. S3 storage is redundant over an entire region. Entire availability zones can go down (extremely improbable) without your data being put at risk. It, therefore, struck me as odd to see: > Due to S3 and B2 being at least nearly equally* accessible, reliable, available, as well as many other providers, our primary reason for moving our backups now became pricing. but then ... > * Science is hard, blue keys on calculators are tricky, and we don’t have years to study things before doing them WTF? They're trying to be joking here I hope, but that comes across somewhat "We don't give a crap about our customer's data".
- gregorysudderth 7y agoSorry for the bad vibe. I was trying to interject some humor into a dry process. When I asked a couple peers from my storage background, "how would you do this project" they both said the same thing: 1) form a working group 2) do a study 3) test 4) 90 days later, do an analysis. Epic process. We care a lot, but that's beyond our scope. This was an all-hands reviewed process, and like machines that are built to be ultimately reliable including: hospital generators, human-rated spacecraft equipment, airplane engines for single-engine remote location flying (PT6), our process was detuned speed-wise specifically, for overall service reliability and minimal impact. We tested, we analyzed, we saw weird failures (python core dump?) in simple code, and followed up on all of those before proceeding. We agonized. In the end we were satisfied, because our customers couldn't tell anything changed, and our CSR's got zero new tickets. Not bragging at all, relieved of course, but, we care about the CSR's load and work experience too. Thanks for checking the article out, and let me know if we can show you more about our service.