RAID levels, and the one failure they actually cover
RAID protects against a drive dying. That is the whole list. Every other way a file disappears, deleting it, encrypting it with ransomware, corrupting it in an application, losing the machine to fire or theft, reaches every disk in the array at the same instant and at the same speed. The array is a device that keeps serving reads while a disk is broken, which is an availability feature, and buying it as a safety feature is how people end up with one very reliable copy of nothing.
The levels, and what each one survives
The original taxonomy is nearly forty years old. Patterson, Gibson and Katz proposed five levels in 1988, and their names describe the mechanism rather than a marketing tier: "First Level RAID: Mirrored Disks", "Second Level RAID: Hamming Code for ECC", "Third Level RAID: Single Check Disk Per Group", and "Fifth Level RAID: No Single Check Disk", the last being the one that spreads parity across every member instead of dedicating a disk to it. Levels 2 and 3 did not survive contact with the industry. What runs today is 0, 1, 5, 6 and 10.
Linux's md(4) states the tolerances precisely. The number of devices that may fail "is one for RAID levels 4 and 5, two for RAID level 6, and all but one (N-1) for RAID level 1". RAID0 has "zero redundancy" and is a striped array, so it is not in this conversation at all: it multiplies your exposure by the number of members. RAID10's tolerance is "dependent on configuration", because which second disk dies decides whether you are fine or finished.
| Level | Survives | Capacity cost | The specific weakness |
|---|---|---|---|
| 0 | nothing | none | Any one disk takes the whole array with it |
| 1 | all but one member | half, or more with more mirrors | Rebuild reads the surviving copy end to end |
| 5 | one disk | one disk | A second failure during rebuild loses everything |
| 6 | two disks | two disks | Slower writes, longer rebuild |
| 10 | depends which disks | half | Two failures in the same mirror pair is fatal |
The rebuild window is the actual risk
An array is not dangerous when a disk dies. It becomes dangerous afterwards, during the rebuild, and for three reasons at once.
The array is running without redundancy, or with less of it. Every remaining disk is read from end to end, which is the heaviest sustained work they will ever do. And they are all the same age, from the same batch, with the same hours and the same thermal history, because that is how arrays get built.
Rebuild duration is set by capacity, and capacity has grown without a matching growth in throughput. A WD Red Plus tops out at 12TB across its current range, from the 2TB WD20EFPX to the 12TB WD120EFGX. The WD Gold line reaches 26TB. Reading 12TB or 26TB off a spinning disk, while the array also serves whatever normal work it exists to do, is measured in many hours and often in days.
Backblaze publishes the failure side of this from a fleet large enough to mean something. Its Q1 2026 figures are "30,203,180 drive days, 1,030 drives failed, 1.24% AFR" across 341,263 drives. A 1.24% annualized failure rate is low, and it is also not zero across four or five identically aged disks being worked harder than they have ever been worked.
The unrecoverable read error argument, stated carefully
This is where the internet overreaches, so here is the arithmetic and then the caveat.
Drive datasheets publish an error rate. The WD Red Plus product brief lists, for every capacity in the range, "Non-recoverable errors per bits read" of "<1 in 1014", meaning fewer than one in ten to the fourteenth bits. Ten to the fourteenth bits is 12.5 terabytes.
A 12TB drive holds 9.6 times ten to the thirteenth bits. Rebuilding a five-disk RAID 5 built from them means reading four of those surviving drives completely, so about 3.84 times ten to the fourteenth bits. Set against a rate of one error per ten to the fourteenth bits, the naive expectation is roughly 3.8 errors, and on a classical RAID 5 a single unrecoverable read during rebuild is enough to end it, because there is no second parity to reconstruct from.
That calculation is why people say RAID 5 is dead on large drives. Two things make it weaker than it looks.
The specification is a bound, not a measurement. It says less than one in ten to the fourteenth. A drive that never errs also satisfies it. Vendors publish a worst case they are willing to warrant, and the observed rate in the field is generally better, which is why plenty of people rebuild large RAID 5 arrays without incident and reasonably conclude the doom-math is wrong.
And an unrecoverable read is not automatically fatal. md(4) describes an active repair path: "A read-error will cause md to attempt a recovery by overwriting the bad block. i.e. it will find the correct data from elsewhere, write it over the block that failed, and then try to read it back again." That works when the data can be found elsewhere, which during a degraded RAID 5 rebuild is exactly what is missing.
So the honest form of the argument is narrower than the popular one. The URE math does not prove RAID 5 will fail. It shows the failure probability is not negligible, that it scales with drive size, and that RAID 6 buys a second parity for precisely this window. On multi-terabyte drives that is enough to prefer RAID 6, without needing the stronger claim.
Detecting corruption is a separate job from surviving a disk
Classical RAID compares nothing. It reconstructs a missing disk from parity, and if a disk returns wrong data rather than an error, parity does not tell you which member lied.
Checksumming filesystems close that gap, and the OpenZFS documentation is explicit about which operation does what. A scrub "examines all data in the specified pools and verifies each block's checksum", and "For replicated (mirror, raidz, or draid) devices, ZFS automatically repairs any damage discovered during the scrub". Detection and repair are separate capabilities: the checksum finds the bad block, and only redundancy can fix it. A single-disk pool detects corruption and can do nothing about it.
The distinction from a rebuild matters too. "Resilvering only examines data that ZFS knows to be out of date (for example, when attaching a new device to a mirror or replacing an existing device), whereas scrubbing examines all data to discover silent errors due to hardware faults or disk failure." A resilver is not a scrub, and running both is not possible at once: "Because scrubbing and resilvering are I/O-intensive operations, ZFS only allows one at a time."
btrfs offers the same idea with an important exception. Its own status page rates RAID56 as unstable, gated behind CONFIG_BTRFS_EXPERIMENTAL, and states that "The RIAD5/6 block group is still not implemented and on-disk format is not finalized (last change was in 6.12)". btrfs mirroring and striping are used in production widely; its parity levels are not the place to put data you care about.
Hardware, software and getting the array back
A hardware controller stores its array metadata in a format of its own. If the controller dies, an array often needs a compatible controller to read again, and "compatible" can mean the same family and firmware generation. Linux md and ZFS both keep their metadata on the disks in a documented format, so the recovery path is any machine with the same software, which for a home array is usually the better trade.
What none of it covers
Deleting the wrong directory replicates instantly. Ransomware encrypts through the filesystem, so every mirror faithfully stores the encrypted version. Application-level corruption writes a valid but wrong file, and the array stores it correctly. A power event, a controller fault or a filesystem bug can take the whole set. Fire, flood and theft take the box.
An array raises the number of simultaneous hardware failures your data survives from zero to one or two. It does nothing about the events that actually destroy home data, all of which are single-copy events reaching every member at once. Run the array for uptime and for keeping a large volume online. Run separate, versioned, off-site copies for the rest, and verify you can restore from them, because the array will not be the thing that saves you.