RAID (Redundant Array of Independent Disks)

RAID was first proposed in 1987 by David Patterson, Garth Gibson, and Randy Katz at UC Berkeley as a way to use cheap commodity hard disk drives to match the performance and reliability of expensive enterprise storage. The original paper coined the acronym as “Redundant Array of Inexpensive Disks”, later softened to “Independent Disks” once the technology moved from research curiosity to industry standard. The whole point of RAID is to take multiple physical drives and present them to the operating system as a single logical drive, with the underlying drives coordinating to provide better speed, better fault tolerance, or both.¹

The three core RAID techniques

Every RAID level is built from some combination of three fundamental techniques. Understanding these techniques is more important than memorizing each individual level, because the level number is essentially a recipe that combines them.²

• Striping. Data is split into blocks (typically 64 KB or 128 KB) and written across multiple drives in parallel. Reads and writes happen on multiple drives at once, multiplying throughput by the number of drives. RAID 0 is pure striping. Striping alone offers no redundancy; if one drive fails, data on all other drives becomes unusable because each file’s blocks are scattered across the array.
• Mirroring. Every block is written identically to two or more drives. The array continues to operate as long as at least one drive in the mirror set survives. RAID 1 is pure mirroring. Storage efficiency is poor (50% on a two-drive mirror), but read performance can be slightly better than a single drive because the controller can read from whichever mirror is faster.
• Parity. An additional drive (or distributed parity blocks) stores a mathematical checksum of the data on the other drives, computed using XOR. If any one data drive fails, the controller can reconstruct the missing data from the surviving drives and the parity. RAID 5 uses single distributed parity. RAID 6 uses double parity for two-drive failure tolerance. Parity is a compromise between mirroring’s redundancy and striping’s storage efficiency.

Hardware RAID vs software RAID vs firmware RAID

RAID can be implemented at three different layers, each with different trade-offs in cost, performance, and recovery complexity:³

• Hardware RAID. A dedicated controller card (Dell PERC, HP Smart Array, LSI MegaRAID, Adaptec) with its own processor, RAM cache, and often a battery-backed write buffer. The controller presents a single logical drive to the OS; the OS doesn’t know individual drives exist. Best performance and most consistent behavior, but the controller becomes a single point of failure and proprietary metadata makes recovery harder.
• Software RAID. The OS itself manages the array. Linux uses mdadm; Windows uses Storage Spaces; FreeBSD and Linux can use ZFS. The OS sees individual drives and combines them through software. Cheaper (no controller card), more portable across systems (drives can be moved to another machine running the same OS), and easier to recover because metadata is well-documented. The trade-off is CPU overhead for parity calculations on RAID 5 and 6.
• Firmware RAID (sometimes called “fake RAID”). A hybrid approach where the motherboard’s chipset provides RAID logic via UEFI/BIOS and OS drivers. Common on consumer motherboards from Intel (RST), AMD (RAIDXpert), and ASMedia. Behaves like hardware RAID from the OS perspective but uses CPU cycles like software RAID. Recovery is harder than software RAID because the metadata format is proprietary, and easier than full hardware RAID because the array is tied to the chipset rather than a specific add-in card.

JBOD: when you don’t actually want RAID

JBOD (“Just a Bunch of Disks”) is the absence of RAID: multiple drives connected to a system but managed as separate volumes or as a single concatenated volume with no redundancy or striping. JBOD is sometimes confused with RAID 0 because both can present multiple drives as a single logical volume, but the difference matters: JBOD writes data sequentially to one drive at a time, so a single drive failure only loses the data on that one drive. RAID 0 stripes data across all drives, so a single drive failure loses everything. JBOD is the right choice when capacity matters more than redundancy or performance, and when partial data loss is preferable to total loss.⁴

RAID levels are numbered configurations that combine the three core techniques in different ways. The number is just an identifier; higher numbers don’t mean better. RAID 6 is more fault-tolerant than RAID 5, but RAID 10 (also called RAID 1+0) is faster and often preferred for high-performance workloads. The five levels every administrator should understand are 0, 1, 5, 6, and 10.⁵

RAID 0: striping for speed only

