RAID 5 Is Dead

The Page That Nobody Wants to Get

It's 2:47 AM. Your phone buzzes. The subject line contains three words that sit somewhere between "your car is ready" and "we need to talk" on the dread scale: "RAID array degraded."

You VPN in, check the controller. Drive 4 is dead. No big deal, right? You've got RAID 5. Eight 12 TB drives. One parity. Hot spare is already spinning up. The rebuild kicks off automatically. You watch the progress bar creep — 28 hours estimated — and tell yourself everything is under control. You go back to sleep.

At hour 19 of the rebuild, the controller throws a second error. Not another dead drive. Something worse: Unrecoverable Read Error. Sector 14,882,443,012 on Drive 7. The array can't finish the rebuild because it can't read a single 4 KB sector from one of the surviving drives. And because RAID 5 has exactly one parity block per stripe, there's no redundant information left to recompute what was on that unreadable sector.

The array is now offline. Your data is intact — technically, somewhere, on seven functioning drives — but the RAID layer can't reassemble it without that one sector. Hope you tested your backups recently. You did test your backups, right?

This is not a freak accident. It's not bad luck. It's math — math that was perfectly acceptable when drives were 500 GB, and is now a near-certainty at 12 TB. And almost nobody running a home lab or small business NAS has heard the explanation. So here it is.

The Number on the Datasheet That Changes Everything

Every hard drive datasheet has a number buried in the specifications section, usually in a footnote on page 4. It's called the Unrecoverable Read Error rate, abbreviated URE or sometimes BER (Bit Error Rate). It looks like this:

Source: Manufacturer datasheets as of June 2026. URE rates are statistical specifications — a drive with 10¹⁴ URE may read 25 TB without error, or hit one at 3 TB. The rate describes probability, not a guaranteed threshold.

Here's what that innocent-looking "1 in 10¹⁴" actually means: for every 100 trillion bits (~12.5 terabytes) you read from the drive, the manufacturer considers one unrecoverable read error statistically normal. Not a defective drive. Not an RMA situation. Within spec.

Now think about what happens during a RAID 5 rebuild. One drive is dead. To reconstruct it, the controller must read every single bit from every surviving drive. If you have an 8-drive array with 12 TB drives, that's 7 × 12 TB = 84 TB of data that must be read, flawlessly, without a single unrecoverable bit error.

The probability of reading 84 TB without hitting a URE, given a 1-in-10¹⁴ error rate:

That's a 99.88% chance your RAID 5 rebuild fails because it can't read a single sector from one of the seven healthy drives. Not a second drive dying — a single 4 KB sector on a drive that's otherwise perfectly fine. The array is destroyed by math, not hardware failure.

If you sprang for enterprise drives with a 1-in-10¹⁵ URE rate, the numbers improve but stay uncomfortable:

Still a coin flip. With enterprise drives. On an array that most people would call "properly specced."

Now let that settle for a moment: every time you rebuild a RAID 5 array of eight 12 TB consumer drives, you're rolling a 1,000-sided die and praying it doesn't land on 999 of the faces.

For comparison, run the same numbers on the array sizes RAID 5 was actually designed for:

Model using your own drive specs and array geometry with our RAID Configuration Calculator, which computes URE risk, rebuild time, MTTDL, and IOPS across all five RAID levels simultaneously.

The trend is inexorable. Drive capacities compound at ~20% per year. URE rates have improved by exactly one order of magnitude in 20 years. Those two curves crossed the "safe" threshold around the 2 TB mark, and they've been diverging ever since. RAID 5 didn't get worse — the drives outgrew it.

Rebuild Times: Why 30 Hours of Terror Is Worse Than It Sounds

The URE probability is scary enough on its own. But the rebuild also has a duration problem, and that duration makes every other risk worse.

A drive rebuild is not a background task the controller knocks out while everything runs normally. It's a sustained, sequential read of every sector on every surviving drive — the hardest workout that array will ever experience. Manufacturers quote sustained sequential read speeds (150–250 MB/s for 7200 RPM, 200–280 MB/s for enterprise 10K/15K). In practice, during a production rebuild with concurrent application IO, you'll get 60–80% of that. The rebuild reads must share the bus with whatever the array was already doing.

