RAID levels explained: 0, 1, 5, 6, 10 — capacity, speed and failure tolerance for each level

What the name means, and why arrays exist

RAID came from a 1988 research proposal that combined many inexpensive disk drives into one logical unit. The original expansion was "Redundant Array of Inexpensive Disks"; the industry later standardized on "Independent," which is the more accurate term since the drives in a modern array are often far from cheap. The proposal's insight is still the reason arrays exist: by splitting data across drives (striping) you get capacity and throughput that no single drive can match, and by adding redundancy (mirrors or parity) you get a system that keeps working when one of those drives dies.

Three properties are what you're actually choosing when you pick a level: usable capacity (how much of the raw drive space the array hands to the filesystem), performance (how the layout changes read and write behavior), and failure tolerance (how many drives can fail before the data is gone). Every level in this guide trades among exactly those three, and the calculator in Section 08 quantifies the first one.

The three building blocks: striping, mirroring, parity

Striping splits data into blocks and distributes them round-robin across multiple drives, so a single read or write can be served by — or written to — several drives in parallel. Striping is where RAID gets its speed, and it's the reason RAID 0 is fast and also why RAID 0 is fragile: when the data of every file is scattered across every member, losing one member means losing pieces of everything.

Mirroring keeps identical copies of the data on two (or more) drives. Every write goes to all copies; reads can come from any of them. Mirroring is the simplest redundancy there is — it tolerates a member failure with no reconstruction math — and its price is direct: two-way mirroring hands half the raw capacity to redundancy.

Parity is a computed checksum block that can stand in for any one (RAID 5) or any two (RAID 6) missing data blocks in a stripe. Parity is cheaper than mirroring — one parity drive's worth instead of half the array — at the cost of write complexity (updating parity takes extra I/O) and of a longer, more dangerous rebuild, because the replacement data has to be recomputed from the survivors rather than simply copied.

Hardware, software, and operating-system-managed RAID

The same level can be implemented three ways, and they don't behave identically. A hardware RAID controller is a dedicated card (often with its own cache and, on server-grade units, a battery or capacitor backup) that presents the array to the OS as one or more disks; the array configuration lives in the controller. Software RAID (Linux md/DM, Windows Storage Spaces) is managed by the OS on the CPU — no special hardware, configuration survives in the OS, and performance depends on the CPU and cache. Filesystem-level pools (ZFS and similar) go further: redundancy plus checksumming of all data and metadata, with self-healing behavior classic RAID doesn't have.

The trade-offs are real, not religious: hardware controllers can offload work and offer cache/BBU features, but they're a cost, a potential single point of failure, and a portability problem if the card dies. Software RAID is flexible and free, but it uses CPU cycles and the array is tied to that OS installation. When a claim in this guide says "the controller" or "the implementation," it's because the answer can differ between these three — a level's mathematics (capacity, tolerance) is the same everywhere; its speed, rebuild behavior, and failure handling are not.

Raw capacity, usable capacity, and what the filesystem actually sees

Keep three numbers straight. Raw capacity is the sum of the drives' labeled sizes. Usable capacity is what the RAID level's layout hands out: N×S for RAID 0, S for a two-drive mirror, (N−1)×S for RAID 5, (N−2)×S for RAID 6, (N/2)×S for RAID 10 — where N is the drive count and S is the smallest member's capacity. Redundancy overhead is the difference: the raw space consumed by copies and parity.

The number the filesystem reports will be a little smaller than the usable figure, and that's normal: the filesystem reserves space for its own metadata, drives' actual capacity falls slightly short of their decimal label, and some controllers reserve a small slice for metadata or spares. None of this is an error — it's why this guide presents formulas as planning estimates and never as byte-exact promises.

How striping works

A RAID 0 array divides data into blocks (the stripe unit, typically 64 KB to 1 MB depending on the implementation) and writes them in rotation: block 1 to drive 0, block 2 to drive 1, and so on. The practical consequence is parallelism — a large sequential read of a 4 GB file can be served by all four drives simultaneously, and a write is committed when the (fewer, wider) parallel operations complete. The more members, the more I/O can happen at once, up to the point where the controller, bus, or drives themselves become the limit.

