291–300 of 393 posts
0.01S+max(0,7.20*(R-0.0017S)/4)
S is number of GB stored
R is biggest retrieval in the month
4 is the average number of hours a retrieval
For an example with 10TB storage (replace 10000 to change): http://fooplot.com/plot/4pu7u2gpox
x is biggest retrieval in GB, y is $/month
Earlier quoted context omitted.
If you can afford 10Gbps to the internet, $22k is probably chump change.
10Gbps EC2 instances start at $0.742/hour. Welcome to the cloud. ;-) I assume the cost is in retrieval though and counted per the Job Creation API, regardless of whether and how quickly you download the data. but you're right that the 3TB/hour use-case is very hypothetical. Internet archival is just not suitable for those kind of volumes. I think the point OP was making that mistakes like using archives that are too…
If you actually USE 10gpbs your data transfer bill is going to be around $167k per month (That's for transferring 3.34PB).
Actually, a bit higher than that since I calculated all based on the cheapest tier EC2 will quote on the web, 5 cents per gigabyte.
For a one time 3TB download to an EC2 instance, priced at the first pricing tier of $0.12/gigabyte, that transfer will cost $360, and take around 40 minutes.
Earlier quoted context omitted.
I personally believe that data should never be deleted (or overwritten), but only appended to. Kinda like what redis/datomic does. So, keep live data onsite, along with an onsite (small) backup, and all the old data in Glacier.
You can believe that, but legal realities dictate otherwise. There are certain classes of information that you are not permitted to keep beyond a defined horizon, either temporal or event-based. Legal compliance with records management processes means having the ability to delete or destroy information such that it cannot be recovered. Note that if the information is encrypted, you can just delete the decryption key…
Earlier quoted context omitted.
This was interesting to wake up to this morning ... Right now we sell 10TB blocks for $9500/year[1]. This works out to 7.9 cents/GB, per month, so 7.9x the glacier pricing. However, our pricing model is much simpler, as there is no charge at all for bandwidth/transfer/usage/"gets", so the 7.9 cents is it. 7.9x is a big multiplier. OTOH, users of these 10TB blocks get two free instances of physical data delivery (mail…
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…
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.
Earlier quoted context omitted.
This was interesting to wake up to this morning ... Right now we sell 10TB blocks for $9500/year[1]. This works out to 7.9 cents/GB, per month, so 7.9x the glacier pricing. However, our pricing model is much simpler, as there is no charge at all for bandwidth/transfer/usage/"gets", so the 7.9 cents is it. 7.9x is a big multiplier. OTOH, users of these 10TB blocks get two free instances of physical data delivery (mail…
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…
Earlier quoted context omitted.
Yes, that's what I am thinking: a week of backups to S3 and a script that does moves the oldest one from S3 to Glacier. You would rarely need a backup older than a week if you've already got a week of backups. I'm still figuring out if there is a practical way to do this with incremental backups without introducing to much risk that the backup process gets messed up.
"In the coming months, Amazon Simple Storage Service (Amazon S3) plans to introduce an option that will allow you to seamlessly move data between Amazon S3 and Amazon Glacier using data lifecycle policies."
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…
One recurrent issue with Amazon services is that they charge in US$ and currently do not accept euros. European banks charge an arm and a leg for micropayment conversions: last time I got a bill from AWS for 0.02$ it ended up costing me 20 euros or so. Pretty much kills the deal. One solution could be to pre-pay 100$ on an account and let them debit as needed.
Earlier quoted context omitted.
No sigh was necessary, I understand. I even mentioned that I have a NAS and off-site backup... so either you didn't read it all or you stopped the moment you encountered the word "Dropbox" and started typing. That said, people DO use DropBox as backup. If you take a walk around the British Library and asked every PhD student working there how they "Backup" their research and work in progress, I bet every single perso…
"I even mentioned that I have a NAS and off-site backup... so either you didn't read it all or you stopped the moment you encountered the word "Dropbox" and started typing." No offense, but this post doesn't quite match what you wrote originally. My sigh was in response to the phrase "Dropbox should work here, ...". You didn't state security as your concern as to why not use Dropbox, rather it was cost. This might le…