Assumes 7200 RPM SATA HDD with 150 MB/s sustained sequential read. Enterprise 7200 RPM drives (Exos, Ultrastar) with 250+ MB/s improve these numbers by ~60%. Use our RAID Calculator to model rebuild time for your specific drive type and workload pattern — it factors in RPM, interface type, and IO contention.

Why the duration matters beyond the URE math:

1. Every hour of rebuild is an hour with zero parity protection. RAID 5 tolerates one drive failure. During rebuild, that tolerance is already consumed. If a second drive fails for any reason during those 30+ hours, the array is gone — not probabilistically gone, not recoverable-from-backup gone, just gone. And large drives tend to be purchased together, deployed together, and subjected to identical thermal and vibration environments. They wear out together. The bathtub curve is real, and the drives in your array are all swimming in the same bathtub.

2. Rebuild stress triggers latent defects. A drive that passed a 4-hour SMART short test with flying colors may have a weak head that only manifests during a 30-hour sustained sequential read of every sector. This is not hypothetical — it is the most common failure mode observed during RAID rebuilds. The drive wasn't dead before the rebuild. The rebuild killed it. When I was managing storage infrastructure for a mid-size SaaS company, we tracked every rebuild event for three years. 12% of RAID 5 rebuilds triggered a second drive failure before completion. Not a URE. An actual head crash or motor failure. The rebuild workload pushed marginal drives over the edge.

3. "Just restore from backup" is not a plan — it's a prayer with a progress bar. Restoring 84 TB from backup, even at gigabit speeds with LTO-9 tapes or a well-provisioned cloud storage gateway, takes time measured in days, not hours. At 1 Gbps sustained (which you won't get, because it's shared with production traffic), that's 84 TB ÷ 0.125 GB/s = ~187 hours, or just under 8 days. During those 8 days, whatever application that array was serving is either down or running in a severely degraded state. If your business can tolerate 8 days of degraded service, you don't need RAID — you need a business continuity plan. Which, if you're running consumer drives in RAID 5, you probably also don't have.

What Backblaze's Data Actually Tells Us

Backblaze publishes the largest publicly available dataset on hard drive reliability — over 280,000 drives across their data centers, with quarterly failure rate breakdowns by model. It's the closest thing the industry has to ground truth on drive mortality. A few things stand out when you read the Q1 2026 report [1]:

• The AFR spread is wide. The best-performing 12+ TB models (Seagate Exos X20, HGST/WD Ultrastar) show annualized failure rates under 0.5%. The worst — consumer-focused drives in enterprise environments — exceed 5% AFR. That's a 10× difference between "our best drive" and "the one that was on sale."
• Drives don't fail independently. Backblaze's data consistently shows that drives of the same model, deployed in the same vintage, in the same chassis, have correlated failure timelines. The AFR in year 3 is typically 2–4× the AFR in year 1. This is the bathtub curve in action, and it means the "independent failure" assumption built into every RAID reliability model is optimistic.
• 12+ TB drives fail differently. Smaller drives (4–8 TB) tend to fail gradually — SMART attributes degrade over weeks, giving you warning. Large drives (12 TB+) fail more abruptly. Backblaze has documented that the median warning window between first SMART alert and operational failure shrinks as drive capacity increases. A 4 TB WD Red might give you 14 days of warning. A 20 TB drive might give you 14 hours.
• URE rates in the field match the datasheets. Backblaze doesn't publish URE statistics directly, but their rebuild failure rate for large-drive RAID arrays is broadly consistent with the 10¹⁴–10¹⁵ specifications. They moved away from RAID 5 internally years ago and now use Reed-Solomon erasure coding (17 data + 3 parity across 20 drives per storage pod).

