back
70 comments
If Backblaze is reading this, one feature missing from the b2 CLI is an rsync option.

Google Cloud Storage provides gsutil rsync, which is helpful for uploading large folders. Bonus points for checksumming.

Edit: I hear that HashBackup provides rsync capabilities with b2.

We're definitely reading this ;-)

Appreciate the feedback and we'll take a look at that rsync utility. We're also working on a simple client app that will do rsync with B2.

We're also starting to work with partners to offer a variety of other integrations. Duplicity and HashBackup have integrated B2, and Duplicati has an early alpha version. Someone is working on a FUSE integration. So hopefully soon there will be many ways to use B2. We'll list them here: https://www.backblaze.net/b2/docs/integrations.html

Please keep sharing feedback of what you need and how you'd use it!

Gleb from Backblaze

Woah. I opened the bug request (https://bugs.launchpad.net/duplicity/+bug/1498877) for Duplicity. It's so cool to see that y'all must've noticed. I'm definitely hoping to do what I can to help drive your presence on Linux!
Yev from Backblaze here -> We read everything. Already have some integrations working, keep an eye on -> https://www.backblaze.com/b2/docs/integrations.html and https://github.com/backblaze for updates!
+(a bigger number than I can think of right now)

For people on a slow connection, rsync plus cheap storage is going to be a really big deal. Here's hoping it happens!

+2
How is durability compared to S3 and Google? Any guarantees on availability?

How about speed, both on upload and download? It looks like this is geared for less frequent access than other services.

Yev from Backblaze here -> We're designing to have 8 "9's" of durability. Our speed tests have been pretty good thus far, but like with our online backup product it's best to just try it and see how quickly you can get to and from it.
Disingenuous of them to not compare their pricing to Google Nearline[1] or AWS S3 Infrequent Access[2] or AWS Glacier[3] given their price points ($0.01/GB/mo, $0.0125/GB/mo, $0.007/GB/mo) are much more competitive with B2 price-wise. Talk about stacking the deck in your favor.

Makes me leery of even trying it (what other things are they covering up?) or moving my tens of petabytes over there, despite my intense interest.

[1] https://cloud.google.com/storage/docs/nearline

[2] https://aws.amazon.com/s3/

[3] https://aws.amazon.com/glacier/

Those are great services and we actually mention them just a bit lower on the page. In the chart, we're comparing apples-to-apples: real-time cloud storage services.

Nearline, S3-IA, and Glacier are all made for 'infrequent access'. All charge you for deleting files and retrieving files (on top of bandwidth.) Near line has a 3 second latency to first file and Glacier has a 4 hour wait. S3-IA has a minimum file size they charge for.

All of those restrictions might be fine...just depends on the use case. But B2 is designed to be used not only for 'infrequently accessed' files...but also for frequently accessed ones.

And all of other services are still 40% - 250% more expensive for their base storage costs.

Hope that helps. Not trying to hide anything and we'd love to have you give Backblaze B2 a try. (And to provide us feedback or ask us questions about anything else!)

Gleb from Backblaze

B2 has plenty of limitations, too. Like being single datacenter. I wouldn't disqualify it from a list like this just because it's "different".

Each of the services on the list have their upsides and downsides, and none of them are anywhere near apples-to-apples.

What they all are are cloud-based key-value storage, each with their own tradeoffs, including price. So include all the major ones so your clients can make an informed decision and you don't look like you're completely unaware of your own competitive landscape.

We're trying to build a service that's more akin to Google Cloud Service and Amazon S3, not Nearline, IA, or Glacier. Those all have certain limitations (like time to access your data) that we are trying to avoid, which is why we didn't price against them and instead priced against the services we're trying to actually provide an alternative to.
So for that chart, you're choosing Availability Time as the only metric to care about or facet on? But not Durability (# of 9s, # of datacenters, etc)? If that's so, you should just make that clear. And S3-IA would be on that list.

Otherwise, you're just picking & choosing whatever metrics paint you in the best light, which is what would make a prospective customer (like me) or of mine leery.

It feels like you're either unaware of the competitive landscape (unlikely) or intentionally skewing the story, or both. And that will scare off potential customers, like me.

B2 is exciting! You're doing something innovative! I'm interested! Just tell your story, don't hide the things that make you different, and let the clients choose.

B2 is very competitive even with those other services listed - and it makes you seem more credible.

Heh, a friend just pointed out that their math is wrong on their pricing comparison page, too. S3 isn't +440%, it's +340%.
Interesting! How'd they calculate that? Taking the S3 price and dividing by B2 price then multiplying by 100 = 440%. Are they accounting for something else in their calculation?
It's great to see some price pressure on the big players in this area, fantastic going backblaze team!
Yev from Backblaze here -> Thanks! We hope to compete on not just price in the future, but it's not a bad foot to start off on :D
0.005 GB is a competitive price until you bake in the total cost of ownership. In this case, it still makes better sense for us to use Google's Cloud Storage offerings for our 100TB of mp3 file storage since sending all those files results in outgoing bandwidth charges from our infrastructure.

Staying in the same cloud "ecosystem" (Google or AWS) allows for free incoming bandwidth and free bandwidth when transitioning between services (EC2 to S3 / Google Cloud Server / Cloud Storage). An important consideration.

Can you share some info on how backups are handled for 100TB of Google Cloud Storage? (I'm thinking more like malicious actor intentional deleting kind of threat, not the lack of durability)
It's an excellent point. Everyone has to look at their particular use case. If your bandwidth between compute/storage is very high, and the amount you store is very little...staying inside of a provider that offers compute & storage makes sense.

If your cost of storage is high on a relative basis, B2 may be a cost efficient alternative.

Gleb from Backblaze

Surely you have an off-cloud backup of all this though. Just copy that onto 10 10TB disks and post those off to Backblaze for upload (not sure if they actually do this yet).

Most companies charge a small handling fee but it's fast.

Question for BackBlaze folks: curious as to why you didn't use the Amazon S3 API for the B2 service.
Yev from Backblaze -> B2 can be a bit cheaper because our service works a bit differently from S3. For example, uploading files doesn't require expensive load balancers in our data center. Instead, we require the dev to make 2 API calls to upload a file, instead of 1 in S3. The downside - our API isn't S3 compatible. However, the upside is pretty compelling - we pass the savings on and give you considerably cheaper storage.

Folks from the Beta have said that using our APIs they were able to integrate their apps to B2 from S3 relatively quickly. That said we're still early, so it may be that we develop some more compatible APIs in the future.

How does it work for GET requests then?
Some of the cost-efficiencies are achieved by architecting the software somewhat differently. The most important one is that the user requests and upload URL and then posts to that, which saves us from needing big, expensive load balancers.

At the same time, we're working with partners who will abstract our B2 API to make it akin to the S3 API.

Gleb from Backblaze

Definitely cheap!

I'm guessing it shouldn't be used for serving content without a CDN in front of it, though, as you just get a connection without great focus on download speeds or distribution. This makes their use case example "Cloud Applications" slightly misleading (or at least, incomplete), and also their comparisons... I'm not sure which plans they're using in that table, but I think some of these have a rather good CDN included (Rackspace for for example).

Still a great option for backup, blows Glacier out of the water. And certainly usable without a CDN for the "storage" portion of an application that doesn't require top speeds.

Cheaper than glacier (0.007), with none/few of the downsides, that's impressive!
"lowest cost"

Ovh.com public cloud storage is $0.01/gb/month and $0.01/gb out traffic. 99.999 sla and 3x replicated, openstack

OVH's download is cheaper but Backblaze is $0.005/gb/month so unless you're doing a lot of downloading, it's lower cost than OVH.
Idd, I'm building a social media service with it. So traffic is more important than storage. For long therm storage with almost no access/traffic this would be better.
Hubic by ovh is 5€ for 10TB, which would be 0.0005 €/GB/month. But i have no idea how compareable that offer is regarding features or sla. https://hubic.com/en/
Unlike Backblaze's other products, this one supports Linux through their command line tool.

https://www.backblaze.com/b2/docs/quick_command_line.html

CLI isn't mature right now, I'm failing to upload a file, kind of basic functionality.
I had to patch the client to get the authorize_account-command to work (interactively): (ed: lets put that in the righ order, shall we - the dict-key needs two dashes):

    diff -u b2.orig b2
    --- b2.orig     2015-12-17 02:01:55.500314405 +0100
    +++ b2  2015-12-17 02:00:31.032066222 +0100
    @@ -349,7 +349,7 @@

     def authorize_account(args):

    -    auth_urls = {'-production':'https://api.backblaze.com'}
    +    auth_urls = {'--production':'https://api.backblaze.com'}

         option = '--production'
         url = auth_urls[option]
[ed2: quest #182330 "Bug/typo in CLI tool" created -- that's a nasty bugtracker you've got there. Is it possible to just email support somewhere? I get grumpy when I need to run javascript and fill in CAPTCHAs just to file a simple bug ;-) ]
Yev from Backblaze here -> Interesting. Any specific errors its throwing? You can ping our B2 team directly at -> https://help.backblaze.com/anonymous_requests/new (select B2 product) -> they'll help you debug!
Do you have an account?
Looks great. Is there possibility to host static web files with this?
Does B2 include a CDN?
B2 is cool for business customers, but as a personal customer I'm a little salty about the context in which they present it.

If you have an external drive that you don't plug in every 30 days, Backblaze deletes your backup. I pointed out how common it is to have a drive of old photos, media, etc. and was told I should subscribe to B2 if I wanted "an archival solution instead of a backup solution" for those files.

It made me feel like Backblaze was really penny pinching... I'm not a business after all.

> If you have an external drive that you don't plug in every 30 days, Backblaze deletes your backup.

If you have any file that doesn't exist for 30 days, Backblaze deletes all backups of it.

the "context with which they present it" is that it's not for personal use, so I'm not really sure what you have a problem with. Right on the landing page they say "B2 Cloud Storage is for Developers and IT. What will you build?"

If you want a consumer-facing backup service, that's what backblaze's primary product is for.

Great to see competition in the space, especially from a "not super mega corp". Goodluck to you!
Yev from Backblaze here -> Thanks! We had a lot of interest during the closed beta, and so far things are looking pretty good! Just gotta keep it rolling ;-)
The the upload rate throttled?
Yev from Backblaze here -> We don't throttle on our end, though ISPs and distance to datacenter can affect how quickly the data will get there.
Mail them the data; its surprisingly efficient.