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

251–260 of 393 posts

Re: Amazon Glacier

#251

Post by cynicalkane »

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…

For an allegedly "simple" archival service, that's a bizarre pricing scheme that will be hard to code around. If you wrote an automated script to safely pull a full archive, a simple coding mistake, pulling all data at once, would lead you to be charged up to 720 times what you should be charged!

Re: Amazon Glacier

#252

Post by smacktoward »

arethuza wrote: post #101
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.

"Paying $12 to store a gigabyte of data for 100 years" I'm not sure what kind of organisation I'd actually trust to store data for that length of time - a commercial organisation is probably going to be more effective at providing service but what commercial organisation would you trust to provide consistent service for 100 years? A Swiss bank perhaps? Governments of stable countries are obviously capable of this (cl…

If you really want the organization to survive for a long term, you need to make it a religion.

If you can figure out a way to convince a few dozen people every decade that the best way to glorify God is to isolate themselves off somewhere maintaining your archival data, you'll be set for centuries.

Re: Amazon Glacier

#253

Post by dustingetz »

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…

its not reasonable to draw conclusions from the parent without comparing to the cost of archiving and retrieving 3TB on other services.

Re: Amazon Glacier

#254

Post by backwardm »

sreitshamer wrote: post #160
ghshephard wrote: post #36

I'm a long time user of backblaze, and I'm a big fan of the product - it does a great job of always making sure my working documents are backed up, particularly when I'm traveling overseas, and my laptop is more vulnerable to theft or damage. With that said - Backblaze is optimized for working documents - and the default "exclusion" list makes it clear they don't want to be backing up your "wab~,vmc,vhd,vo1,vo2,vsv,v…

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

Just FYI, I too would view Glacier support as something worth a normal upgrade fee. I am using Arq more as a long-term back-it-up-and-forget-about-it storage solution anyway, so it seems like a natural direction to go for a user like me (same strategy, but even lower cost).

That said, I am reminded that I should not forget about the Arq backups and do a few test restores sometime. :)

Re: Amazon Glacier

#255

Post by greedo »

chmars wrote: post #239
acdha wrote: post #236

Earlier quoted context omitted.

Right, which is a largely meaningless distinction: if the process runs as you, any successful attacker can simply read it out of the CrashPlan process in memory. Again, if you're not typing the password in every time, a local compromise is almost certainly game-over. Apple's keychain helps reduce the damage if the data's not actively used but for something like CrashPlan which is always running the attacker is probab…

I agree that showing the encryption key in the clear is not a serious security flaw but it's IMHO against best practice. Passwords and key are usually shown in an obscured form, usually with asterisks, and stored in the user or system keychain. You are absolutely right that the security value of these standard practices should not be overvalued but still … what else within the security framework of CrashPlan is not d…

There have been sound arguments made against obscuring password entry.

Re: Amazon Glacier

#256

Post by greedo »

kondro wrote: post #90
ghshephard wrote: post #36

I'm a long time user of backblaze, and I'm a big fan of the product - it does a great job of always making sure my working documents are backed up, particularly when I'm traveling overseas, and my laptop is more vulnerable to theft or damage. With that said - Backblaze is optimized for working documents - and the default "exclusion" list makes it clear they don't want to be backing up your "wab~,vmc,vhd,vo1,vo2,vsv,v…

Home-use is probably the only situation Glacier is good for backup though. A home user is fine with a 3.5-4 hour window before their backup becomes available for download (as it will probably take them days to download it anyway). In a corporate environment, I don't want to wait around for 3.5-4 hours before my data even becomes available for restore in a disaster recovery situation. Seems good for archive-only in a…

In a corporate environment where you have low RTO goals for DR scenarios, relying on backups instead of replicated SAN etc is not a sound practice, especially with large data sets.

Re: Amazon Glacier

#257

Post by njharman »

regularfry wrote: post #19

What does "99.999999999% durability" mean? Does it mean they allow themselves to lose one byte per terabyte on average?

It means (as always) you should have your data in 2+ locations stored by different services/vendors/etc.

Re: Amazon Glacier

#258

Post by wvs »

thebigshane wrote: post #250
arethuza wrote: post #127

Earlier quoted context omitted.

Probably what would be required is an array of arrays of separate storage providers and services providing "RAID" on top of these storage providers - and you won't want to trust any of these you'll want a few of them... (hence the array of arrays).

Wow, does any service offer something like that? RAID6 would be pretty interesting across s3, google drive, (hrmm, what else? skydrive? rsync.net?)

https://tahoe-lafs.org/

Re: Amazon Glacier

#259

Post by reddit_clone »

andyjohnson0 wrote: post #179
arethuza wrote: post #101

Earlier quoted context omitted.

"Paying $12 to store a gigabyte of data for 100 years" I'm not sure what kind of organisation I'd actually trust to store data for that length of time - a commercial organisation is probably going to be more effective at providing service but what commercial organisation would you trust to provide consistent service for 100 years? A Swiss bank perhaps? Governments of stable countries are obviously capable of this (cl…

There are some pretty old commercial organisations out there. One list [1] has several that have existed for over 1000 years. Whether they would be capable of storing data (or would even be interested in doing so) is hard to say, but there have at least demonstrated that long-term organisational continuity is possible, and that presumably requires some organisational 'memory'. Having a long history obviously isn't a…

How about Catholic church? That has lasted a couple of Millennia!

Re: Amazon Glacier

#260

Post by toomuchtodo »

pgeorgi wrote: post #148
yungchin wrote: post #77

Earlier quoted context omitted.

The only issue I see is that verifying archive integrity (you don't want to find out the archive was bad after you lost the local backup...) would be somewhat complicated, given their retrieval policies. Also, the billing for data-transfer out plus peak retrievals sounds so convoluted, I can't begin to work out what a regular test-restore procedure would cost me. Nevertheless, it's some exciting progress in remote st…

They could provide salted hash verification: send some salt, get a list of files with SHA1(salt | filedata) via email some hours later (so they can do the verification as a low priority job). The salt is used to prevent amazon from just keeping the hashes around to report that all is well. To avoid abuse, restrict the number of free verification requests per month.

Or just build the verification into the storage system, and send a SNS message if data loss has occurred (just like what happens when a Reduced Redundancy object has been lost in S3).
Post reply on HN