Backblaze Hard Drive Stats for 2018

https://www.backblaze.com/blog/hard-drive-stats-for-2018/

by sashk • 8 years ago

448 158 8 years ago

alinde2• 8 years ago

Would be interesting to also have metrics on failure per TB storage.

I'm not sure how that would be useful, since terabytes don't fail. When a drive fails, it's effectively a brick with no terabytes.

alinde2• 8 years ago

I was thinking as one failure of a 100TB disk has a very different impact of 10 failures of 1TB disks. It'd give some idea on how much data is lost due failures, no?

brianwski14• 8 years ago

Disclaimer: I work at Backblaze.

When a drive fails, it's effectively a brick with no terabytes.

Interesting factoid: that isn't always true. What you describe is actually the CLEANEST type of failure, the drive suddenly becomes a brick. We replace the drive and rebuild it from parity.

A way more interesting failure is when disk blocks start going bad at an unacceptable rate. Backblaze splits your data across 20 different hard drives in 20 different machines in our datacenter. The sub-parts we call "shards", a shard sits on one disk. Each shard has a SHA-1 checksum, so we know if each shard has been corrupted. If an individual shard is missing or corrupted, we know it needs to be rebuilt from parity.

So when a drive is HALF-FAILED, we even have a procedure to pull the drive out, and then opportunistically copy whatever files we can recover onto a new drive, then put the new drive back into production. Any files we recover where they are in the correct filesystem location and their SHA1 says they have not been corrupted speeds up the rebuild.

The reason the speed of rebuild is important is the whole concept of 11 or 12 "nines" of durability. We can't have more than 3 drives fail in any one group of 20 drives, and the faster the rebuild time, the less likely for 4 simultaneous failures. It plugs into the formulas in this blog post we did about durability: https://www.backblaze.com/blog/cloud-storage-durability/

klodolph• 8 years ago

I’m not sure that it’s especially useful to measure that way, which is why they wouldn’t report it. The chance that a given GB of data is on a failed disk is equal to the disk failure rate, regardless of disk size (>1GB).

For large deployments, the concern is between failure rates and the amount of time it takes to rebuild data from a failed disk.

For small deployments, my main concerns are whether disk failure takes a machine or volume out, causing availability problems.

I’m trying to figure where failures per GB would be how you would choose, what scenario we’re you thinking of?

krob• 8 years ago

HGST look like the best, but they don't have the quantities of the Seagate, makes me wonder if these numbers are skewed :/

simcop23874• 8 years ago

They're not going to be skewed. HGST disks are usually more expensive, so that limits the quantity that they buy. The seagate disks are usually cheaper but have a slightly higher (except when it's a brand new line) failure rate. When filling out a single server I go with the HGST disks because the premium price and quality means fewer failures, but it's more cost effective to go for lots of seagate disks when you have more redundancy and can eat more failures.

level• 8 years ago

I built a server a few years ago, and I determined it was more cost effective for a drive to fail than to use HGST. It would be more inconvenient, but having a drive fail on a home server with only 6 drives didn't seem very likely anyway.

VectorLock2• 8 years ago

This makes me curious of where the cost/benefit point is between these brands of drives. Do they buy enough that the reduced cost for higher failure rate outweighs the expense of buying more expensive drives?

zepearl6• 8 years ago