Capacity: N × S, minimum two drives

RAID 0 wastes nothing on redundancy, so usable capacity is the full raw total: N × S (S = smallest drive). Two 8 TB drives give a 16 TB volume; four give 32 TB. The minimum is two drives — a one-drive "RAID 0" is just a drive. The only capacity cost in the array is the small filesystem and controller overhead discussed in Section 01, which applies to every level equally.

Why one failed drive ends everything

Because every file's blocks are spread across every member, a single failed drive doesn't lose "a file" — it loses one block out of every stripe, which means it loses pieces of all the data. With no mirror to copy from and no parity to recompute from, the array has no way to reconstruct anything, and the whole volume is unavailable. Most implementations mark the array failed immediately; the data is recoverable only with specialized forensics on the surviving drives, which is a specialist service, not a recovery plan.

Drive count makes this worse in a way that surprises people: a four-drive RAID 0 has four times the failure surface of one drive, so the array's expected lifetime is shorter than any single member's. Adding drives to a RAID 0 buys capacity and speed, and it proportionally increases the chance that something in the array fails. The math is unforgiving precisely because there is no "one failure is okay" state.

Where RAID 0 fits — and where it doesn't

RAID 0 is a legitimate tool when the data is regenerable: video-editing scratch disks, render caches, build output, temporary datasets, game storage you can re-download. In those roles it's excellent — maximum capacity, maximum throughput, minimum cost per usable terabyte. The inapplicable role is anything whose only copy lives in the array: photo libraries, databases, project files. The decision rule is one question: "If this array died tonight, would I lose anything I can't recreate?" If yes, RAID 0 is out regardless of how much you like the speed.

How mirroring works, and what it costs

Every write is committed to both members; a read can be served by either. Usable capacity is S — one drive's worth — so a two-drive mirror of 8 TB drives is an 8 TB volume with 100% redundancy overhead. The minimum for the classic two-way mirror is two drives; larger even counts can be arranged as N/2 pairs (a common software-RAID layout), giving (N/2)×S usable, but the standard form — and the one this guide's calculator uses — is the single pair.

Writes are bounded by the slowest member (the controller typically waits for the slower drive to acknowledge), and there's no parity penalty — a mirrored write is just "write twice," not the multi-step read-modify-write that parity levels require. That makes RAID 1's write behavior among the best of the redundant levels, which is why operating-system volumes so often run on it.

Failure behavior: one of two, and the second one is fatal

A two-way mirror tolerates exactly one failed member: with drive A gone, drive B holds a complete, current copy and the array keeps serving — degraded, at single-drive capacity, with no performance math involved in the reads. Which member failed doesn't change what's recoverable in a two-way mirror (the survivor is always the full dataset); what does matter operationally is that the array now has zero redundancy, and the second member is the only thing standing between the system and data loss. Replacement and resync are not optional maintenance; they're the window where the mirror is genuinely one bad day from a disaster.

And the mirror's protection has a boundary people blur: it protects against the drive failing, not against the data being wrong. Both members receive the same writes — the same corruption, the same bad update, the same ransomware. A mirror is one redundant copy, and the backup (Section 01) is still the only thing that survives a logical failure.

Reads, and the rebuild

Read performance depends on the implementation: a capable controller or software stack can stripe reads across both mirrors (interleaving requests between them for up to roughly double single-drive throughput for concurrent reads), while a basic setup simply reads from one member at a time. Either way, mirror reads never involve reconstruction — the data is there, verbatim — which keeps latency low and behavior predictable.

When a member fails, recovery is a resync: the replacement drive receives a complete copy of the surviving member. There's no parity computation, so resyncs are typically faster and less CPU-intensive than parity rebuilds — the limiting factor is raw copy bandwidth. Until the resync completes, the array is still a degraded mirror with zero redundancy, so the same urgency applies: finish the resync, then verify it (Section 10 covers verification and scrubbing).

