Backblaze has ordered 100 petabytes of hard drives
backblaze.com
backblaze.com
I chatted with support and they said this is normal. That progress may jump to completed any time because the restore only tracks file count.
I wish I could say I’m happy about this but I’m four days into trying to pull down my data and I still have no idea when I’ll be able to start the download.
This sucks.
All the data is encrypted and spread throughout our datacenters. So we fetch each file and decrypt it (with the password you provided when kicking off the restore).
If this is less than 1 GByte it is instantaneous. But if it is a TByte of data, it takes a few hours to decrypt and add to the ZIP file.
There are some things that can affect it. We have a "pool" of restore servers that do this task. The oldest ones in the pool are 9 year old computers with slow hard drives. The newest restore servers are built on SSDs and are blazingly fast and have newer processors. So based on which restore server was assigned the task, plus other things like the size of each file can speed or slow the restore.
We are in the middle of a project to speed up all restores. Hilariously we figured out that simply by decommissioning the oldest, saddest restore servers the restores averaged FASTER restore times.
1. Why is the data being decrypted server-side instead of client-side? The server should be sending the encrypted data to the client, and the password should never leave the client machine.
2. Why are zip files being created? The client software should be receiving the data and writing the files directly to the selected restore directory.
e.g. this is how restore works with CrashPlan, and it only takes a few seconds to begin the process. Files are written directly to the selected output directory.
> 2. Why are zip files being created?
We actually offer two forms of restore: A) Zip File Download, and B) External USB Hard Drive FedEx'ed to your home.
In the case of the Zip file download, we chose the format of zip because both Mac and PC (the most common desktops) natively understand it with no additional software needed. In other words, if you just lost your computer, go to ANY COMPUTER ANYWHERE and you can fetch your files with a web browser. Zip preserves the file hierarchy and the last modified time, so it's "pretty good".
In the case of the USB Hard Drive there is no zip file, we can correctly place each file with all the correct timestamps in the correct heirarchy on the USB Hard Drive (which is actually an encrypted hard drive) and then FedEx the hard drive to you anywhere in the world in a day or two.
> 1. Why is the data being decrypted server-side instead of client-side?
Short Answer: Ease of use.
Longer Answer: To clarify, Backblaze produces four different products/modes for different customers with different needs and requirements. We want customers to choose what is appropriate for them. One size does not fit all:
1) Online Backup ($5/month) where every file is encrypted on your laptop BEFORE being sent to Backblaze and your backup is secured by your username/password - where you can recover your password if you have access to your email account. (We support two-factor auth which provides an additional optional layer of protection.)
2) Online Backup ($5/month) where every file is encrypted on your laptop BEFORE being sent to Backblaze and your backup is secured by your username/password AND your private encryption key is secured by a "passphrase" that is not recoverable in any way, shape, or form. (Two-factor auth is also optional here.)
3) B2 Object storage (half of 1 cent/GByte/month) where you store your file completely unencrypted, and this can be "private" (only accessible by username/password) or "totally public accessible by knowing the URL". A good application of this is serving up a web page to the public - you really WANT people to see all the contents!
4) B2 Object storage (half of 1 cent/GByte/month) where Backblaze has zero knowledge. You cannot browse your file hierarchy because Backblaze doesn't know your filenames. You cannot preview your images. You cannot recover your passwords. There is no other option other than downloading the encrypted blobs and applying whatever decryption algorithm you decided on (we have no ability to know what that is).
Ok, so I think some (many?) people in the security field think that Backblaze should ONLY offer mode #4 (and maybe #3 to serve up public websites). I happen to disagree and I personally feel that products #1 and #2 are useful and appropriate for some customers. But everybody is welcome to their opinion and we want to be completely open as to what exactly is occurring and what we are offering as a service.
Personally I think #2 is an excellent trade off of security vs convenience. Your data is as impervious to attack as a zero knowledge system in #4 for years upon years. Then one day your laptop is stolen or crashes and you want your files back. You want all 4 TBytes back - so you order one of our free (encrypted) USB hard drives to be FedEx'ed to your home with all your data. To kick this process off FOR THE FIRST TIME EVER you tell us your passphrase (up until this very moment it really has been zero knowledge). At this moment you are opening a window of SLIGHTLY lowered security that slams shut after a few hours. For those few hours of preparing your 4 TByte restore, if an undetected hacker had compromised the one restore server in the Backblaze data center that your job was on, that hacker could possibly get access to your files. But then the reduced security window slams shut, we NEVER write your passphrase to any disk so it has now vaporized and we do not remember it, and if a hacker hacks into our system the following day you are STILL completely impervious.
But again, as long as you fully understand the implications of #3 I am COMPLETELY supportive if you instead choose #4 which is our "Zero Knowledge" offering.
This is the part that security people get hung up on.
We have to trust Backblaze [0] to not hang onto the password longer than you say you will, either intentionally (say, "to improve the user experience") or unintentionally ("oh that memory got written to swap and happened to persist on disk for a long time, whoops").
So that's the "malicious" case (maybe some of the above described cases are "benign malice", doesn't matter). There's also the "subverted" case: if the decryption password enters your infrastructure, we have to trust that you have not been popped by an attacker.
Whereas, if Backblaze has zero knowledge, and only serves encrypted bits, the _only_ concerns customers have are with durability and availability, which it sounds like you have pretty well in hand from your description of how bits are distributed around your datacenter(s).
[0] not just Backblaze but 5-years-from-now Backblaze: people and businesses change.
In a commercial setting, you need to control the infrastructure and security artifacts. Otherwise, old fashioned physical controls are effective, trustworthy and have more legal protections than any of these products at a cost of some convenience.
Nothing personal, but I really don't want y'all seeing my data, even if I need to restore.
(context: I've been a Backblaze user for years and love the hell out of you. I've never really thought of how the restore would work with my encrypted data, though. Turns out the story is ... not what I had hoped)
Bonus points for open sourcing a tiny "backblaze decrypter" command line utility that can do this manually. Though maybe that's a stretch.
This is how CrashPlan worked. (And incidentally, as I'm sure the guys at backblaze are fully aware, CrashPlan home is shutting down and I'm currently struggling to find a replacement that meets my desires. So if backblaze started to offer that #2 + encrypted restore soon they would gain my custom at the least.)
We totally understand, especially about the (very real) security issues.
I would reassure you that Zip file restores are COMPLETELY automated and with thousands of them happening every day no Backblaze employee ever sees your files.
The USB restore drives are placed in an envelope by a human, but they are encrypted when they are placed in the envelope so there is still no danger of any person seeing your files.
Plus we take our customer's privacy VERY seriously and it would be a firing offense for any Backblaze employee to ever look at a single customer file (or file name) without that customer's explicit permission.
> In the case of the Zip file download, we chose the format of zip because both Mac and PC (the most common desktops) natively understand it with no additional software needed. In other words, if you just lost your computer, go to ANY COMPUTER ANYWHERE and you can fetch your files with a web browser. Zip preserves the file hierarchy and the last modified time, so it's "pretty good".
Security issues aside, from a space and time perspective, that's much less convenient for both you and me: it takes time and space for you to prepare the zip file, and space and time for me to save it and extract it. It would be better to install a simple client and restore the files directly into a directory. In the case of a few files, it doesn't matter much, but in the case of gigs of files, it definitely becomes a problem.
Is there any chance of you implementing a more CrashPlan-like restore option in the future?
> Longer Answer: To clarify, Backblaze produces four different products/modes for different customers with different needs and requirements. We want customers to choose what is appropriate for them. One size does not fit all:
I wish this explanation were on the Backblaze web site, because this makes it very clear. :)
Is there any chance of implementing a hybrid of #2 and #4, a client-based, zero-knowledge option? i.e. basically, CrashPlan's client in the private-key mode.
If Backblaze were to implement this, and add a Linux client, I'd seriously consider switching.
Thanks for your time.
> and space and time for me to save it and extract it
One advantage is that for millions of small files, batching them together into one monolithic ZIP file allows for faster downloading. As opposed to a round trip to fetch each file. But there could be a happy medium where we batch 1,000 encrypted files to download to your computer then split them up, decrypt them, and cleanup any temporary files before fetching the next 1,000 encrypted files, etc.
> Is there any chance of implementing a hybrid of #2 and #4,
> a client-based, zero-knowledge option?
Yeah, we get asked for a "client restore option" quite a bit (see other comments in this thread also). Realistically I don't see it happening in the next 6 months, but eventually we really should get it done.
Well, any such software that didn't have pipelining would be poorly designed. ;) Compare to software like rsync, Unison, etc, which transfer large numbers of small files quickly. Seems like a good solution would be to build on librsync.
Email me Hn <at> strapr.com if you want more details
Btw, unlike parent comment, I had a great experience with the restore and couldn't be happier with the decision to go with backblaze.
Note: They recently released a new website and software version that's supposed to address some of these issues but fool me once and all...
The problem started when I decided to upgrade to High Sierra. The upgrade was catastrophic for this configuration of Mac Pro. I have been on the horn with an Apple Senior Advisor within Apple Enterprise Support who has escalated my specific issues to Apple Engineering. I decided to roll back but in the process of restoring the machine from the time machine backup the locally attached drive failed.
Apple has yet to tell me if they will even support the Apple RAID controller even though this version of the Mac Pro is listed as compatible. In the meantime I need to get back up and running. This is why I pay for a cloud backup in addition to having a local backup.
Fortunately, I also have a MacBook Pro laptop that I keep a duplicate copy of some of the data on.
My productivity will not take a hit.
It's just that most people are not me and it seems like it should not take more than four days to create a restore so that I can download my data.
A bug in a script I wrote in .net, was supposed to iterate through a list of network directories to delete (all starting with \\SERVERNAME\) and ended up iterating through the characters of the first item in that list ("\").
That's how I learned that in Windows, "\" means the root of the current drive, and that deleting all files from a drive on an SSD only takes seconds...
Good luck, hopefully you can get everything back in order before the weekend is over.
I checked into it, and we think your restore is slow for several reasons:
1) Lots of tiny files (we are fixing this in a rewrite literally this week)
2) It landed on a slow restore server. (We are planning on decommissioning that server soon because it is 8 years old and slow.)
We have the technology to move your restore to a faster restore server. However, the restore experts here tell me your restore is actually 90% through the part that would speed up, so they recommend just "let it run". I really really hope it will be finished and ready for you in the next few days.
If you need some of your files any faster, I think you should prepare several smaller restores. It turns out that if you prepare four restores, each one 25% as large as the original, the four restores will complete 4x faster because they are prepared by four separate servers.
You can create up to 10 simultaneous ZIP restores, and they are totally free, so feel free to spin up a few more restores even if they overlap with the original large 1.1 TByte restore.
Please reach out to me again if your restore isn't ready by Tuesday (October 10th).
Two things missing from them in my opinion 1) a Linux client and 2) a second location
I guess I could get away without a Linux client if there was an unRAID plugin for B2.
One of their employees pretty much said exactly that here on HN recently. I don't have the comment bookmarked or anything like that so I can't cite it for you, but I do remember reading it.
I'm paraphrasing, of course, but s/he basically said "the math doesn't work out" (for the regular service, not B2 (obviously)).
Could you link some source? I'm also backing up my linux machines with them and would prefer to plan ahead.
Some info here: https://www.theregister.co.uk/2017/08/23/crashplan_ends_cons...
affiliate link: https://billing.time4vps.eu/?affid=1881
Cheaper then backblaze in most situations and you get a full linux host.
With my luck, the first time I need to be able to quickly restore a full dataset or something, it will probably have been well worth it and I'll likely be kicking myself for not doing it.
B2 is priced at a sustainable point for them, so that's your best option for other use cases-- it's only $5/TB*mo!
https://blog.eogn.com/2017/08/22/crashplan-is-shutting-down-...
The Backblaze numbers seem to support this as well, far fewer failures of HGST drives vs Seagate, but they seem to buy mostly Seagate. I guess when you have tens of thousands of drives, you're always going to need to be replacing them. So maybe a 10x reduction in failures isn't worth it? Or maybe they just couldn't get HGST drives in quantity?
Also you want to buy from a wide range - if most of the drives come from one place and they have a manufacturing disaster that causes everything made in one month to fail a few months into use then that might take you too close to redundancy requirements for comfort. I would expect the range picked will be based on individual design (platter design, platter layout, controller type, ...) rather than per manufacturer - maybe HGST has fewer designs available at any one time and that tips the balance a bit.
No power on/off cycles, no physical impacts to worry about (even most desktops occasionally get bumped into), but non-stop operation and presumably near continuous read/write operations.
You'll likely get different failure patterns as a result.
I thought it would be more like: continuous writes until full, and then likely a handful of reads for the rest of that drive's life.
Or is every pod constantly in use? Would it help if smart algorithms repartition the data on storage pods, to optimize power use?
> it remains on so that backup and B2 data can be uploaded and accessed
This is also why Amazon has tiered pricing between S3 and Glacier.
> Have you ever computed how much power you would save if you turned them off when not needed?
Electrical power is a gigantic part of our datacenter bill (like 60%). However, we cannot really ever turn off the hard drives.
If they were powered down, it would take too long to retrieve data. It would be like Amazon Glacier where it can take 15 minutes to get a single image back.
> is every pod constantly in use?
The way we built it, yes. If one user deletes a backup or unsubscribes from the Backblaze service, it frees a little bit of space on pods all over the datacenter. So we allow some other customer to use that space up as soon as we can.
We also use ALL the pods in the datacenter to give us "breadth" to accept data faster. This is particularly helpful on surges of new customers due to a press event, or if a competitor like CrashPlan decides to exit the market.
Well, speaking for myself, I don't mind if I have to restore a backup, and have to wait 1 minute extra for a system to come online (that's about the typical boot time of a Linux system, so I suppose for a storage pod it would be about the same).
By the way, it seems possible to power down an individual SATA drive if it is not in use: [1].
[1] https://unix.stackexchange.com/questions/112117/shutdown-my-...
Complications like a write cache drive in case of power failure, or grouping expected-cold data together. Also I wonder if powering the drive up and down occasionally will have a positive or negative impact on drive reliability compared to having it on 100% of the time.
Also if if he says it takes about 15 Min's for it to come online and be usable in their massive data center I would believe him.
The ones provided in the „My Account“ page are an absolute nightmare.
Look at services like Stripe or Digitalocean and make them downloadable as PDF. Best case: send them out via email or auto-upload to specific Dropbox folder.
Or rather, if I have 10TB on a NAS and a Linux machine, what would it cost to back that up to Backblaze as a consumer given that you don't support this and I'd need to purchase the business thing?
I thought B2 was like S3 and figured that Business Backup was what I needed.
TIL.
> I thought B2 was like S3
It is. Backblaze actually has two separate product lines:
1) Online Backup for $5/month/computer where you have to use our client we wrote with all of it's policies. This is widely targeted at "ease of use" type customers. There is a free feature inside of "Online Backup" called "Groups" where one person can pay for many others. You can use this for a business, we absolutely do NOT charge differently just because it is a business. Or you can use "Groups" to pay for a family, or whatever. "Groups" is free, we honestly don't care if you use it or not.
2) Backblaze B2 - this is "object storage for half a penny per GByte per month". There are MANY clients available for you to choose from, you can see a list on this page: https://www.backblaze.com/b2/integrations.html The idea here was many people kept approaching Backblaze saying they needed to store stuff cheaply, but didn't want to use our client, or maybe it wasn't "backup" they needed but to host live images on a website on the internet, stuff like that. So we built an API anybody can program to. https://www.backblaze.com/b2/docs/
I recently trimmed down my Backblaze licenses after switching to Linux installs, just went with s3 as s3cmd had a path of least resistance to storing backups. Would love to switch back if it's ever possible :)
But if youre using S3, just switch to B2, its per GB pricing, much cheaper than S3 and supports lots of Linux tools. I use rclone.
I'm pretty sure the right Linux backup solution is rsync.net, by the way, which does support a native (SSH) file access interface. For big backups, storage is (slightly less than) twice as expensive as S3, but unlike S3, there are no bandwidth costs.
I'm aware, but B2 is not the reference point. He said he went with S3, so that's what we're comparing to. I.e., if S3's prices are palatable, then rsync.net might be, too.
Just to clarify ... we (rsync.net) support "borg backup" now (with borg deployed on the server side ...) which is the "holy grail" of efficient, zero knowledge, remote backups:
https://www.stavros.io/posts/holy-grail-backups/
... and if you are willing to give up our ZFS snapshots on the account (you manage retention yourself with borg) and you are willing to handle your own technical support of borg, we offer a 3 cents rate. This is about the same price as S3:
Most of the anti-vibration tech is straight forward, like the fans aren't bolted to the chassis, they are held by rubber rivets, and we have slowly but steadily improved the "pressure" that drives are held in place to limit failures, etc.
From time to time, a fan will "half fail" causing large vibrations which can massively increase drive failures in the rack that bad fan is in.
What is louder? The fans or all the disks together? I had a workstation with 6 spinning disks and that was already quite loud.
What do you mean "stay competitive?"
Data is automatically distributed across a minimum
of three physical facilities that are geographically
separated by at least 10 kilometers within an AWS Region
Designed for 99.999999999% durability and 99.99%
availability of objects over a given year.
Designed to sustain the concurrent loss of data in two facilities.
From https://www.backblaze.com/b2/cloud-storage.html Uptime: 99.9% SLA
Reliability: 99.999999% durability
So S3 is 10x more available, 1000x more durable, and datacenter redundant.I mean, what are the odds that S3 will even be operating in 100 years? I'll certainly put $1 against $1,000,000,000 that it won't, and that's only one many ways it could fail the standard.
Yes. We have already dropped B2 prices once, and the expectation is we'll probably be dropping them regularly as our cost per GByte drops.
> What's it like having to flip such a massive switch...
What's amusing is the switch is tiny (just one constant in a json table) and but the fallout is massive. But realistically we have a business strategy of not making egregious profits, so we only drop prices when our margin is too high.
Jeff Bezos of Amazon once said, "Your margin is my opportunity." Well, Jeff's margin is Backblaze's opportunity. :-) We survive and thrive because Amazon is being too greedy and marking up their storage (and outbound bandwidth) by way too much.
When we started 10 years ago, we could only afford to rent a quarter of one cabinet at the datacenter at 365 Main Street, San Francisco. We had "right of first refusal" on the rest of the cabinet we occupied. We could pile all of the hard drives ever deployed in that cabinet on my kitchen table.
Now it is semi trucks filled with fork lift pallets of drives. But it just "snuck up on us". Each day it was a little larger, each drive order was just slightly larger than the previous.
Back during the hard-drive crisis after the tidal wave that disrupted production ... they were buying from anyone that had drives to sell, including people going into their local big-box store to source drives.
So the question would be, In unit of Backblaze, what are the size for Amazon, Apple, Google, Facebook?
If those are 12 TByte Seagates, that's about 120 PBytes? So at this point we are almost there and in fact we sometimes talk directly with the manufacturers, who turn around and send our order through a distributor or reseller. This is probably to prevent "channel conflict" where Seagate or Western Digital is undercutting it's distributors, but that's just a guess.