I agree (about Seagate being more cost effective for e.g. a datacenter). As private user I had in general bad experiences with Seagate (e.g. years ago I bought 8 2TB drives for 2 raid5 and 2 didn't even spin up, 1 failed after ~1 year) => I'm using since then only HGST and (pls. no jinx) so far only 1 has failed, but it "warned me in advance" with weird noises and terrible performance for ~1 week or so.

I now have at hetzner.de a host that has 3 4TB Seagate drives and I ended up building a 3-disks-raid1 instead of a raid5 because I'm too scared that when one drive fails, an additional one will fail as well during the rebuild-process when the remaining ones are stressed (a raid5 would then implode in this situation).

linsomniac4• 8 years ago

My experience, over decades, but now coming up on half that ago, was that IBM/Hitachi/HGST are definitely worth it. I used to run a small hosting business, which had hundreds of discs, and consulting business which had clients with hundreds more discs.

Seagates, in general, could always be expected to fail in a 3 year span. Often multiple times. IBM/Hitachi/HGST, especially the UltraStar enterprise line, would basically never fail. Over 20 years and hundreds of discs concurrently running (switching out as opportunity arose), we probably RMAed single digits of HGST drives.

In comparison, while I had a few pockets of Seagate drives that didn't fail (I had 6 in a storage server at home that never gave me problems), we could generally expect 5% of Seagate drives that we had running to fail in a given year. Enterprise or regular didn't really seem to matter.

For us, replacing a drive was fairly expensive, using a limited resource (our time). So we gravitated to HGST almost exclusively.

But: We also did an extensive burn-in process before a drive went into production. Basically: "badblocks -svw" for a week. He noticed that we had some drives that would fall out of RAID arrays, but if we ran badblocks on would never report an error. My theory was that there were some marginal sectors that would bit-rot. Running a week of badblocks would exercise those and allow badblock remapping to remove them from use.

Remember the IBM "Deathstar" 75GXP? We even had good luck with those. I had one of them start freaking out, and I was aware of the "Deathstar" name, so I went to replace it with another drive I had on hand. When I pulled it out to replace it I realized it was HOT. Not in the grand scheme of things, but definitely hot to the touch. I looked up the temp specs and it was clearly above that. The box it was in had 2 5-inch bays that didn't have the covers on them. I covered those bays, turned the machine back on after re-installing the Deathstar, and the drive continued operating for another 3-5 years with no problem. Made me wonder if improper cooling was the source of those reports.

HillaryBriss4• 8 years ago

improper cooling

You've had far more experience with this stuff than I have. I wonder what your view is on all these NAS RAID boxes and HDD longevity and heat.

I personally never saw so many HDD failures until I started running them inside a small NAS I bought some years ago. I nicknamed it my "drive killer" because I was replacing the things so often. Other HDDs I have in other (non-NAS) machines sure seemed to last much longer.

As for the Deathstar story: I had a similar experience with a Seagate. Inside the NAS, one of the SMART error counts started to rise in a foreboding way, so I replaced it (with an HGST) before it had a chance to die. Then, out of curiosity, I tried the old Seagate in a different non-critical setting (non-NAS) and it's continued to work for two more years. IDK. Too much heat?

kalleboo• 8 years ago

The Deathstar 75GXP issues were [quote Wikipedia] "due to the magnetic coating soon beginning to loosen and sprinkle off from the platters, creating dust in the hard disk array and leading to crashes over large areas of the platters".

Perhaps heat could have accelerated the process by loosening the material somehow, but it was definitely a design/manufacturing flaw.

e402• 8 years ago

Anyone have a good source of HGST drives? On Amazon, it used to be you could only get them from resellers and some comments complained about getting used drives. I basically stopped buying HDs from Amazon from resellers.

EDIT:

Example:

THEY ONLY WAY YOU CAN VERIFY THAT YOU DID INDEED RECEIVE THE FULL 5 YEAR HGST WARRANTY IS YOU MUST CALL HGST TECHNICAL SERVICE, GIVE THEM THE SERIAL NUMBER AND ASK IF THE DRIVE IS A NON-OEM, OEM OR REMANUFACTURED.

I have ordered expecting the full 5 year warranty, and verifying with technical service, have discovered - one with over 18,000 hours (from Crystaldiskinfo), several OEM's (no manufacturer warranty), a remanufactured and a full 5 years manufacturer warranty. AND once in awhile I get lucky and received as advertised - a full 5 year manufacturer's warranty.

superhuzza2• 8 years ago

Agreed. I only buy storage for personal use, but I've learned to avoid Amazon entirely. There are just way too many reports of fake or repackaged HDDs, SSDs, SD cards etc.

I can generally get the same or relatively comparable prices at local computer stores that I trust significantly more than Amazon.

jeremy7600• 8 years ago

They show the rates over years, too.. Quantities may be a factor in lower numbers, but over time they are reliable as well.

samstave2• 8 years ago

BackBlaze spent ~12 million dollars on 12TB Seagate drives (at full retail)

metalliqaz4• 8 years ago

Good thing they charge me $0.94 a month for my B2 storage. Gotta make that budget from somewhere!

atYevP10• 8 years ago

Every little bit helps ;)

brianwski14• 8 years ago

Disclaimer: I work at Backblaze.

Good thing they charge me $0.94 a month for my B2 storage.

We thank you for your business! :-) The absolute beauty of Backblaze B2 (or Amazon S3 or Azure) is that we can build a storage system at scale, and sell off all the little pieces of that. You win because you get a fair price on a sliver, and we win because we add up 100,000 customers like you and make about $1 million per year.