Two-way mirrors versus three or more copies

Nothing stops a mirror from having three (or more) members — several software stacks and ZFS-style pools support them — and a three-way mirror tolerates any single failure with a full copy still redundant behind it. The cost scales linearly (three drives, one drive usable), so three-way mirrors are a deliberate choice for very critical, capacity-tolerant roles rather than a default. If someone shows you a "RAID 1" with five drives, ask what layout it actually is: one pair plus spares, two pairs striped, or a multi-way mirror — the failure behavior is different in each case, and the label alone doesn't tell you which.

Distributed parity — and why it's not on one disk

In a four-drive RAID 5, each stripe spans all four drives and holds data in three of them plus one parity block — the XOR-derived value that, combined with any three of the four blocks, reproduces the missing fourth. The key design decision: the parity position rotates from stripe to stripe. A layout with all parity on one dedicated disk is a real thing (RAID 4) — and it's obsolete for a specific reason: that one disk becomes the read and write bottleneck for every I/O, because every stripe touches the parity. Distributing parity spreads that traffic across all members, which is why "RAID 5" means distributed single parity, full stop.

Usable capacity is (N − 1) × S with a minimum of three drives: four 8 TB drives give 24 TB (one drive's worth to parity), and the redundancy overhead is 1/N of raw — 25% at four drives, 20% at five, falling as the array grows. That shrinking overhead is RAID 5's core economic argument against mirroring in capacity-oriented roles.

The write penalty

Updating data in a parity array means the parity block stays correct, and that costs extra I/O. A full-stripe logical write typically unfolds as a read-modify-write cycle: read the old data block, read the old parity block, compute the new parity, write the new data, write the new parity — on the order of four physical I/O operations where a plain write is one (implementations vary, and write-back cache changes the timing, but not the shape). Small random writes hit this hardest, because they can't avoid the extra reads; large sequential writes amortize it well. That's the mechanical reason "RAID 5 is great for files, awkward for databases" is a rule of thumb that keeps coming up.

Reads, by contrast, are close to single-drive speed for random access — a healthy RAID 5 serves normal reads without touching parity at all — which is why RAID 5's profile is "reads fine, writes pay a tax." The tax is the price of the cheaper redundancy, and it shows up most in exactly the workloads (random write IOPS) where RAID 10's lack of parity later becomes its advantage.

Degraded operation, and the window that actually matters

When one member fails, the array doesn't stop: it goes degraded, and every read that needed the missing block is reconstructed on the fly from the other data blocks plus parity. The system stays up — that's the point of the level — but it's now running with zero redundancy, and every I/O on affected stripes costs extra reads and CPU.

Here's the part that separates a working understanding from the label: the dangerous window is from the first failure until the rebuild finishes, which on large drives can be many hours. During that window, a second member failure ends the array. And even with all other members healthy, the rebuild itself reads the entire surviving set — and if one of those reads hits an unrecoverable read error (latent sector damage that only reveals itself when read), the rebuild can fail or the array can be lost. Neither outcome is guaranteed — rebuilds succeed most of the time — but the risk is real, scales with drive size and age, and is the technical reason "RAID 5 tolerates one failure" quietly assumes the rebuild works and nothing else fails meanwhile. That assumption is exactly what RAID 6 removes.

RAID 5 with large drives: why the math got uncomfortable

Rebuild time is roughly proportional to the capacity being reconstructed, so the same four-drive layout that rebuilt in under an hour with 2 TB drives takes several times longer with 16 TB drives — a longer zero-redundancy window, and more sectors read during the rebuild, which is also where unrecoverable-read risk accumulates. This is why many capacity-oriented environments have migrated from RAID 5 to RAID 6 (or to pool-style layouts) as drive sizes grew: not because RAID 5 is wrong, but because its single-parity budget was designed for an era of smaller disks. If you're building a new RAID 5 on large drives, the honest requirements are: quality drives with low AFR, spares on hand, monitoring that pages on failure, and a backup that doesn't depend on the rebuild succeeding.

Two independent parity sets

RAID 6 stores two parity values per stripe, computed with independent algorithms (commonly one algebraic and one Galois-field-based, so the two syndromes carry independent information). The property that matters: with two missing blocks in a stripe, the two parity equations have exactly enough information to solve for both unknowns — which is why any two failed members, in any positions, are recoverable from the survivors. Usable capacity is (N − 2) × S with a minimum of four drives: six 8 TB drives yield 32 TB, and the overhead falls from 50% (four drives) to about 33% (six) to 25% (eight) as the array grows.

What dual parity costs: writes, and degraded reads

The write path is heavier than RAID 5's: a full-stripe update now maintains two parity values, adding reads and writes to the cycle (implementations batch this differently, but the direction is unambiguous — RAID 6 writes cost more than RAID 5's, and random small writes feel it most). Degraded-mode reads also get more expensive: reconstructing from one failed member in a two-failure state means combining two surviving data blocks with both parities. In practice this means RAID 6's throughput is somewhat below RAID 5's in write-heavy and degraded scenarios — a real but usually secondary concern next to what it buys.