RAID 0 stripes data across two or more drives with no redundancy. Storage efficiency is 100% (all drive capacity is usable) and performance scales nearly linearly with drive count: a four-drive RAID 0 with 600 MB/s SATA SSDs theoretically reaches 2,400 MB/s sequential reads. The fatal weakness is that any single drive failure destroys the entire array. RAID 0 is useful for video editing scratch disks, gaming, or any workload where the data is reproducible from backup and speed is paramount. It is never appropriate for primary storage of important data.

RAID 1: mirroring for redundancy

RAID 1 writes identical data to two or more drives. Storage efficiency is 50% on a two-drive mirror (you get the capacity of one drive). Read performance can match or slightly exceed a single drive because the controller can read from either mirror. Write performance equals single-drive speed. The array continues operating as long as one drive survives. RAID 1 is the standard choice for boot drives, small servers, and home NAS units with two drive bays. It’s simple, durable, and easy to recover: pull either mirror drive and read it directly on any compatible system.

RAID 5: striping with single parity

RAID 5 stripes data across three or more drives and stores a parity block per stripe, distributed across all drives. Storage efficiency is (n-1)/n: a five-drive RAID 5 has 80% usable capacity. Read performance is good (similar to RAID 0); write performance is slower because every write requires reading old data, computing new parity, and writing both. The array survives a single drive failure but no more. RAID 5 was the workhorse of business storage for two decades and remains common in NAS units, but it’s increasingly considered risky on large arrays because of rebuild cascade math (covered in the recovery section below).⁶

RAID 6: striping with double parity

RAID 6 extends RAID 5 with a second parity block per stripe, requiring at least four drives. Storage efficiency is (n-2)/n: a six-drive RAID 6 has 67% usable capacity. The array survives any two simultaneous drive failures. Write performance is slower than RAID 5 because two parity calculations are needed per write. RAID 6 has become the standard choice for arrays of 6 or more large-capacity drives because the second parity drive provides a safety margin during rebuilds, when the array is most vulnerable to additional failures.

RAID 10: striping over mirroring

RAID 10 (also written RAID 1+0) combines mirroring and striping by first creating mirrored pairs and then striping data across the pairs. Requires a minimum of four drives in pairs. Storage efficiency is 50% (same as RAID 1). Read and write performance approach RAID 0 because there’s no parity calculation overhead. The array survives multiple drive failures as long as both drives in any single mirror pair don’t fail simultaneously. RAID 10 is the standard choice for high-performance database and virtualization workloads where both speed and redundancy matter.

RAID levels at a glance

Level	Min drives	Storage efficiency	Fault tolerance	Read / Write speed	Best for
RAID 0	2	100%	None	Fastest / Fastest	Scratch disks, reproducible data
RAID 1	2	50%	1 drive	Good / Good	Boot drives, small servers
RAID 5	3	(n-1)/n	1 drive	Good / Slow	Small NAS, legacy use
RAID 6	4	(n-2)/n	2 drives	Good / Slower	Large NAS, modern arrays
RAID 10	4	50%	1 per mirror pair	Fast / Fast	Databases, high-IO workloads
JBOD	2+	100%	None	Single drive	Capacity-focused, partial-loss-OK

Beyond the standard levels, a few nested RAID levels matter in practice: RAID 50 (striped RAID 5 sets) and RAID 60 (striped RAID 6 sets) extend the principle to very large arrays. Synology Hybrid RAID (SHR) is Synology’s proprietary scheme that allows mixing drive sizes in a RAID 5 or RAID 6 layout, recovering the lost capacity that traditional RAID throws away when drives differ in size. ZFS RAIDZ1, RAIDZ2, and RAIDZ3 are software-RAID equivalents to RAID 5, 6, and triple-parity, with significant additional features like checksumming and copy-on-write semantics that prevent the silent corruption issues hardware RAID can hide.⁷

RAID arrays fail in ways that single drives don’t, because they introduce additional failure points (controller, metadata, rebuild process) on top of the underlying drive failures. The most common failure modes recovery labs see:⁸