The very best business is where the customer and provider are happy with the relationship.

samstave2• 8 years ago

EDIT: It may have appeared that I was denigrating them for the spend...

NOPE

I was just curious when I saw the # of drives as the largest chunk in this writeup - to see how much that chunk cost them.

GNU_IS_UNIX• 8 years ago

Do larger capacity drives have higher failure rates?

simcop23874• 8 years ago

It's usually not so much that larger drives are inherently less reliable, but that the larger drives are also the newest lines and so yields and manufacturing issues are more likely to crop up than in the older lines that have had issues sorted out.

SiempreViernes2• 8 years ago

I don't think so, it's just that they didn't include their older and smaller drives, from previous report I remember a segate (I think) 3 TB disk that was abysmal.

linsomniac4• 8 years ago

Anything interesting in this one? I've stopped reading them because they all seem to be "Seagates fail kind of a lot but we use them because reasons. HGST doesn't fail a lot, but we also have statistically insignificant numbers of them, so <shrug>."

SiempreViernes2• 8 years ago

No, the opportunity to do a better analysis hasn't gone away.

metalliqaz4• 8 years ago

"because reasons" is an overly negative way to say "because they offer the best value"

They can get large numbers of them cheap, and their system is good at detecting and replacing bad drives, so why not use them?

linsomniac4• 8 years ago

In my head it wasn't negative, it was that there are a lot of reasons that I don't think needed to be gone into. Offering value is one, having systems that are designed to minimize the impact of failures is another. Others that came to mind when I wrote that include: Being able to get them at the quantities they need, having systems that reduce the COST of failures (drive replacement and RMA), cost of RMAing 10 drives is < 10x the cost of RMAing 1 drive, having drives available in the SIZES Backblaze wants. And there are others I could speculate about but don't have as concrete information on (vendor relationships, manufacturer relationships, marketshare, firmware quality/suitability, temperature).

Maybe it's just my social/business groups, but "because reasons" doesn't have to have a negative meaning. I use it as more a statement of fact: There are reasons for this.

Sahhaese• 8 years ago

With two categories A and B you don't need the same number in each category to compare whether they come from the same distribution.

I would be surprised if the number of drives they have is actually "statistically insignificant" \* but I haven't crunched the numbers.

https://en.wikipedia.org/wiki/Pearson%27s_chi-squared_test

\* By this I guess you mean that the null hypothesis of "they have the same failure rate" is not rejected.

merlincorey• 8 years ago

HGST doesn't fail a lot, but we also have statistically insignificant numbers of them, so <shrug>."

They have over 20 thousand HGST drives now, according to this year's report, which seems significant to me.

They continue to have lower failure rates than the Seagates.

mjevans• 8 years ago

It will be when the drives they just added have had more time in use. The best part of this is that them adding those drives signifies that they were on the market at good prices to add; competition is a good thing for consumers.

walrus013• 8 years ago

If I had to guess, the seagates are sufficiently cheap in ridiculous quantities, and Backblaze's multi-pod redundancy/parity and drive monitoring is good enough, that even if they have a 3% failure rate and the HGSTs have a 0.75% failure rate, that it's still an acceptable risk for them.

If you're an individual person with a 12-drive ZFS RAIDZ2 with hotspare, in a file server in your garage or something, you might prefer to pay the premium to buy HGST, because what if you have a double drive failure during a three week period while you're on vacation out of the country?

loeg3• 8 years ago

Especially if you're an individual person with a non-raid6 / hot spare system, you might pay a premium for a lower failure rate (standalone drive, RAID1, or RAID5, for example).

standardUser• 8 years ago

"Seagates fail kind of a lot..."

That Seagate 10 TB was the singular standout in terms of reliability. Maybe it is worth checking out.

mark-r2• 8 years ago

If there's one thing I've learned from seeing these reports over the years, it's that the specific drive model matters more than the brand.

kristofferR• 8 years ago

Your comment is frankly incredibly arrogant - "I can't be bothered to click and skim through the short post, so hurry up and summarize the contents for me."

zeroname• 8 years ago

Ten people give their opinions, as requested. One person thinks you're arrogant and tells you so.

You can't argue with results.

jsgo2• 8 years ago

Haven't read this one yet, but Seagates from what I saw in these tended to be okay. It was Western Digital that had, surprisingly, the most issue (which is unfortunate, considering I finally figured out the cheaper method using Best Buy for WD Red disks).