"Tolerates two" — and what it does not guarantee

From a healthy state, RAID 6 survives any two member failures simultaneously or sequentially — a materially different safety profile from RAID 5, because the first failure no longer opens a fatal window: the array can sit degraded on one drive, get serviced on a normal schedule, and still absorb the second. The rebuild after a single failure also starts from a stronger position — the reconstruction has the second parity set available throughout, which reduces (not eliminates) the exposure to an unrecoverable read error mid-rebuild.

The boundary of the guarantee is worth stating plainly: RAID 6 tolerates two failed members. A third failure — before or during the rebuild of the second — loses the array, and a rebuild from a two-failure state is the slowest, most I/O-intensive one the level performs. "Tolerates two" is also a statement about member failures; a controller failure, a cabling fault, or a human removing the wrong drive is outside the parity math entirely. Dual parity buys time and margin — it doesn't buy immortality.

Where RAID 6 beats RAID 5 — and where the difference is academic

The case for RAID 6 is strongest in the capacity-oriented, large-drive world: many-drive arrays where the rebuild window is long, where spares and on-call coverage aren't instant, and where the extra drive's overhead (often 1–2 drives out of 8 or more) is affordable against the risk it removes. It's the default recommendation in most modern storage guidance for exactly that profile. Where the difference matters less: small arrays (four to six drives) on modest drives with fast spare coverage, where RAID 5's single-parity window is short and the extra parity drive is a large fraction of the array — and any environment with write-heavy random I/O, where RAID 6's heavier write path is a genuine daily cost. Implementation quality matters too: not every controller or software stack rebuilds RAID 6 with equal efficiency, so "RAID 6" on a basic consumer controller is not the same experience as on a serious storage appliance.

Structure: mirrors first, then stripes

