51–60 of 146 posts
Earlier quoted context omitted.
Interesting. Have you ever computed how much power you would save if you turned them off when not needed? Or is every pod constantly in use? Would it help if smart algorithms repartition the data on storage pods, to optimize power use?
Why wouldn't that be handled already by the drives themselves?
Earlier quoted context omitted.
Interesting. Have you ever computed how much power you would save if you turned them off when not needed? Or is every pod constantly in use? Would it help if smart algorithms repartition the data on storage pods, to optimize power use?
I wonder about this, too. Since access latency is the primary concern, a neat solution would be to create some dynamic "fastup" storage scheme. For large files, loosen the always-on requirement; to fulfill a request the first N bytes are served from the always-on pod, and the tail is stored and served from pods that dynamically power up drives only at access time. The size of N is computed such that the IO time it ta…
I’ve been a customer for years and recently had a catastrophic failure of a computer and it’s direct attached backup drive. I have spent the last four days waiting for backblaze to create a restore a backup for a computer on and last I checked it was at 9%. 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…
Why would it take any time at all to "create a restore"?
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.
I’ve been a customer for years and recently had a catastrophic failure of a computer and it’s direct attached backup drive. I have spent the last four days waiting for backblaze to create a restore a backup for a computer on and last I checked it was at 9%. 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…
Yev from Backblaze here -> That's definitely not normal, how much data/files do you have (are you doing a .zip or a USB restore)? We're currently QAing a dramatic increase to the restores, but right now only available internally until we are confident in it. In the mean time though you can download mission-critical files in smaller-sized restored, that might help you get up and running faster while the mega-restore c…
Email me Hn strapr.com if you want more details
Earlier quoted context omitted.
Why would it take any time at all to "create a restore"?
Brian from Backblaze here. 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.
@atYevP Do you guys do anything special regarding HDD vibrations? I am assuming your special case is built with this in mind. It is crazy how many things one has to consider at such scale. Things people normally do not care about!
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.
Earlier quoted context omitted.
I wonder about this, too. Since access latency is the primary concern, a neat solution would be to create some dynamic "fastup" storage scheme. For large files, loosen the always-on requirement; to fulfill a request the first N bytes are served from the always-on pod, and the tail is stored and served from pods that dynamically power up drives only at access time. The size of N is computed such that the IO time it ta…
I don't think latency is an issue for a backup solution.
> 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.
@atYevP Do you guys do anything special regarding HDD vibrations? I am assuming your special case is built with this in mind. It is crazy how many things one has to consider at such scale. Things people normally do not care about!
Not Yev but I also work at Backblaze. 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.
I love the articles from Backblaze. I enjoy them publishing the failure rates of drives and anything else on the blog. 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.