Granted, I'm not a hardware guy so my takeaway could've been wrong, but that's what it looked like to me when reading them.

peterwwillis2• 8 years ago

I'm interested in failure rate per iops. If the drive fails infrequently, great, but if it's also the worst performing drive, screw that. Would rather buy drives that perform as well as possible with the least failure rate.

walrus013• 8 years ago

In my recent experience there is not a lot of speed difference anymore between multiple manufacturers' 6TB to 12TB sized hard drives, when comparing between two competing products in the same rpm class (5400 or 7200) and areal density. Assuming similarly sized RAM cache on drive and not something like a drive with 64GB of SSD cache (hybrid drive).

loeg3• 8 years ago

To put it another way, everyone's pushing up against the same physical limits of spinning rust.

peterwwillis2• 8 years ago

I mean more like benchmarked performance. Two drives with the same specs may end up performing differently. I realize benchmarks are not entirely realistic and tuning can affect the outcome, but if there's a clearly outsized performance difference between two seemingly equivalent products, I want the one that performs better and fails the least. So, aggregate random read and write operations per second over failure rate, as a general spec. (this might also expose flaws in the stats, if one drive model is getting predominately more of a certain operation which results in more failures)

akulbe2• 8 years ago

I realize my comment is a tangent. I'm hoping folks might be understanding and hopefully have some advice.

If you have terabytes to back up, are there still any backup services left that'll let you ship them a drive for a faster initial backup?

ajford• 8 years ago

AWS has the Snowball program. They ship you what is essentially a network storage device with 10G ethernet, and you upload data over your local 10G network using their protocols, then ship back and they ingest into S3/Glacier.

Haven't used it personally, but did a fair amount of digging ~3 years ago. It was a potential backup solution, but we ended up shipping a 4U server full of 4TB drives to a partner for off-site backup, since they needed routine access anyways.

Check out the AWS page: https://aws.amazon.com/snowball/

brianwski14• 8 years ago

Disclaimer: I work at Backblaze so I'm biased. :-)

If you have terabytes to back up, are there still any backup services left that'll let you ship them a drive for a faster initial backup?

Backblaze offers a "Backblaze Rapid Ingest Fireball" to allow you to ship us 60 TBytes of data on an appliance.

https://www.backblaze.com/blog/introducing-backblazes-rapid-...

If you only have 2 - 10 TBytes, I suggest you get a faster network connection, or carry your laptop to a location (like your work place, or a library, or your neighbor's house) with a fast connection and just upload it. You might be surprised how easy and fast it is to upload a couple of TBytes nowadays. Using the Backblaze Personal Backup with 30 threads, I can upload about 1 TByte every 12 hours or so. So if you can leave your laptop at your workplace for 4 days you can upload 8 TBytes, then bring your laptop back home for the incrementals.

jl6• 8 years ago

Be wary of freeloading the upload bandwidth on a pipe that belongs to someone else.

post_break2• 8 years ago

It's been over a year, can you please ask someone at backblaze to add a single line of code into the snapshots so you can leave a comment? Right now if you make a snapshot, the only info is the date and time. Not the data, what's in the snapshot, literally anything about it. Please!

trumped• 8 years ago

but don't most ISPs have datacaps nowadays, Comcast has 1TB

chx• 8 years ago

I have cable Internet with 20mbit/s upload which I believe is decent (unless you have fiber) means uploading 8 000 000 gigabits (=1 terabyte) would take 400 000 seconds, that's about five days and that's the theoretical maximum. At ten terabytes you are now looking at two months...

akulbe2• 8 years ago

Hi Brian,

Thank you for reaching out. I love it when company folks will get into the conversation on HN.

As far as connection, I've got 300/300 from Frontier. It's good, and I can help out my friends. But more questions below...

I had been using CrashPlan for years. Converted to their business plan when they decided to ditch the Consumer stuff.

My confidence in their viability/user experience has eroded. I have personally ditched their service. My concern is for some family members who I've also had on my plan. I think they have roughly ~3TB of photos backed up. I want to find them a new home.

Color me skeptical that folks outside of the public cloud providers are going to be around in 10 years.

Convince me why Backblaze is a good option to send folks to, and please understand, I'm not trying to be a jerk. I'm just wary after having "the CrashPlan experience." Know what I mean?

Thanks.

AnIdiotOnTheNet• 8 years ago

You might be surprised how easy and fast it is to upload a couple of TBytes nowadays.

You might be surprised how slow it is in many areas of the US, let alone the world.

Arn_Thor4• 8 years ago

Thanks for weighing in. I wish it was that fast. I'm a new customer (formerly CrashPlan) uploading about 7TB, mostly photos and videos. Got a 500Mbps up/down line (in theory and in practice), but my daily uploading to Backblaze has never surpassed 30Mbps I've tried both low, medium and max thread numbers.

In such a case, could the HDD itself be a bottleneck as it's trying to slice and dice a lot of files large and small? It's running at 70-80% active time.

Probably doesn't help that I'm located abroad either..

zachruss92• 8 years ago

I really appreciate BackBlaze opening up this data. While I don't purchase HDDs often, I always refer to these reports when deciding.

They also open sourced their server chassis which is awesome!

It's nice to see a reduction of the failure rates as a whole. It looks like the next few years will be some interesting times for the growth in storage capacities for HDDs.

atYevP10• 8 years ago

Yev from Backblaze here -> Glad you're enjoying the stats!

HankB99• 8 years ago

Please thank those responsible on my behalf (and all of the others who study the numbers before purchasing drives.)

ericd• 8 years ago

These reports were super helpful when we were choosing how to kit out our servers (we went all HGST as a result). It's pretty hard to find good reliability data otherwise. So, a really big thanks from us.

JustSomeNobody• 8 years ago

Thanks! You guys rock.

sigi452• 8 years ago

I wonder if any of those companies talk to Backblaze about it. Like sending drives back for inspection :)