• Single drive failure on a redundant array. The expected scenario RAID is built for. RAID 1, 5, 6, and 10 continue running on the surviving drives. Replace the failed drive, let the controller rebuild, done. No recovery needed beyond replacement parts. The array is in a degraded state until rebuild completes.
• Multiple simultaneous drive failures. The catastrophic scenario. Two failed drives on RAID 5, three failed on RAID 6, both drives in any mirror pair on RAID 10. The array is offline. Recovery requires lab work: imaging every drive separately, then virtually reconstructing the array from the images.
• Cascade failure during rebuild. A second drive fails (or develops unrecoverable read errors) while the array is rebuilding from the first failure. RAID 5 with a degraded array has zero remaining fault tolerance, so any second-drive issue during rebuild kills the array. The math is brutal on large arrays: a 4 by 20 TB RAID 5 reads 60 TB during rebuild, mathematically expected to encounter ~4.8 unrecoverable read errors at typical consumer drive URE rates of 1 in 10^14 bits.⁹
• Drive timeout mismatch (TLER/ERC). Enterprise and NAS drives are configured to give up on bad sectors quickly (~7 seconds) and let the RAID controller handle the recovery. Consumer desktop drives may spend 30 seconds to 2+ minutes retrying internally. The RAID controller’s command timeout (8 to 20 seconds) expires while the consumer drive is still retrying, and the controller marks the still-functional drive as failed. This is the single most common cause of “phantom” RAID 5 array drops on consumer drives.
• RAID controller failure. The dedicated hardware that manages the array dies (PSU surge, capacitor failure, ROM corruption). The drives are healthy but the OS sees no array. Recovery options: install an identical replacement controller (works most of the time, sometimes), or send the drives to a lab that can reconstruct the array virtually from the metadata on the drives.
• Metadata corruption. The configuration data the controller stores on each drive (or in firmware) describing the array layout becomes corrupted or partially overwritten. Symptoms include the controller refusing to recognize the array, marking healthy drives as foreign, or showing the wrong RAID level. Recovery requires reading the metadata from each drive and reconstructing the original array geometry by hand.
• Accidental array reinitialization. Administrative mistake. Someone runs the controller’s “create new array” or “initialize” function on a populated array, overwriting the metadata and (depending on the controller) potentially zeroing data blocks. Recovery is possible if the data hasn’t been overwritten by new writes; the original RAID layout is reconstructed from surviving file system structures.
• Power surge or simultaneous power loss during write. A power event during heavy writes can leave parity blocks inconsistent with data blocks, creating a “write hole” condition where the array appears intact but reads return corrupted data. Hardware RAID controllers with battery-backed write cache prevent most of these; software RAID and consumer-grade controllers without BBWC are vulnerable.

RAID 5 rebuild cascade math: why bigger arrays are riskier

Consumer hard drives have a published unrecoverable read error rate of roughly 1 URE per 10^14 bits read, or about one URE per 12.5 TB on a perfectly healthy drive. RAID 5 rebuilds require reading every byte from every surviving drive. The math gets ugly fast on large modern arrays:

• 4 drives × 4 TB = 12 TB of reads during rebuild = ~0.96 expected UREs (likely successful)
• 4 drives × 8 TB = 24 TB of reads = ~1.9 expected UREs (some risk)
• 4 drives × 16 TB = 48 TB of reads = ~3.8 expected UREs (significant risk)
• 4 drives × 20 TB = 60 TB of reads = ~4.8 expected UREs (very high risk)

On a degraded RAID 5 array, every single URE causes a stripe to fail because there’s no remaining redundancy. This is why RAID 6 has effectively replaced RAID 5 for arrays of 6+ drives or 8+ TB drives in 2026. Enterprise NAS drives with lower URE rates (1 in 10^15 or 10^16) and shorter timeouts mitigate but do not eliminate the math.

Warning signs your RAID array is failing

Most RAID arrays give clear warnings before catastrophic failure if anyone is monitoring them. The problem is that nobody monitors them until something breaks. Watch for these in combination:

