RAID 10 nests two RAID levels: mirroring for redundancy and striping for speed. Most implementations build it as RAID 1+0, meaning mirrored pairs are created first, then striped together.
It delivers strong read and write performance with no parity-calculation overhead, and rebuilds are comparatively simple mirror copies rather than parity recalculations, but usable capacity lands around 50% and it needs a minimum of four drives.
Fault tolerance here is conditional, not absolute. RAID 10 survives one failed disk per mirrored pair. Lose both disks in the same pair, though, and that data is gone, even though the rest of the array stays online. That distinction should shape your buy/use decision, not sit as a footnote.
Key Terms Defined
RAID 1+0 (striped mirrors): RAID 1 mirror arrays are built first, then combined into a RAID 0 stripe. This is what nearly everyone means by "RAID 10," and what most hardware controllers implement.
RAID 0+1 (mirrored stripes): The inverse construction. RAID 0 stripe arrays are built first, then mirrored as a whole. Same components, different assembly order, meaningfully different failure behavior.
Mirror pair: Two disks holding identical data. In RAID 1+0, the array is a collection of these pairs, striped together for throughput.
Complex RAID 10: A single, non-nested RAID level (Linux mdadm --level=10) that mimics RAID 10 behavior without literally building separate RAID 1 and RAID 0 layers underneath.
RAID 1+0 vs. RAID 0+1: Why the Build Order Matters
RAID 1+0 builds RAID 1 mirrors first, then stripes them together into a RAID 0 layer. Because each mirror is managed independently, multiple disk failures can be tolerated as long as the failed disks belong to different mirrors.
RAID 0+1 inverts that order: it stripes first, then mirrors the entire stripe set. The SUSE documentation notes this configuration has slightly weaker fault tolerance, because if disks fail concurrently on both sides of the mirror, the entire array's data is lost. It also carries a structural limitation: spare devices can't be assigned to the underlying RAID 0 legs, because a RAID 0 stripe can't tolerate losing even one device.
Before you assume a controller's failure behavior, confirm which topology it actually builds. A datasheet that says "RAID 10" doesn't guarantee you're getting RAID 1+0 underneath.
RAID 10 vs. RAID 6 vs. RAID 1: A Decision Table
| RAID 10 | RAID 6 | RAID 1 | |
|---|---|---|---|
| Usable capacity | ~50% (N ÷ replicas) | N-2 drives | 50%, no striping |
| Tolerated failures | One per mirror pair | Any two drives, array-wide | One of two disks |
| Rebuild mechanism | Mirror copy | Parity recalculation | Mirror copy |
| Best-fit workload | OLTP, virtualization | Bulk/archival capacity | Small, simple redundancy |
The capacity gap is concrete: eight 16 TB drives yield 64 TB usable in RAID 10 versus 96 TB in RAID 6, and the difference only grows as drive counts scale up.
The write-path difference is architectural, not a guaranteed speed multiple. RAID 10 writes each block to both mirror halves with no parity math, while RAID 6 computes and writes two parity blocks per stripe. A simplified Servnet UK model frames this as roughly a ×2 write penalty for RAID 10 versus ×6 for RAID 6, but real-world results shift with controller cache, stripe size, and workload block size. Treat that as a directional model, not a benchmark you can quote verbatim.
The decision rule: pay RAID 10's capacity premium for sustained small-block random writes and latency-sensitive transactional workloads, where rebuild speed and predictable I/O outweigh raw capacity. Reach for RAID 6, erasure coding, or replicated storage systems when capacity efficiency or very large drive counts dominate the requirement instead.
What Actually Happens When a Drive Fails
A RAID 10 rebuild copies data from the surviving mirror partner to the replacement disk. It does not recalculate parity across the array. That's why DiskInternals and Servnet UK both describe RAID 10 rebuilds as generally less taxing on the array than parity-RAID rebuilds. Actual duration still depends on drive speed, data volume, and controller throttling, so don't treat any vendor's "minutes to hours" estimate as a fixed number for your array.
The hard boundary: two failures inside the same mirror pair leave no surviving copy, so that pair's data is lost even though the rest of the array stays healthy. This is the one scenario RAID 10's redundancy model cannot absorb.
There's a difference between independent failure and correlated failure, and RAID 10's math only covers the first. Its "one disk per pair" tolerance assumes failures happen independently, but drives sharing a backplane, power supply, controller, or firmware batch can fail together. DiskInternals recommends deliberately distributing mirror pairs across separate backplanes or enclosures to reduce that risk. RAID 10 doesn't do this automatically; it's a design decision you have to make yourself.
Where the Capacity Cost Is Worth Paying, and Where It Isn't
RAID 10 earns its 50% capacity tax in a specific set of environments: OLTP and transactional databases (SQL Server, Oracle-class workloads) and dense virtualization hosts, where small-block random writes and fast rebuilds matter more than maximizing raw terabytes. This shows up in practice as mixed estates that run RAID 10 on flash for databases and VMs alongside RAID 6 on nearline HDD for bulk capacity and backups, letting each RAID level do the job it's actually good at.
The tax is a poor bargain for bulk or archival storage, large sequential-capacity tiers, or very large all-flash deployments, where paying for 2x the raw drives just to get fault tolerance becomes expensive. RAID 6, erasure-coded object storage, or software-defined replication typically deliver comparable resilience at a lower cost per usable terabyte at that scale.
One knob parity RAID doesn't have: complex software RAID 10 can use more than two replicas per data block, up to the number of devices in the array, trading even more capacity for extra redundancy. That's a niche option, useful when losing an entire mirror pair still can't be tolerated, but it's not a default setting most environments need.
Implementation Details That Change the Rules
Linux software RAID actually gives you three distinct choices, not one. You can build nested RAID 1+0 or RAID 0+1 device stacks manually, or use a single "complex" RAID 10 level via mdadm --level=10 or YaST, which isn't nested at all. The complex form allows even or odd device counts (nested 1+0 requires even), lets you configure two to N replicas, and offers a choice of near, far, or offset data layouts, each with different performance characteristics that don't apply to the nested forms.
LVM RAID 10 is created with lvcreate and repaired with lvconvert --repair, but that repair command depends on a spare physical volume already attached to the volume group, per Oracle's Linux LVM documentation. Skip that prep step, and a failed leg has nowhere to rebuild to when the failure actually happens.
Hardware controllers add their own rules that aren't universal RAID 10 properties. Broadcom's MegaRAID family, for example, supports spanned RAID 10 across 4 to 240 drives, with matched, even-numbered spans, and requires a single-span RAID 1 for 2 to 32 drives while shifting to multi-span configurations at 36 drives and up. Those thresholds are MegaRAID/firmware behavior, not something you can assume applies to a different vendor's controller. Always check the specific hardware documentation before you plan a build around a drive-count ceiling.
Frequently Asked Questions
Is RAID 10 a substitute for backup?
No. RAID protects against disk hardware failure only. It does nothing against ransomware, accidental deletion, logical corruption, or site disasters, so immutable, offsite backup remains mandatory regardless of RAID level.
Can I mix drive sizes or types within a RAID 10 mirror pair?
None of the vendor documentation reviewed here specifies a hard rule, but mismatched drives waste capacity, since the pair is capped at the smaller drive's size, and can introduce uneven latency. Matching drives within a pair is the safer practical baseline.
Does RAID 10 protect against a whole-enclosure, controller, or power failure?
Not by default. Its "one failure per pair" math assumes independent drive failures. Correlated failures from a shared backplane, controller, firmware bug, or power event can take out both members of a pair at once. Deliberately distributing mirror pairs across separate backplanes or enclosures is a mitigation you design in, not something RAID 10 does automatically.
How many drives can a RAID 10 array actually support?
It depends entirely on implementation. Nested Linux software RAID 1+0 needs an even number of devices, complex mdadm RAID 10 allows even or odd counts, and a given hardware controller family imposes its own span and drive-count ceilings. There's no single universal maximum across implementations.
Is SSD-based RAID 10 worth the added cost over HDD?
Vendor material reports lower latency, higher IOPS, and faster rebuilds on flash, but that's a vendor-reported comparison rather than an independent benchmark. Validate against your own workload and controller before committing budget, since pricing and performance vary by capacity, configuration, and support tier.