In a four-drive RAID 10, drives are paired into two mirrors, and the array stripes data across the pairs. Usable capacity is (N / 2) × S with a minimum of four drives, and the count must be even (odd counts can't form complete pairs). A naming footnote that saves confusion later: "RAID 10" conventionally means 1+0 — mirrors striped together. The reverse construction, 0+1 (stripes mirrored as whole units), exists but is rarely offered because it's strictly worse: it gives up more capacity and tolerates less, so when a menu says "RAID 10," this is the layout that's meant.

The structural consequence is that data from any given stripe exists in two places — once in each of two different mirror pairs — so the array can keep serving as long as at least one member of every pair that holds needed data is alive. That "at least one per pair" condition, not a fixed failure count, is the actual tolerance rule.

Performance: the best write story among the redundant levels

Writes stripe across the pairs in parallel and land on a mirror member each — two parallel writes, no parity reads, no recomputation. That makes RAID 10 the standard answer for random-write-heavy roles: virtual machine disks, databases, transactional workloads — exactly the profiles where RAID 5's write penalty hurts. Reads stripe across pairs as well, with each pair's two members able to serve — so read throughput scales with both the pair count and the mirroring, typically landing RAID 10 ahead of RAID 5/6 for mixed workloads on comparable hardware.

The price is capacity efficiency: half the raw space is mirrors, full stop — the same overhead as a two-way mirror, regardless of array size. On four drives, RAID 10 and a two-way mirror cost the same; RAID 5 gives more space. RAID 10's argument is never "more capacity" — it's "redundancy without the parity tax on writes and rebuilds."

Failure tolerance: placement, not counts

The accurate statement — and the one that replaces the common but wrong "RAID 10 survives exactly one drive" — is this: RAID 10 survives any set of failures in which no mirror pair loses both members. One failure anywhere: fine. Two failures in different pairs: fine. Three failures in three different pairs of a six-drive array: fine. Two failures in the same pair: the array is lost, because that pair's data now exists nowhere. So RAID 10 can out-tolerate RAID 6 in a lucky failure sequence and fall to a single unlucky pair before RAID 5 would think about dying — the difference is placement, and placement is random from the drives' point of view.

Operationally that means RAID 10's discipline is pair hygiene: replace a failed member immediately so no pair sits degraded, because a degraded pair is a one-failure-from-dead structure. It also means the level's real-world reliability depends on drive quality and correlated-failure risk (Section 10) as much as any level — the math is forgiving, the pairs aren't infinite.

Rebuilds: the fastest of the redundant levels

Rebuilding a failed RAID 10 member is a mirror resync: copy the surviving pair member to the replacement. No parity computation, and typically only that member's share of the data — so RAID 10 rebuilds are generally the quickest and least I/O-intensive of the redundant levels, and they carry the lowest rebuild-failure risk (there's nothing to recompute that a latent sector error could break). For environments where "time to full redundancy after a failure" is a first-class metric, that's a substantial advantage over both parity levels — and one of the core reasons RAID 10 remains the default recommendation for VM hosts and other uptime-sensitive systems.

The formulas, and their assumptions

The five standard formulas for equal-sized drives, with N = drive count and S = the smallest member's capacity. For mixed-size arrays, every level's usable capacity is governed by the smallest drive — an 8 TB + 4 TB mirror is a 4 TB volume — so entering the smaller size is the correct (if conservative-feeling) input:

Treat the output as a planning number. Real filesystem-available space will be somewhat lower (metadata, alignment, controller reservations — Section 01), and some implementations deviate from the conventional layouts these formulas describe. The calculator's job is to compare levels at a glance, not to replace a vendor's capacity planner for a specific system.

Decimal TB versus binary TiB — the unit trap

Drive labels use decimal units (1 TB = 10¹² bytes); operating systems frequently report binary units (1 TiB = 2⁴⁰ bytes ≈ 1.0995 × 10¹² bytes). The result: an 8 TB drive shows up as "7.28 TiB" in many OS file managers — nothing is missing, the ruler changed. The calculator converts between both systems and shows each result in your input unit plus the other, so "24 TB usable (21.99 TiB)" is one number, not a discrepancy. When comparing a vendor's spec to your OS's report, do the conversion first — it's the most common "my array lost capacity!" false alarm in storage.

Sequential vs random: where each level flexes

Large sequential I/O (video, backups, media) is where striping shows: RAID 0 and RAID 10 scale roughly with the number of drives participating, while parity levels read near single-drive speed because each stripe's data blocks are spread thin and the controller can't parallelize a single sequential read the same way. Random I/O (databases, VMs, transactions) distributes across members in every level — which is why even RAID 5 beats a lone drive for random reads — but the write path is where they diverge hardest, because random writes are exactly the case that triggers the full parity update cycle.

The practical shape, qualitatively: RAID 0 leads on both axes with no protection; RAID 10 is the redundant level that keeps RAID-0-like write parallelism; RAID 1 is single-drive-speed with redundancy; RAID 5/6 trade write IOPS for capacity efficiency. A level that's "slower" on one axis can still be the right one if that axis isn't what your workload lives on.

