Amazon Glacier • Hacker News Board

Re: Amazon Glacier

#381

Post by ghshephard » Wed, Aug 22, 2012, 8:24 PM UTC

sintaks wrote: post #373

ghshephard wrote: post #355

Earlier quoted context omitted.

The math doesn't come close to replacing tape - basically once you go north of 100 terabytes (just two containers - at my prior company we had 140 containers in rotation with iron mountain) Glacier doesn't make financial or logistical sense. Far cheaper and faster to send your LTO-5 drives via driver.

It may not make sense today. Amazon is notorious for betting on the far future. They're also raising the bar on what archival data storage services could offer. When you ship your bits to Amazon, they're in 3+ DCs, and available programmatically. Separate from the play for replacing tape, there's also the ecosystem strategy. When you run large portions of your business using Amazon's services, you tend to generate a…

Thanks very much for the insight - what you are saying actually makes a lot of sense in the context of systems inside the AWS ecosystem. After all, they need to archive data as well. Also - my 140 container example w/Iron Mountain was Pre-versioning and always-online differential backups. We basically had a complex tower-of-hanoi that let us recover data from a week, a month, six months, and then every year (going back seven years) from all of our servers. (And, by Year seven, when we started rotating some of the old tapes back in - they were a generation older than any of our existing tape drives. :-)

Clearly, with on-line differential backups - you might be able to do things more intelligently.

I'm already looking forward to using Glacier, but, for the forseeable future, it looks like the "High End" archiving will be owned by Tape. And, just as Glacier will (eventually) make sense for >100 Terabyte Archives, I suspect Tape Density will increase, and then "High End" archiving will be measured in Petabytes.

Thanks again.

Re: Amazon Glacier

#382

Post by ghshephard » Wed, Aug 22, 2012, 8:26 PM UTC

sintaks wrote: post #346

ghshephard wrote: post #180

Earlier quoted context omitted.

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…

Right - the point I was trying to make, is he was putting all his eggs in one basked. If anything catastrophic happened to S3, he might lose both his S3 as well as his Dropbox backups.

If you are going to the effort of having dual-backup systems, may as well try and find something that can't be impacted by a single disaster.

Re: Amazon Glacier

#383

Post by ghshephard » Wed, Aug 22, 2012, 8:29 PM UTC

chmars wrote: post #361

leejoramo wrote: post #223

Earlier quoted context omitted.

Arq is great backup software. I would view inclusion of Glacier support as a worthy paid upgrade. Arq is the pinnacle of my rather large backup pyramid which also includes: Dropbox, Superduper, Crashplan, rsync, SVN/GIT and more.

In an earlier version of Arq, there was no possibility to see which data was actually selected for backup (and which not). Has Arq become more user-friendly?

I'm a current user of ARQ, and it has, in my opinion (compared to Backblaze) a phenomenally user friendly description of exactly what is being backed up, and when, and when something was added, or modified.

Re: Amazon Glacier

#384

Post by ghshephard » Wed, Aug 22, 2012, 8:36 PM UTC

omh wrote: post #356

ghshephard wrote: post #355

Earlier quoted context omitted.

The math doesn't come close to replacing tape - basically once you go north of 100 terabytes (just two containers - at my prior company we had 140 containers in rotation with iron mountain) Glacier doesn't make financial or logistical sense. Far cheaper and faster to send your LTO-5 drives via driver.

Have you considered the cost of the tape loaders? Our loaders cost significantly more over their lifetime than the storage costs of the tapes themselves. The tradeoffs will be different depending on how many tapes you write and how often you reuse them.

Until I took over backups, and instituted a rotation methodology, the guy prior to me just bought another 60 AIT-3 tapes every month and shipped them off site to Iron Mountain.

Agreed - how-often you re-use tapes (and whether you do) - has a dramatic effect on "system cost" of your backup system.

Re: Amazon Glacier

#385

Post by prehnra » Wed, Aug 22, 2012, 9:53 PM UTC

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.

Yes please!

Re: Amazon Glacier

#386

Post by pbhjpbhj » Wed, Aug 22, 2012, 11:36 PM UTC

DeepDuh wrote: post #69

buro9 wrote: post #41

This is a really good offering for media that you typically will keep locally for instant access, yet you want to have an off-site backup in a way that lives for a very long time. Dropbox should work here, but it's simply too expensive. My photo library is 175GB. That isn't excessive when considering I store the digital negatives and this represents over a decade. I don't mind not being able to access it for a few ho…

