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

311–320 of 393 posts

Re: Amazon Glacier

#311

Post by voltagex_ »

res0nat0r wrote: post #238
chmars wrote: post #232

Earlier quoted context omitted.

My question is not about the setup, that's OK. I am wondering why CrashPlan shows the encryption key in the clear and does not store it in the user or system keychain.

I'm assuming this because their desktop client is a java app and it it's been made to run on linux, mac and Windows. Is there such a thing as a keychain on Windows? I've only used it on linux and mac.

Yes, there's the CredWrite API - http://msdn.microsoft.com/en-us/library/windows/desktop/aa37..., although I must admit I like the OS X keychain a lot better.

Re: Amazon Glacier

#312

Post by Dylan16807 »

freehunter wrote: post #209
Dylan16807 wrote: post #198

Earlier quoted context omitted.

Oh I totally understand that people are going to be willing to pay more after a disaster to get files back. But realistically, if there is a large enough volume of files to bother amazon then they're going to need day(s) to download. If they rate-limited by day then the price would only reach a couple years of storage. The hourly thing is only going to bite minor retrieval events, and it is going to bite them amazing…

My department (information security) was actually just discussing this service this morning at our morning meeting. We've been looking into backup services for our security monitoring appliance beyond our datacenter and DR site. These backups would need to persist for a year according to PCI/SOX compliance, and if we needed to show data to an auditor, we wouldn't need the entire log. In fact, we'd likely not even nee…

It's not that I want to use this as hot storage, it's that I would like to be able to test my backups once or twice a year.

Re: Amazon Glacier

#313

Post by dredmorbius »

jonknee wrote: post #217
justincormack wrote: post #205

Earlier quoted context omitted.

Thailand.

They have had a military coup within the last decade, not exactly a bastion of stability.

The Thai king is the longest-reigning current head of state, ascending the throne on 9 June 1946. Elizabeth II of England is 2nd, 6 February 1952.

The oldest country (not government) is likely Vietnam (2897 BCE). Other contenders: Japan (660 BCE), China (221 BCE), Ethiopia (~800 BCE), or Iran (678 BCE).

Few of today's modern states pre-date the 19th Century, many antedate World War II or the great de-colonialisation of the 1960s including much of Africa and Oceana (some of the longest inhabited regions of Earth).

Among the more long-lived institutions are the Catholic Church (traditionally founded by Jesus ~30 AD, emerging as an institutional power in 2nd Century Rome). The oldest company I can find is Kongo Gumi, founded in 578, a Japanese construction firm. The record however is likely held by the Shishi Middle School founded in China between 143 and 141 BCE.

My own suggestion would be the Krell, though some might disqualify this based on a requirement for human organization.

Re: Amazon Glacier

#314

Post by narsil »

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

Earlier quoted context omitted.

Wait, do I understand this correctly: You sync your dropbox to S3? Do you overwrite your previous daily when you do so?

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.

You could try adding objects with the date in their names to a 'backup' bucket rather than create separate buckets for each backup. S3 also supports object expiration, so you can set your daily backups to expire after 7 days and weekly backups to expire after 4 weeks, for example.

Re: Amazon Glacier

#315

Post by dredmorbius »

bobsy wrote: post #154
arethuza wrote: post #150

Earlier quoted context omitted.

Sorry, what I meant by "stable" there is countries that have been relatively stable for a few hundred years and seem reasonably likely to continue that integrity for at least a century or so. Of course, predicting future stability is complete guesswork!

We are straying a bit off topic here. I don't think any country has been stable for a "few" hundred years. A few is 3. This is before the US was founded. I would say a stable country is one which has had a legit democracy for 70 or so years and doesn't share a border with a non-democratic / non-legit-democratic state. These two points suggests its unlikely to have a revolution or be invaded any time soon. Of course,…

I'll reject your democratic requirement out of hand, as democracies haven't proven particularly stable. There was that trial-run in Athens which lasted 501 years (508 - 7 BCE, with interruptions). Other than a few small/outlying instances (most notably the Althing in Iceland, it didn't re-emerge until the short-lived Corsican Republic (1755), and of course, the United States (1776).

Japan (660 BCE) and China (221 BCE) have both had feudal / bureaucratic governments exhibiting very high levels of stability. While dynasties and eras are marked, the overall states persisted largely intact.

Re: Amazon Glacier

#316

Post by driverdan »

jwr wrote: post #80
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…

What's even more important, you will be able to encrypt your backups without having to disclose the encryption key in case you ever need to restore (client-side encryption and decryption). This is not the case with Backblaze, which is why I switched to CrashPlan — but I'm still looking for other solutions.

The other feature that's great about CrashPlan is that it will allow you to backup to other systems running their software. I backup my laptop to both their service and one of my dedicated servers. That way if anything ever happens to their online service I have a second remote copy that I control.

Re: Amazon Glacier

#317

Post by [deleted] »

jwr wrote: post #80
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…

What's even more important, you will be able to encrypt your backups without having to disclose the encryption key in case you ever need to restore (client-side encryption and decryption). This is not the case with Backblaze, which is why I switched to CrashPlan — but I'm still looking for other solutions.

[deleted]

Re: Amazon Glacier

#318

Post by ricardobeat »

tomkarlo wrote: post #309
vl wrote: post #303

Earlier quoted context omitted.

But why there is retrieval delay then?

Having a multi-hour delay in retrieval lets them move it into their off-peak hours. Since their bandwidth costs are probably calculated off their peak usage, a service that operates entirely in the shadow of that peak has little to no incremental cost to them.

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.

Re: Amazon Glacier

#319

Post by DeepDuh »

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

Earlier quoted context omitted.

Wait, do I understand this correctly: You sync your dropbox to S3? Do you overwrite your previous daily when you do so?

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.

Re: Amazon Glacier

#320

Post by DeepDuh »

Dylan16807 wrote: post #199
DeepDuh wrote: post #151

Earlier quoted context omitted.

It doesn't matter whether he notices it or not, you can't count on social factors when it comes to backup systems. He might notice it but then he thinks, oh no problem, it's all in Dropbox anyway, I'll talk to Dylan16807 when he gets back. I've never had any complete data losses until now, but I've had this situation where the Dropbox cache was the only place to retrieve files twice and it showed me that it can't be…

I just want to understand better why you had to resort to the cache. The only time I've ever done that was when I accidentally deleted a bunch of data and didn't want to restore each file by hand or put in a support ticket.

I can't quite put my foot down on what the scenario is exactly. One time might have been a case where a folder with lots of small files got moved away and Dropbox only allows single file restore, which would have taken hours, possibly longer than the lost work. Once I've done something stupid where I wanted to exchange a whole Dropbox folder with a different version. I switched off the client on one PC (by mistake, obviously) and exchanged the folder on the other, then switched it on again. Then I became aware the the old folder had important stuff in it. The versioning was corrupted at that point, many old files would either not show up online or would produce an error message.

So usually there is some user behaviour involved, yes. But the whole point of a backup system is that you can rely on it, even when the user behaves stupidly up to a certain degree. Sync is for day to day collaboration and data management, it's not for backup.

Post reply on HN