Will a Read Error Kill Your RAID 5 Rebuild?

You are picking a RAID level for four or six new drives, and somewhere in the research somebody has told you RAID 5 is dead. The argument is always the same: modern drives are so large that a single unreadable sector during a rebuild is close to a certainty, so the second you lose a drive you have lost the array.

That argument rests on one number printed on your drive's datasheet. It is worth knowing exactly what that number is, because it is a worst-case bound rather than a measured rate, one major vendor has quietly changed the unit it is printed in, and the failure it describes is usually not "the array is gone."

The number, as the datasheets actually print it

Every hard drive datasheet carries a row for unrecoverable read errors. It is the manufacturer's stated ceiling on how often the drive will return a read failure that its own error correction cannot fix. Here is what four current sheets say.

One bit in 10¹⁴ works out to one error per 12.5 TB read, since a terabyte is 8 × 10¹² bits. The 10¹⁵ class drives are rated ten times better, at one per 125 TB.

That ten-fold gap is the real division on the table, and it does not fall neatly along a consumer-versus-enterprise line. The WD Red Plus is a NAS drive sold for exactly this job and it carries the 10¹⁴ figure, while Seagate's NAS drive one tier up carries 10¹⁵.

The calculation that makes RAID 5 look dead

Take four 4 TB drives in RAID 5. One dies, you put in a replacement, and the array reads all three survivors end to end to reconstruct it. That is 12 TB of reading, or 9.6 × 10¹³ bits.

If you treat the datasheet figure as a per-bit probability and every bit as an independent coin flip, the chance of hitting at least one error across that pass is 1 minus (1 minus 10^-14) raised to the power of 9.6 × 10¹³, which is about 62%.

Now scale the drives up. Four 24 TB BarraCudas means reading 72 TB, or 5.76 × 10¹⁴ bits, and the same formula returns 99.7%. Even at the better 10¹⁵ rating, 72 TB still gives you about 44%. That is the whole "RAID 5 is dead" case in three numbers.

It is a clean calculation. Every assumption underneath it is doing more work than it looks like.

The spec is a ceiling, and it is not stated consistently

Look at the wording again. Seagate's rows say "Max" or "<1 in." Western Digital's says "<1 in." None of them say "on average" or "typically."

These are warranty bounds. A drive that never produces a single unreadable sector in its life is fully inside the spec, and so is one that produces errors at a tenth of the stated rate. Plugging a stated upper limit into a probability formula as though it were the expected value is the single largest source of overstatement in the calculation above.

The unit is shakier than it looks too. Seagate's 2020 BarraCuda datasheet prints the row as "Nonrecoverable Read Errors per Bits Read, Max: 1 per 10E14." The 2024 sheet for the 16TB, 20TB and 24TB models keeps the identical row label and changes the value to "1 sector per 10E14."

The label says bits and the value says sectors, on the same line, in the same table. The reading that makes engineering sense is that the rate is still per bits read and Seagate is clarifying that what you lose is a whole sector rather than a bit, which is true and does not change the magnitude. But nothing on the sheet says that, and if you instead read it as one sector per 10¹⁴ sectors, the implied endurance jumps by a factor of several thousand. A number this load-bearing should not be ambiguous on the vendor's own document.

The errors are not spread evenly, and that breaks the formula

The independent-coin-flip model assumes every bit on every drive carries the same small risk. The largest field study of this says otherwise.

Bairavasundaram, Goodson, Pasupathy and Schindler analysed error logs from production storage over 32 months across 1.53 million disks, published as An Analysis of Latent Sector Errors in Disk Drives at SIGMETRICS 2007. A latent sector error is precisely the failure mode in question, a sector that reads back bad and is not noticed until something touches it.

Across the whole sample, 53,820 disks developed one or more such errors. That is 3.45%. Broken out by class, "about 8.5% of all nearline disks are affected by latent sector errors while only 1.9% of all enterprise class disks are affected."

