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

Amazon Glacier

aws.amazon.com

Post reply on HN
Print view View original

341–350 of 393 posts

Re: Amazon Glacier

#341

Post by sintaks »

res0nat0r wrote: post #304
vl wrote: post #303

Earlier quoted context omitted.

But why there is retrieval delay then?

An uneducated guess? Maybe there is some type of spare storage pool just for staging the glaciar restore requests, and they've done the math to figure out how much space they need on average over time for this. The 24 hour storage expiration probably helps with this and they've calculated how much space they need to have on-hand and for spikes for restore requests and the restore delay helps factor in these demand sp…

Why wouldn't they stage in S3? :)

Re: Amazon Glacier

#342

Post by sintaks »

tomkarlo wrote: post #328
ricardobeat wrote: post #318

Earlier quoted context omitted.

If every request is delayed by the same amount, then it just moves the peak. Otherwise it just flattens/spreads it around peak_length + 4 .

I'm not talking load so much as network traffic. Companies like Amazon and Google have huge peak hour outbound traffic during US waking hours, and then a huge dip during off hours. If they can push more of the traffic into those off hours they can make the marginal cost of the bandwidth basically zero. So if you make a request at peak hours (say 12 noon ET), they just make you wait until 11 PM ET to start downloading…

Amazon has ridiculous internal bandwidth. The costly bit is external. The time delay is largely internal buffer time - they need to pull your data out of Glacier (a somewhat slow process) and move it to staging storage. Their staging servers can handle the load, even at peak. GETs are super easy for them, and given that you'll be pulling down a multi-TB file via the Internet, your request will likely span multiple days anyhow - through multiple peaks/non-peaks.

Re: Amazon Glacier

#343

Post by [deleted] »

ensignavenger wrote: post #296
ghshephard wrote: post #290

Earlier quoted context omitted.

I've spent several hours reading about this and talking with colleagues, reading the (really great) HN threads on the topic and doing a bunch of math - and I've come to the conclusion that rsync.net/backblaze/tarsnap/crashplan probably don't have too much to worry about for _most_ use cases. The wonky pricing on retrieval makes this inordinately complex to price out for the average consumer who will be doing restores…

Online backup for my photos and other data was my initial thought, but I'm afraid it would cost too much to do a restore- if I store 3 TB of photos/documents/etc for 2 years, then have a house fire (local backup destroyed), I want to be able to restore my data to my new computer as quickly as my Internet connection will let me, and I don't want to be stuck with a huge bill for retrieval on top of all the other expens…

[deleted]

Re: Amazon Glacier

#344

Post by anologwintermut »

tc wrote: post #222

Beware that retrieval fee! The retrieval fee for 3TB could be as high as $22,082 based on my reading of their FAQ [1]. It's not clear to me how they calculate the hourly retrieval rate. Is it based on how fast you download the data once it's available, how much data you request divided by how long it takes them to retrieve it (3.5-4.5 hours), or the size of the archives you request for retrieval in a given hour? This…

From a Wired article citing this post[1]

'Update: An Amazon spokesperson says “For a single request the billable peak rate is the size of the archive, divided by four hours, minus the pro-rated 5% free tier.”'

This seems to imply the cost is closer to 4k instead of 22k.However, the spokesperson's statement seems to describe intended system performance , not prescribe the resulting price. So if it actually does take them an hour to retrieve your data, you might still owe them 22k

[1]http://www.wired.com/wiredenterprise/2012/08/glacier/

Re: Amazon Glacier

#345

Post by sintaks »

DeepDuh wrote: post #319
g-garron wrote: post #206

Earlier quoted context omitted.

Yes I do it, I have the weekly and monthly. And yes, I might have daily-monday / daily/tuesday.... and so on, and it would work better, but this way works for me. There is a lot of room for improvement, and it is not hard to implement with cron-jobs and more buckets.

Do you know about worst case analysis? Let's say your data loss occurs on the Sunday, 31th of a month at 23:55 and then gets synched across all your S3 backups (or it could occur at some point before that but you don't notice it). And poof goes your data.