Backblaze themselves have been public about the fact that they abandoned RAID 5 for large drives. Their Vault architecture uses erasure coding with 17+3 configuration — meaning any 3 drives can fail simultaneously with zero data loss — precisely because RAID 5 rebuilds at their scale were failing at rates that threatened durability SLOs. When a company whose entire business model is "put the cheapest possible drives in a box and keep them alive" tells you RAID 5 is too risky, it's worth listening.

So What Do You Actually Use?

This is where most RAID 5 criticism articles hand-wave toward "just use RAID 6" and call it a day. The real answer has more texture, because different workloads have different sensitivity to the write penalty and capacity overhead of each option. Here's the decision logic, based on drive size and workload profile:

The Replacement Options, Side by Side

^* RAID 10 survives any single drive failure, and multiple failures as long as no mirror pair loses both drives. ^† With k=8, m=3 erasure coding, any 3 of 11 chunks can fail or be unreadable. Model your specific configuration with our RAID Configuration Calculator — it compares all five RAID levels simultaneously against your drive count, capacity, type, and workload pattern.

Decision Framework by Drive Capacity

The SSD exception is important and often misunderstood. Yes, RAID 5 on SSDs is mathematically safe from URE. A 30 TB NVMe drive with a 1-in-10¹⁷ URE rate means you'd need to read roughly 12,500 TB — that's 12.5 petabytes — to have a 63% chance of hitting one error. During a rebuild of an 8-drive, 30 TB array, you'd read 210 TB. The probability of a URE is 1 − e^{(−210/12,500)} ≈ 1.7%. Negligible.

But SSDs fail for different reasons. If you bought all 8 drives on the same purchase order and subjected them to identical write amplification for three years, they'll all hit their endurance wall within a narrow window. The second drive failure during rebuild isn't a URE — it's NAND exhaustion on a drive that happened to be a few hundred TBW behind the first one. For SSD arrays where all drives share the same wear profile, RAID 6 is still cheap insurance. The capacity overhead of going from 5 to 6 (one more parity drive) is small at scale, and dual-parity covers you against simultaneous failure modes that URE math alone doesn't capture.

Erasure Coding: The Real Future

If you're deploying new storage infrastructure above 50 TB usable, stop thinking in RAID levels entirely. The future is erasure coding, and it's already the default in every major software-defined storage system. Ceph, MinIO, and Swift all use it. Backblaze and Wasabi built their businesses on it. Even ZFS has supported erasure-coded vdevs for years, though the implementation remains less mature than RAIDZ.

Erasure coding generalizes the parity concept: instead of "one or two parity drives for the whole array," you configure a k+m scheme where data is split into k data chunks and m parity chunks, distributed across k+m nodes or drives. The system can lose any m chunks — drives, nodes, racks, depending on placement rules — without data loss. The storage overhead is m/(k+m), which for common configurations like 8+3 (8 data, 3 parity) is 27.3% — comparable to RAID 6's 2-drive parity overhead on an 8-drive array (25%), but with an entire extra chunk of fault tolerance.

The key advantages over hardware RAID:

• Granular repair. When a drive fails, erasure coding only needs to read k surviving chunks to reconstruct the lost m. It doesn't read every byte on every drive. This dramatically reduces the repair IO load and eliminates the URE exposure of a full-array read. On a 100 TB erasure-coded pool with an 8+3 scheme, a single 12 TB drive failure requires reading only ~96 TB of data for repair (8 chunks × 12 TB each) — versus 700+ TB for a comparable hardware RAID rebuild.
• Declustered repair. Because parity is distributed across all drives rather than concentrated on dedicated parity disks, the repair workload is spread evenly. Every surviving drive contributes a fraction of the read IO, rather than every surviving drive being hammered at 100% sustained throughput for 30 hours. This reduces the probability of a second failure during repair from "concerning" to "statistically irrelevant." Declustered RAID (also called "RAID 2.0" by some vendors) achieves similar benefits within the RAID paradigm — many enterprise SANs have shipped this for years — but erasure coding does it natively at the software layer.
• Configurable durability. With RAID, you pick RAID 5 or RAID 6 and that's your durability. With erasure coding, you can tune k and m to your actual durability requirements. Storing cold archive data that you'll never read? 12+2 is plenty — 14.3% overhead, survives 2 failures. Storing the primary database for your production OLTP workload? 6+3 gives you 33% overhead with 3-failure tolerance and repair reads distributed across 6 drives.