• SMART warnings on individual drives showing rising reallocated sectors, pending sectors, or read error rates. Replace drives before they fail; once one drive fails, the rebuild puts maximum stress on the others.
• Controller logs reporting predictive failures or media errors. These are the controller telling you a drive is on its way out. Replace it during planned maintenance, not during an emergency rebuild.
• Sustained slow performance compared to historical baselines, especially on writes. A degraded array can be 5 to 10 times slower than a healthy one, and a healthy array experiencing controller cache battery failure runs slow because writes default to write-through mode.
• “Foreign configuration” or “missing drives” alerts on hardware controllers. Often a sign of metadata mismatch after maintenance, sometimes a sign of a marginal drive being intermittently dropped.
• Drives showing up and disappearing in the controller management software. The phantom-drop pattern from TLER/ERC mismatch on consumer drives in a RAID 5 or 6 array.
• Battery health warnings on RAID controller. A failed battery on a write-back cache controller forces write-through mode (slower) and creates write-hole risk during power events.
• Sudden silence from the array’s monitoring email alerts. Email alerting silently breaking is extremely common. Test the alerts periodically; an array that hasn’t sent any alerts in months might be working perfectly, or might have lost SMTP config months ago.

Where RAID is implemented determines both how it performs and how it fails. The four main implementation tiers, in roughly increasing order of cost and complexity:

Software RAID through the OS

The OS itself handles RAID logic. Linux mdadm is the dominant Linux software RAID stack; Windows Storage Spaces is the modern Windows equivalent (replacing the older Disk Management dynamic disks). FreeBSD and Linux can use ZFS, which goes beyond standard RAID to provide checksumming, copy-on-write, and snapshots. Software RAID is the most portable: drives can be moved to another machine running the same OS and the array reassembled. It’s also the cheapest because no controller card is required. The trade-off is CPU overhead, which matters less in 2026 than it did 10 years ago because modern multi-core CPUs handle parity calculation easily.

Firmware RAID through the motherboard chipset

Intel Rapid Storage Technology (RST), AMD RAIDXpert2, and similar consumer-motherboard solutions implement RAID through the chipset’s UEFI firmware and OS-level drivers. They behave like hardware RAID from the user perspective but actually run on the host CPU. Performance is similar to software RAID, but the array is tied to the specific chipset family (and sometimes specific motherboard). Moving the array to a different motherboard usually requires a compatible chipset and driver. Recovery is harder than software RAID because the metadata format is proprietary and not always documented.¹⁰

Hardware RAID through dedicated controllers

A dedicated PCIe card with its own processor (often an Intel IOP or LSI/Avago/Broadcom ROC chip), DRAM cache, and battery-backed or flash-backed write buffer. Examples: Dell PERC, HP Smart Array, LSI MegaRAID, Adaptec, Broadcom MegaRAID. Performance is consistent because the controller handles all RAID operations independent of the host CPU, and the write cache absorbs bursts. The trade-off is the controller becomes a single point of failure, and the controller’s firmware uses proprietary metadata that’s much harder to recover from without the original card.

Storage appliance RAID (NAS/SAN)

Dedicated storage devices like Synology, QNAP, NetApp, EMC, or Pure Storage that integrate the RAID logic, drive enclosure, and network protocols into a single product. From the user’s perspective, the array is just shared storage; the RAID details are hidden. These products often use proprietary RAID variants (Synology SHR, NetApp WAFL, ZFS in TrueNAS) that offer features standard RAID lacks but tie the array to the appliance’s firmware. Recovery typically requires either an identical replacement appliance or specialized lab work to extract data from the underlying drives.

RAID solves a specific problem (uptime in the face of drive failure) and does it well. It does not solve the broader problem of data protection, which leads to the most common RAID misuse: people relying on RAID as their only line of defense against data loss.

RAID vs other data protection strategies

Property	RAID	Single drive + backup	NAS with snapshots	Cloud backup
Drive failure tolerance	Yes (most levels)	No	Yes (NAS RAID)	N/A
Accidental deletion recovery	No	Yes (from backup)	Yes (from snapshot)	Yes
Ransomware recovery	No	Yes (offline backup)	Partial (snapshot)	Yes (immutable backup)
Fire / theft / disaster	No (same location)	If backup off-site	No (same location)	Yes
Recovery time	Hours (rebuild)	Hours-days (restore)	Minutes (snapshot)	Hours-days (download)
Cost (relative)	Medium-high	Low-medium	Medium-high	Subscription
Best as	Uptime layer	Working storage	Working + recent recovery	Disaster recovery

RAID advantages and drawbacks