Parity overhead, and the latency question

The write penalty (Section 04) is I/O overhead: extra reads and writes per logical write. There's a second, quieter cost — latency — because a parity write can't complete until its extra operations do, and each added step adds queue time. Write-back cache masks this heavily: with a good cache (and ideally a battery/capacitor backup on hardware), acknowledged writes complete from cache and the parity work happens in the background, which is why the same RAID 5 array feels fast on a well-equipped controller and sluggish on a basic one. Latency-sensitive workloads should be evaluated on the implementation's cache behavior as much as on the level itself.

Degraded mode and rebuild impact on performance

A degraded parity array is a different beast from a healthy one: every read touching the failed member's blocks requires reconstruction (extra reads plus CPU for the parity math), so throughput drops and latency rises — most noticeably on the stripes that were using the lost drive. A rebuild makes it worse temporarily: the reconstruction reads plus the writes to the new drive saturate the array's bandwidth for hours, and any production I/O competes with it. RAID 1's degraded mode is milder (reads just come from the survivor — no math), and its resync is a simple copy; RAID 10's is in between. This is why "time to rebuild" is a performance characteristic, not just a recovery one — a rebuild is the most expensive I/O event the array will ever run, and it's scheduled by a drive failure, not by you.

Why no level "wins" — and what actually sets your numbers

Every real-world number is the product of the layout and the platform: drive type (a SATA HDD array and an NVMe array behave completely differently at every level), controller or CPU capability, cache size and policy, queue depth, stripe size relative to your I/O size, and the workload's read/write/sequential/random mix. Stripe size deserves a line of its own: too small and you multiply the number of drives touched per I/O (wasting the parallelism), too large and sequential efficiency suffers — the "right" value depends on your typical I/O size, which is why vendors publish tuned defaults per workload rather than one universal setting.

The takeaway for decision-making: compare levels by shape (this table), then expect your actual system to shift every entry. If a purchase decision hinges on specific numbers, benchmark the actual configuration — with your drives, your controller, your workload — because the level tells you the trade-off, and the hardware sets the magnitude.

Qualitative profiles — relative behavior, not measured figures. No benchmark numbers are quoted on purpose: the real values are set by your drives, controller, cache, and workload (see above).

The recovery sequence: detect → replace → rebuild → verify

The standard flow: monitoring detects a failed (or predictive-failure) member; the array degrades; a spare or hot spare takes the slot; the controller reconstructs the missing data from the surviving members (a copy for mirrors, parity math for 5/6) and writes it to the replacement; the rebuild completes and the array returns to full redundancy; a verification pass (resync check, scrub, or consistency scan) confirms the rebuilt data actually matches. Each step has its own failure mode — a failed drive that won't be removed, a spare that's also bad, a rebuild that hits an unrecoverable read — which is why "we have RAID" is a partial answer to "how do we recover?" and the sequence is the complete one.

Two supporting practices belong here. Hot spares shorten the detect-to-rebuild gap: the array starts rebuilding the moment a drive dies instead of waiting for a human and a stockroom. Scrubbing / consistency checks periodically read the entire array (parity levels verify the checksums, mirrors compare copies), surfacing latent sector errors while the array is healthy — which converts a potential mid-rebuild disaster into a routine drive replacement. Both are cheap insurance; both are skipped by enough "we have RAID" shops to make the difference visible in post-mortems.

Tolerance vs likelihood: what the table can't tell you

The column headers matter: "tolerates" is stated for a healthy array, and "after N failures" is the actual operating state. The gap between the two columns is where recoveries live or die. Four realities widen that gap in practice: correlated failures (a power spike, a firmware bug, a batch of same-vintage drives, or a backplane fault can take two members at once — which defeats RAID 5's single-parity budget outright); latent sector errors discovered during rebuild reads; controller and cabling faults, which no level tolerates because they're outside the drive-failure model; and operator errors — pulling the wrong drive, or worse, re-initializing the array out of desperation (see the warning below).