I'm also curious why those companies wouldn't directly talk to backblaze. I read somewhere a blog post on how they bought specific drives online at a sale.

atYevP10• 8 years ago

Yev from Backblaze here ->

I read somewhere a blog post on how they bought specific drives online at a sale.

Yea, we used to buy drives wherever we could, but that was years ago. We're larger now so we go through more established channels.

hinkley3• 8 years ago

Also no natural disasters taking out the manufacturers again, right?

fpgaminer2• 8 years ago

Tangentially related. Whenever I get a new drive, I always do a "burn-in". A program writes data to the whole drive and then reads it back (reproducible random data).

Is there any real justification for doing this kind of test on a new drive?

Doing it takes quite awhile, so I've been wondering lately if it's even worth it. I've never found anything with it.

conbandit• 8 years ago

If you've never found anything with it, why do you keep doing it (see: the definition of insanity)?

e402• 8 years ago

I have. Last time I bought a bunch of drives for a RAID array, I used the WD utility to test each of them. 1 of the 6 failed the test.

cataflam• 8 years ago

Not the parent, but probably because

1. It's notorious that hard drives have a higher failure rate at the beginning of their lives than in the middle (see bathtub curve [0]). So it's not absurd to test them hard early on before writing any useful data and to do an early RMA.

2. The failure rate on drives is low enough that his methodology may be right but he still never has any failure in his life. Doesn't it make insane.

[0] https://en.wikipedia.org/wiki/Bathtub_curve

icelancer3• 8 years ago

Why do you back up drives if you've never had a failure?

jonhohle• 8 years ago

   insanity | inˈsanədē |
   noun
   the state of being seriously mentally ill; madness

I'm not sure when the definition of obsessive-compulsive started being used to describe insanity (it's been going on for at least a decade), but I don't like it (and cringe every time I hear someone repeat it).

Sohcahtoa82• 8 years ago

This is a very strange invocation of the definition of insanity.

Apparently, quality assurance should never be a thing.

StrangeDoctor• 8 years ago

I do this with SD cards, I've found fakes with regards to speed and capacity. But I use ZFS for drives and just trust it to do its thing.

cerberusss• 7 years ago

Yup, I do this with SD cards as well. To do this on the commandline, I just fill it up with big gigabyte-sized files. The loop uses "seq 1 16"; at least 15 files should fit on a 16 GB stick.

    $ cd /Volumes/your_new_SD_card
    $ dd if=/dev/urandom of=test.bin bs=10000000 count=1000
    $ for i in $(seq 1 16); do cp test.bin test$i.bin; done

For good measure, you could run md5/md5sum on the files.

bluedino• 8 years ago

In one of their first blog posts about the pods they stated that they saw 'high infant mortality' in drives so they would burn-in each pod for a few days before writing any customer data to one.

fpgaminer2• 8 years ago