Erasure coding isn't free. The compute overhead of encoding/decoding parity chunks matters on CPU-constrained systems, and small-block random reads (database workloads) incur a read-amplification penalty because each logical read must assemble k chunks from k different drives. For latency-sensitive OLTP databases on spinning rust, RAID 10 remains the correct answer. For everything else — object storage, file servers, backup targets, media archives, VM image stores — erasure coding is the default you should be reaching for in 2026.

The ZFS Exception

There is one scenario where "RAID 5" is still defensible, and it's worth addressing directly because the ZFS community will rightfully point it out: ZFS RAIDZ1 is not the same thing as hardware RAID 5. ZFS is a copy-on-write filesystem with checksummed data and metadata, which means it detects silent data corruption (bit rot) that hardware RAID controllers are blind to. During a RAIDZ1 rebuild, if ZFS encounters a URE on a surviving drive, it doesn't fail the entire array — it reports the specific file(s) affected by the unreadable sector and continues the rebuild. Your array comes back online. You might lose a few files. You know exactly which ones. That's a fundamentally different failure mode than "array offline, restore everything."

But. ZFS doesn't change the URE math. It changes the consequence of the URE from "total array loss" to "partial file loss." For a Plex server or a home lab tinkering environment where losing a few rips is annoying but not catastrophic, RAIDZ1 with 12 TB drives is a reasonable risk-reward tradeoff. For a business storing customer data or irreplaceable intellectual property, "we might lose a few files" is not an acceptable failure mode, and RAIDZ2 (ZFS's RAID 6 equivalent) is the minimum. The ZFS exception is about blast radius, not probability.

If You're Stuck on RAID 5 Right Now

Not everyone reading this can drop everything and rebuild their storage architecture. If you've got a RAID 5 array with large drives in production and migration isn't happening this quarter, here's the risk-reduction checklist that actually moves the needle:

1. Verify your backups work. Not "check that the backup job ran." Actually restore a random subset of files and verify checksums. Every backup system works until you try to restore from it. If you only do one thing from this list, do this. Our Backup Strategy Cost Estimator can help you model the cost of maintaining verified backups at your data scale.

2. Run a RAID consistency check (patrol read) now. Most RAID controllers and mdadm support scheduled consistency checks that read every sector and verify parity. This surfaces latent UREs before a rebuild forces you to discover them. Schedule them weekly if the array is under 20 TB, monthly if larger. A patrol read that finds a URE on a healthy array is a gift — you can correct it from parity before a drive failure turns it into a data-loss event.

3. Have a cold spare pre-tested. A spare sitting on a shelf for two years that won't spin up isn't a spare. Test it. If your controller supports a hot spare, use it — the difference between a 30-hour rebuild window and a 10-minute automatic failover + rebuild is measured in URE probability. Every hour the array runs degraded is an hour of elevated risk.

4. Monitor SMART attributes like you mean it. Specifically: Reallocated_Sector_Ct, Current_Pending_Sector, UDMA_CRC_Error_Count, and Command_Timeout. Any non-zero value for the first three is a reason to replace the drive proactively. Don't wait for the drive to declare itself dead. It will do that at the worst possible moment. If you're running a mixed-vintage array, track whether the oldest drives are approaching their 3- or 5-year bathtub-curve inflection point.

5. If you're buying new drives, buy enterprise or Pro-tier. The price difference between a WD Red and a WD Red Pro or between an IronWolf and an IronWolf Pro is typically $20–40 per drive. For an 8-drive array, that's $160–320 in additional spend. Compare that to the cost of restoring 84 TB from backup — or worse, the cost of not being able to. The URE specification alone (10¹⁴ vs 10¹⁵) is worth 10× the price premium. The better warranty (5 years vs 3, typically) and higher workload rating are free bonuses.

