[budmang]

I'm thrilled that we can offer this raw cloud storage for just $0.005/GB/month. Would love to hear from the Hacker News community what you do with storage today & what you might do with B2.

Here are my thoughts on our announcement today: https://www.backblaze.com/blog/b2-cloud-storage-provider/

Gleb

[acdha]

Do you have any plans to offer some sort of WORM model where you could “seal” a bucket, file, etc. to prevent future changes? This is really nice for protecting against malware, human error or malice, etc. and a regulatory requirement for certain industries.

[budmang]

We're at the very beginning of this journey, and heard from a lot of folks that they wanted access to inexpensive cloud storage. I imagine we'll learn a lot more about needs & use cases from people overtime. I can certainly understand the value of WORM storage and it is something we'll definitely consider adding. Appreciate the suggestion!

[2bluesc]

> Would love to hear ... what you might do with B2.

B2 finally creates an option for Linux users to use BackBlaze for back-up (at minimum) at work and at home. I look forward to that.

[brianwski]

A python command line tool that should work on Linux to send folders to B2 is available for download here: https://www.backblaze.com/b2/docs/quick_command_line.html

CAVEAT (PLEASE READ): this does NOT encrypt data yet!! This is just a quick technology demonstration, it isn't a polished backup client. Give us another month for that...

We expect Linux servers (and desktops) to make up a significant percentage of the things communicating to B2, so you can expect a lot more support than you have been getting from the traditional Backblaze Online Backup product line.

[voltagex_]

If I was going to tar and then gpg files, what would be the optimal "chunk size" from your point of view? Say I have 10GB that I'm encrypting and then splitting up, are you going to want 1GB chunks or many more 100mb chunks? (This also raises the question of how much data I want to lose to corruption...)

[brianwski]

I would recommend 1 GByte chunks for several reasons. The first reason is that you'll get very good throughput and efficiency at that large size. If you go as small as 10 MBytes we see long distances to our datacenter not "ramping up" fully. In other words, we can't get a single threaded application between New Zealand and California to get the advertised bandwidth for small chunks, but up at 1 GByte we DO get the advertised bandwidth. But if you go too large (like 5 GBytes) we have seen that you start seeing too high a percentage of uploads rejected because of bit errors occurring somewhere in the networking between your computer and our servers (the SHA-1 checksum won't match).

[2bluesc]

One thing to consider is using ecryptfs as I do for my data at rest. It's mounted as a (mostly) regular filesystem at ~/Private (or similar) and the encrypted files that serve as the backend (~/.private) are then uploaded to the cloud service of my choice. Currently using crashplan, but B2 would be nice to create archives/snapshots of my data instead of just syncing it as most consumer backup solutions do.

This is a very low friction way to have accessible data and have it encrypted by a fairly popular mechanism.

[lucb1e]

> Would love to hear ... what you might do with B2.

Back stuff up, but properly encrypted instead of your Windows client's closed source stuff. Without B2 I would use S3 but at their rate I might as well rent a datacenter myself, so I'm going to do the math again with B2 soon.

[sspiff]

Thank you for doing this. I've read some awesome stuff on Backblaze's infrastructure over the years, but never could use the service (a high level backup solution for Windows/Mac isn't so useful for me).

This announcement may mean I finally get to test your stuff! (I've been frustrated with the quality and feature creep in open source syncing solutions and procrastinating building my own, bare bones alternative).

[budmang]

Would love to have you do it...and hearing about how it goes!

[jafitc]

Is it me or there's no mention of durability?

Is this only for noncritical, reproducible data as S3 reduced redundancy?

[scott_karana]

Yeah, I'm really concerned about this too. I assume it's fairly good storage if they're dogfooding this for their backup product, but explicit is better than expectations in this case :)

[brianwski]

Brian from Backblaze here. In general we are shooting for about the same reliability as Amazon S3. Backblaze is really transparent about our redundancy and pretty much everything we do. We use 17+3 Reed Solomon across 20 computers in 20 different locations in our datacenter. You can read about it here: https://www.backblaze.com/blog/vault-cloud-storage-architect...

Also, we are the only company we know of that releases our drive failure rates. We release them quarterly, here is the most recent failure analysis: https://www.backblaze.com/blog/hard-drive-reliability-stats-...

And for the record Backblaze only has one datacenter. This bothers some customers deeply so if it is a show stopper definitely don't use Backblaze B2. We just want to be transparent about what we do and what we don't do. One idea is you could use B2 as a primary copy of the data, and make another copy into Amazon Glacier in case the Backblaze datacenter is hit by a meteor (or a terrorist attack or an airplane crashes into it).

Oh, I said this elsewhere but I have a lot of confidence we won't lose your data, we've been perfecting that for 8 years. What Backblaze DOESN'T have much experience in is serving up viral videos and the CDN (Content Delivery) layer. I'm looking forward to that layer, I think it will be fun to polish, but especially over the next few months of invite only beta anybody using B2 needs to be able to work with us to get the kinks worked out.