Thank you. Found the post: https://www.backblaze.com/blog/alas-poor-stephen-is-dead/

They have another good idea in there: recording the SMART data before and after the test. Their theory is that even if SMART attributes are still OK after the test, looking for a trend in the attributes may point to eventual failure later. Nice.

humantiy2• 8 years ago

Curious if anyone knows how they calculate drive days. For example the first drive on their report (hgst 4tb) has a count of 50 but total days of 23069. If I take the 50 by the days it should be 18250, so not sure where the extra 4k in days is coming from. Retired drives or something?

tzs• 8 years ago

I think it is over the time they have had the drive, not over the reporting interval. It's a measure of the age of the drives. Assuming their drives are operating 24/7, that means that those particular 50 drives have been in service an average of 461 days.

I'd expect on next year's report, those particular drives will show up as 49 drives with around 42000 drive days, assuming they aren't replaced by then.

humantiy2• 8 years ago

If that is the case then wouldn't the Annualized Failure Rate be based of the year total not the drive days if it is total days in service? For example the drive count(50)/drive days(23,236) gives the AFR of 1.58% which equals out their numbers. The drive days is more than the total amount possible for that year.

Rebelgecko• 8 years ago

I wonder if they have states failure rate based on a drive's manufacturing or installation date? It looks like there's a bit of a bathtub curve, and it would be interesting to see if that's attributed to individual drives having a tendency to fail quickly (if they're going to), or if drives are less likely to crap out once their model has been manufactured for a few years

mikece• 8 years ago

While I've heard lots of great things about the Backblaze reports, I've noticed in comments on NewEgg, Amazon, etc that the SKUs mentioned in the report frequently aren't available anymore. I've never had problems with WD Red drives though I don't purchase them all from the same vendor at the same time to make sure I get drives from different lots in case of a lot defect.

wmf• 8 years ago

By the time you have accurate reliability data on any equipment it's obsolete. Maybe this will change with the slowdown of Moore's Law/Kryder's Law.

mark-r2• 8 years ago

A perennial favorite, literally. Thank you.

atYevP10• 8 years ago

You're welcome!

icelancer3• 8 years ago

My company uses Backblaze since I think it's a good product, but blogs like this really cemented my choice. I appreciate their attention to detail and publishing data openly.

atYevP10• 8 years ago

Yev from Backblaze here -> That's awesome to hear! I'm glad you're with us! That's one of the nice side-benefits of this blog and one of the reasons we adopted an "open" policy with the Storage Pods. The first time we published that post it was because folks didn't believe we could store data so inexpensively - so it's nice to hear that we're building some trust along the way!

linux2647• 8 years ago

Is there anything similar for SSDs?

chemmail• 8 years ago

Relibality looks decent this year. All my seagates are having tons of errors, i think i'll stick to the other team from now on even though seagates seems to be getting better.

b3lvedere2• 8 years ago

Thank you Backblaze! I love your reports.

What is your procedure/policy on which disks to use in the pods? Do you try and maybe control the risk by using different harddisk brands in a single storage pod? Or do you just not care, because there have never been 3 pods dead at the same time? :)

Do you still use 17 data plus 3 parity shards?

evil-olive• 8 years ago

Their Q3 2018 stats had a bit of info on the lifecycle of introducing new disks:

https://www.backblaze.com/blog/2018-hard-drive-failure-rates...

In Q3 we added 79 HGST 12TB drives (model: HUH721212ALN604) to the farm. While 79 may seem like an unusual number of drives to add, it represents “stage 2” of our drive testing process. Stage 1 uses 20 drives, the number of hard drives in one Backblaze Vault tome. That is, there are are 20 Storage Pods in a Backblaze Vault, and there is one “test” drive in each Storage Pod. This allows us to compare the performance, etc., of the test tome to the remaining 59 production tomes (which are running already-qualified drives). There are 60 tomes in each Backblaze Vault. In stage 2, we fill an entire Storage Pod with the test drives, adding 59 test drives to the one currently being tested in one of the 20 Storage Pods in a Backblaze Vault.

b3lvedere2• 7 years ago

Thank you for the info! Much appreciated.

arcaster• 8 years ago

TIL - Seagate drives are still basically shit :)

Arn_Thor4• 8 years ago

Odd they don't have the 6TB HGST on the list. Well, maybe not odd, but annoying since I'm curious about that drive's performance especially

Backblaze Hard Drive Stats for 2018

Related Stories