6. Model your actual risk. Stop guessing. Use our RAID Configuration Calculator with your actual drive count, capacity, type, and workload. It computes URE risk, rebuild time, IOPS, and MTTDL across all five RAID levels for your specific configuration. The output will tell you whether your array is safe or whether you're running on borrowed time. In practice, the answer is usually the latter.

Frequently Asked Questions

Methodology & Disclosure

URE probability calculations use the standard exponential model P(URE) = 1 − exp(−bits_read × URE_rate), which assumes bit errors occur independently at a constant rate — consistent with manufacturer URE specifications and industry modeling practice. Drive URE rates are sourced from publicly available manufacturer datasheets as of June 2026: Seagate IronWolf/Exos product manuals, WD Red/Gold/Ultrastar specification sheets, and Solidigm/Samsung/Kioxia enterprise SSD datasheets. Rebuild time estimates assume 70% sustained throughput efficiency (80% for enterprise drives with higher native sequential throughput), benchmarked against community-reported rebuild durations on Synology, QNAP, TrueNAS, and mdadm platforms.

Backblaze drive failure statistics are sourced from the Backblaze Drive Stats for Q1 2026, the most recent quarterly report available at time of writing [1]. The 12% RAID 5 rebuild-triggered second-drive failure rate is drawn from the author's operational experience managing ~500 drives across three data centers over four years; it is not a peer-reviewed statistic and should be treated as anecdata. Backblaze Vault erasure coding architecture details are from Backblaze's public engineering documentation [2].

Disclosure: jslet is an independent research project. We are not sponsored by any storage vendor, drive manufacturer, or cloud provider. The RAID calculator on this site was built because the author got tired of explaining the URE math from scratch every time someone posted a "RAID 5 vs RAID 6" question on Reddit. No affiliate links, no sponsored recommendations.

References & Further Reading

1. Backblaze (Q1 2026). "Backblaze Drive Stats for Q1 2026." Quarterly hard drive failure analysis covering 283,000+ drives across Backblaze US and EU data centers. backblaze.com
2. Backblaze (2025). "The Backblaze Storage Pod Architecture." Technical documentation on the Vault storage architecture with Reed-Solomon erasure coding (17+3 configuration). backblaze.com
3. Seagate Technology (2026). "IronWolf and IronWolf Pro Internal Hard Drive Datasheet." URE specifications: IronWolf <1 in 10¹⁴, IronWolf Pro <1 in 10¹⁵. seagate.com
4. Western Digital (2026). "WD Red HDD Product Brief." WD Red (non-Pro): URE <1 in 10¹⁴. WD Red Pro: URE <1 in 10¹⁵. westerndigital.com
5. Leventhal, Adam (2009). "Triple-Parity RAID and Beyond." ACM Queue, Volume 7, Issue 11. The foundational paper on why RAID 5 is insufficient for large drives — mathematically correct in 2009, and drive sizes have increased 20× since then. acm.org
6. Wikipedia (2026). "Standard RAID Levels — Unrecoverable Read Error Risk." The canonical RAID comparison table with URE risk modeling. wikipedia.org
7. Ceph Foundation (2026). "Erasure Coded Pools — Architecture and Performance." Ceph documentation covering k+m erasure coding configurations, placement groups, and repair mechanics. docs.ceph.com
8. TrueNAS / iXsystems (2026). "ZFS RAIDZ and RAIDZ2 Best Practices." ZFS-specific RAIDZ1 vs RAIDZ2 guidance, including the URE handling difference (file-level failure vs array-level failure) that makes RAIDZ1 defensible in some scenarios. truenas.com

📜 Copyright & Attribution

"RAID 5 Is Dead: Why 12TB+ Drives Make Single Parity Mathematically Unsafe (2026)" — jslet Research, June 2026.
https://www.jslet.com/raid-5-is-dead

📡 Enjoyed this? RAID 5 died the day 12TB drives shipped. RSS covers one infrastructure assumption that expired while you weren't looking, every week. RSS Feed → | More options →