sigh Dropbox should not be used as a backup system. A system that synchronizes live should never get that role, except if they can guarantee that old data is never overwritten, new is always appended. This is not the case with dropbox - I've experienced multiple scary occurrences of old versions going to the nirvana with certain user actions. In certain cases the old data just appears to be gone, in other cases the w…

>A system that synchronizes live should never get that role, except if they can guarantee that old data is never overwritten, new is always appended. //

Why don't Dropbox enable this use-case. It would surely be very easy to implement. I guess that pack-rat does do this in a way but seems like overkill.

I'd like something along the lines of duplicating all files but requiring confirmation of deletions and overwrites.

Re: Amazon Glacier

#387

Post by rmah » Wed, Aug 22, 2012, 11:52 PM UTC

wheels wrote: post #145

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…

> Governments of stable countries are obviously capable of this I don't consider that obvious. I live in Berlin, the capital of what most would consider a stable country, but my apartment (which is even older) has been a part of 5 different countries in the last 100 years (German Empire, Weinmar Republic, Nazi Germany, East Germany and finally, the Federal Republic of Germany).

No offense, but Germany is far from what I'd call a stable nation. It has, in fact, only been a nation for 141 years. and during that time has, as you've noted changed governments many times.

Re: Amazon Glacier

#388

Post by sintaks » Thu, Aug 23, 2012, 12:25 AM UTC

hga wrote: post #368

sintaks wrote: post #339

Earlier quoted context omitted.

Former S3 employee here. I was on my way out of the company just after the storage engineering work was completed, before they had finalized the API design and pricing structure, so my POV may be slightly out of date, but I will say this: they're out to replace tape. No more custom build-outs with temperature-controlled rooms of tapes and robots and costly tech support. If you're not an Iron Mountain customer, this p…

It wasn't built to back up your family photos and music collection. But at its price points, with most US families living under pretty nasty data cap or overage regimes, it sounds superb, with of course the appropriate front ends. There's no good (reliable), easy and cheap way to store digital movies, e.g. DVD recordable media is small by today's standards and it's much worse than CD-Rs for data retention (haven't be…

Not saying it couldn't be very useful for the data-heavy consumer. Just guessing this is more of an enterprise play than anything else. :)

Re: Amazon Glacier

#389

Post by sintaks » Thu, Aug 23, 2012, 12:27 AM UTC

ghshephard wrote: post #382

sintaks wrote: post #346

Earlier quoted context omitted.

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…

Right - the point I was trying to make, is he was putting all his eggs in one basked. If anything catastrophic happened to S3, he might lose both his S3 as well as his Dropbox backups. If you are going to the effort of having dual-backup systems, may as well try and find something that can't be impacted by a single disaster.

Ah, right - definitely.

Re: Amazon Glacier

#390

Post by sintaks » Thu, Aug 23, 2012, 12:46 AM UTC

rektide wrote: post #377

sintaks wrote: post #339

Earlier quoted context omitted.

Former S3 employee here. I was on my way out of the company just after the storage engineering work was completed, before they had finalized the API design and pricing structure, so my POV may be slightly out of date, but I will say this: they're out to replace tape. No more custom build-outs with temperature-controlled rooms of tapes and robots and costly tech support. If you're not an Iron Mountain customer, this p…

I wasn't holding my breath, but I was thinking there's a possibility they were using short-stroking to speed up most of their systems hard drives by making a quarantined barely touched Glacier zone in the inside of their drives: https://plus.google.com/113218107235105855584/posts/Lck3MX2G... My backup wouldn't it be cool if is, unlike the above reasonableness, a joke: imagining 108 USB hard drives chained to a poor P…

That would definitely be cool. Pretty unlikely, however. When it comes to hardware, they like to keep each service's resources separate. While a given box or rack many handle many internal services, they're usually centered around a particular public service. S3 has their racks, EC2 has theirs, etc. Beyond the obvious benefit of determinism - knowing S3 traffic won't impact Glacier's hardware life, being able to plan for peak for a given service, etc - I'm guessing there are also internal business reasons. Keeping each service's resources separate allows them to audit costs from both internal and external customers.

Then there's failure conditions. EBS is an S3 customer. Glacier is an S3 customer. Some amount of isolation is desirable. If a bad code checkin from an S3 engineer causes a systemic error that takes down a DC, it would be nice if only S3 were impacted.

I probably shouldn't go into the hardware design (because 1) I'm not an expert and 2) I don't think they've given any public talks on it), but it's some of the cooler stuff I've seen, especially when it came to temperature control.