He could just turn on object versioning.

Re: Amazon Glacier

#346

Post by sintaks »

ghshephard wrote: post #180
g-garron wrote: post #176

Earlier quoted context omitted.

I use a combination of Dropbox and S3. I have my MacBook and a Linux server linked to my Dropbox account. So changes in my documents are synced to my Linux. My Linux run three cron-jobs. One daily, one weekly and another monthly. The command is. s3cmd sync --delete-removed ~/Dropbox/documents/ s3://backup-daily/ There are buckets for weekly and monthly too. Note: the command is not exactly like that, check the man pa…

One thing to be a little careful of - you are sending all of your data to S3, which is, of course, the backing store for Dropbox.

Dropbox stores their stuff in S3 a little different. It's not a 1:1 correspondence between user files and objects under Dropbox's S3 account. The fact that they use S3 as their backing store means very little. It certainly sounds good to have S3 in back when you talk about scalability and durability, but 1) they could just as easily use something else, and 2) depending on their sharding strategy, a single lost object could impact multiple files at the user level.

Re: Amazon Glacier

#347

Post by sintaks »

jordibunster wrote: post #269
sreitshamer wrote: post #160

Earlier quoted context omitted.

I'm looking into supporting Glacier in Arq. It sure is cheap -- $10/month for a terabyte.

I think the key here is not to just provide a toggle for using Glacier instead of S3, but to have the historical snapshots migrated to Glacier from S3 and deleted every 90+ days. I will gladly pay more money for Arq again.

Yes. The forthcoming S3 Lifecycle Policy API additions should allow for exactly this, automatically.

Re: Amazon Glacier

#348

Post by sintaks »

zach wrote: post #28

Amazon Glacier is an extremely low-cost, pay-as-you-go storage service that can cost as little as $0.01 per gigabyte per month. What would be absolutely fascinating is a pay-before-you-go storage service — data cryonics. Paying $12 to store a gigabyte of data for 100 years seems like a pretty intriguing deal as we emerge from an era of bit rot.

Data cryonics indeed. One of the early names kicked around (and, indeed, its working name for over a year) was Cold Storage.

Re: Amazon Glacier

#349

Post by sintaks »

phil wrote: post #24

Storage experts: I'd love to know more about what might be backing this service. What kind of system has Amazon most likely built that takes 3-4 hours to perform retrieval? What are some examples of similar systems, and where are they installed?

See my post up top: http://news.ycombinator.com/item?id=4416065

Re: Amazon Glacier

#350

Post by sintaks »

tezza wrote: post #34
phil wrote: post #24

Storage experts: I'd love to know more about what might be backing this service. What kind of system has Amazon most likely built that takes 3-4 hours to perform retrieval? What are some examples of similar systems, and where are they installed?

Typically they are tiered. There'll be a near-line HDD array. This is for the recent content and content they profile as being common-access. Then there'll be a robotic tape library. Any restore request will go in a queue annd when an arm-tapedrive becomes free they'll seek to the data and read it into the HDD array. Waiting for a slot with the robot arm - tape drive is what will take 4 hours. EMC(kinda), Fujitsu etc…

Close. Tiered, yes. But remember who we're talking about.

First, no tape. The areal storage density of tape is lower than hard disks. Too many moving parts involved. Too hard to perform integrity checks on in a scalable, automated fashion without impacting incoming work.

Second, in order to claim the durability that they do (99.999999999%), that means every spot along the pipe needs to meet those requirements. That means the "near-line HDD array" for warm, incoming data needs to meet those requirements. Additionally, if the customer has specified that the data be encrypted, it needs to be encrypted during this staging period as well. It also needs to be able to scale to tens if not hundreds of thousands of concurrent requests per second (though, for something like Glacier, this might be overkill).

They've already built something that does all that. It's called S3. The upload operations likely proxy to S3 internally (with a bit of magic), and use that as staging space.

After that, the bottleneck is likely I/O to Glacier's underlying storage - but again, not tapes. See this post for deets: http://news.ycombinator.com/item?id=4416065

Post reply on HN