The distribution within that affected minority matters just as much. The median affected drive had three errors, the most common count was one, and the paper reports that 37% of nearline error disks "have only one error; i.e., they do not develop any additional latent sector errors after the first one." More than 80% had fewer than 50.

So the risk is concentrated. Most drives carry none of it, a small group carries a little, and a tiny group carries almost all of it. The paper's own summary states the errors have spatial and temporal locality rather than arriving independently. A model that smears the same per-bit probability evenly across a healthy array is describing a drive population that does not exist.

What actually happens when a rebuild hits a bad sector

The scary version of this story ends with the rebuild aborting and the array being written off. Whether that happens is a property of your RAID implementation, not of physics, and the two implementations most home and small-office arrays actually run do not behave that way.

Linux md keeps a bad block log. The kernel's md admin guide documents bad_blocks and unacknowledged_bad_blocks as per-device sysfs files listing known bad blocks by start address and length. It also describes the errors attribute as a count of read errors "that have been detected on this device but have not caused the device to be evicted from the array (either because they were corrected or because they happened while the array was read-only)." A read error is a recorded event, not automatically a dead member.

ZFS is more explicit still. The OpenZFS troubleshooting guide notes that checksum errors appearing on several disks at once usually indicate "one unrecoverable block, not simultaneous failure of the whole row," and that when a block genuinely cannot be reconstructed, zpool status -v lists the affected files by name. Those files are gone and you restore them from backup. The pool keeps running.

Neither of those is a good afternoon. Both are a long way from losing 72 TB.

The risk people skip is the second whole drive

While everyone argues about read errors, the failure RAID 5 genuinely cannot survive gets less attention: a second complete drive failure before the rebuild finishes.

Our RAID Storage Calculator estimates rebuild time at a sustained 200 MB/s, which puts a 24 TB drive at about 33 hours and a 4 TB drive at about 5.6 hours. Backblaze's 2025 Drive Stats report covers roughly 344,196 drives as of December 31, 2025 and puts the year's annualized failure rate at 1.36%, with a lifetime figure of 1.30%.

Spread 1.36% a year evenly across a 33 hour window and you get about a 0.005% chance per surviving drive, or roughly 0.016% across three of them. That is about one rebuild in 6,400.

Treat that as a floor, not an estimate. It leans on exactly the independence assumption this post has spent several paragraphs criticising, and drives bought together in one order share an age, a manufacturing batch, a temperature and a vibration environment. Real second failures cluster. The number is still useful for showing that the scale of this risk is nothing like 62%.

What to do with all of this

Scrub on a schedule, and treat it as the main defence. The latent sector error paper found that "more than 60% of these errors are discovered through scrubbing," and a bad sector discovered on a healthy array gets rebuilt from parity and remapped. The same sector discovered during a rebuild is the one you cannot fix. Scrubbing converts the second case into the first.

Check the workload rating on the drive you are about to buy, because it is the spec that most cleanly separates a desktop drive from a NAS drive. The 24TB BarraCuda is rated for 120 TB/year and 2400 power-on hours a year. One rebuild pass on a four-drive array reads 72 TB, which is 60% of that annual allowance in a day and a half, in a box that will run 8760 hours a year rather than 2400. The IronWolf Pro on the same table is rated for 300 TB/year and the full 8760 hours.

Then pick the RAID level with the read errors in mind rather than only the drive failures. RAID 6 and RAIDZ2 hold two parity units instead of one, so during a single-drive rebuild there is still redundancy left over, and an unreadable sector on a survivor gets reconstructed instead of ending up in a list of damaged files. That is the real reason double parity is the default advice for large drives, and it costs you one drive of capacity out of the array.

If you want to see what that trade looks like in terabytes for your specific drive count, our RAID Storage Calculator compares every valid level side by side with usable space, efficiency, fault tolerance and rebuild time. Nothing uploaded.