Parity-based RAID levels handle the heavy lifting in most medium-to-large storage arrays. They give you redundancy without the 50% capacity cost of mirroring, which is why they’re the default for file servers, backup targets, and virtualization hosts where every terabyte counts.
This is Part 2 of a two-part series. Part 1 covered the foundations – RAID 0, RAID 1, RAID 10, and RAID 01 – including striping, mirroring, hardware vs. software RAID, and why RAID isn’t a backup. Start there if you haven’t read it.
If you’re coming from Part 1, you already know two of RAID’s three building blocks: striping, which splits data across drives for throughput, and mirroring, which copies data identically for redundancy. This article covers the third: parity.
Parity answers a different question. How do you get redundancy without dedicating half your raw capacity to copies? Instead of keeping a full duplicate of every drive, parity RAID computes a compact checksum from your data blocks and stores that alongside the data. One or two drives’ worth of capacity can protect the entire array. The trade-off is write complexity and rebuild exposure – both of which matter more than most people expect when they first deploy this kind of array.
How parity protects your data
Parity is a mathematical relationship between the data blocks stored on your drives. When a drive fails, that relationship lets the controller reconstruct the missing data from whatever survived. When we explain parity to junior engineers, the lightbulb usually comes once they see the XOR operation in action.
Single parity: XOR (RAID 5)
RAID 5 uses XOR (exclusive OR) to compute parity. For every stripe – the smallest unit of data distributed across the disks – the controller XORs the data blocks on all data drives and writes the result as the parity block. If any one drive fails, you recover its data by XORing the surviving blocks, including parity, back together. It’s elegant, and it works, but it only protects against a single failure per stripe.
Double parity: P+Q (RAID 6)
RAID 6 computes two independent parity values per stripe, called P and Q. P is standard XOR parity, identical to RAID 5. Q uses a Galois Field calculation that’s mathematically independent of P. Because P and Q don’t depend on each other, the controller can solve a system of two equations to reconstruct any two missing drives. Even if both failed drives held parity blocks, the reconstruction succeeds.
Why parity rotates across drives
RAID 4 stored all parity on a single dedicated drive, and that’s what created the write bottleneck. RAID 5 and RAID 6 fix this by rotating parity blocks across every drive in the array on a stripe-by-stripe basis. Every drive holds both data and parity. The write load spreads evenly, and the single-drive bottleneck disappears.
The write penalty: Why parity RAID is slower on writes
This is where parity RAID gets tricky, and it’s the part we’ve watched catch people off guard most often. There’s a write penalty with every parity-based array, and it’s the main reason parity RAID isn’t always the right answer.
The read-modify-write cycle
Almost every write to a parity RAID array triggers a read-modify-write (RMW) cycle. When you update a single data block – and this is what trips people up – the controller has to do all of the following before that write is considered complete:
- Read the old data block
- Read the current parity block for that stripe
- Compute new parity by XORing old data, new data, and old parity
- Write both the new data block and the updated parity block
Four I/O operations for every logical write. RAID 6, which maintains two parity blocks, needs six.
Where it hurts
The penalty hits hardest on workloads with high rates of small, random writes – exactly the pattern OLTP databases and active VM datastores produce. Each transaction generates scattered writes, each triggering a full read-modify-write cycle. The first time you watch a RAID 5 array buckle under a write-heavy database load, you understand why people pay for RAID 10’s capacity overhead. RAID 10’s write penalty is roughly 2x instead of 4x or 6x.
NVMe and controller cache change the equation
On HDD-based arrays from the 2010s, the write penalty was painful because each of those 4 or 6 I/O operations involved a mechanical seek. On modern NVMe arrays, sub-100-microsecond latency makes the penalty far less noticeable in absolute terms. It’s still there, but the baseline is so fast the net result is often acceptable. Hardware RAID controllers with battery-backed write cache help further by absorbing write bursts and coalescing small writes into full-stripe writes.
RAID 5: Striping with distributed parity
RAID 5 stripes data across all drives and distributes a single XOR parity block per stripe. The parity role rotates with every stripe, so no single drive becomes a bottleneck. Your OS sees one logical volume with usable capacity equal to n-1 drives, where n is the total drive count.
You need at least 3 drives. With 3, two hold data and one holds parity in a rotating fashion. That’s the smallest array where one drive can fail and you still have enough blocks to reconstruct everything.
When a drive fails, and eventually one will, the array enters degraded mode and keeps running. Reads continue normally. The controller reconstructs missing data on the fly from the surviving blocks. When you insert a replacement, the controller rebuilds by reading every other drive and recomputing. During this rebuild, the array’s degraded and under heavy I/O load. That’s the riskiest period in a RAID 5 array’s lifecycle.
I’ve seen RAID 5 work well on the right hardware and self-destructing on old good SAS 7200 drives. On all-flash or NVMe arrays, rebuild times are measured in hours, not days. The 4x write penalty’s real but tolerable for read-heavy or mixed workloads. You sacrifice one drive’s worth of capacity for parity, which is hard to beat on efficiency. A 3-drive array gives you 66% usable capacity; an 8-drive array gives you 87.5%. For general-purpose file servers and mid-tier databases, that trade-off often makes sense.
The problems start when you scale up with spinning disks. On a 6-drive array with 4 TB HDDs, rebuilding requires reading roughly 20 TB of data. With a 10^14 unrecoverable read error rate (the spec on many enterprise drives from that era) the probability of hitting an unrecoverable error during rebuild is around 16%. That climbs above 30% with 8 TB drives. We’ve learned this the hard way, and theese numbers are why RAID 5’s reputation took a hit on large HDD arrays.
Short version: RAID 5 on SSDs or NVMe in arrays of 3 to 6 drives is a solid, efficient choice. On large HDD arrays, it’s a gamble the math doesn’t support (avoid it like hell).
RAID 6: Striping with double parity
RAID 6 takes what RAID 5 does and doubles the safety net. A second independent parity block gets computed per stripe, which means any two drives can fail at the same time and the array won’t blink. Both get fully reconstructed from the survivors. Even if both failed drives held parity blocks, the math works out.
You’ll need at least 4 drives – two for data, two for parity. In practice, RAID 6 arrays typically start at 6 or more, where the capacity overhead of two parity drives becomes economically justified. Usable capacity follows n-2/n. On an 8-drive array, that’s 75%. On a 12-drive array, it’s 83%.
RAID 6’s standout advantage is fault tolerance. Surviving two simultaneous failures matters when rebuild times stretch into days and the odds of a second failure during that window aren’t zero. If you’re running an HDD array with more than 6 drives, RAID 6 should be your minimum safe configuration.
The cost is real. The 6 I/O write penalty vs. RAID 5’s 4 makes write-heavy workloads noticeably slower. And with two drives dedicated to parity, small arrays lose a disproportionate amount of capacity. A 4-disk RAID 6 array gives you only 50% usable space.
We’ve deployed RAID 6 on backup targets and archive tiers where write performance doesn’t matter much but resilience does. It’s the right call for NAS appliances using high-capacity drives, for any environment where a second failure during rebuild would be catastrophic, and for backup repositories where you’re optimizing for capacity and safety over raw IOPS.
RAID 50 (5+0): Striped RAID 5 groups
RAID 50, also written as RAID 5+0, is a nested RAID configuration. It combines the distributed parity of RAID 5 with the performance-boosting data striping of RAID 0. Think of it as striping across multiple underlying RAID 5 groups. This hybrid approach aims for both improved performance and enhanced fault tolerance compared to a single large RAID 5 array.
To create a RAID 50 setup, you need at least 6 drives (two RAID 5 arrays, each with at least 3 disks, then striped together). This structure helps improve write performance and speeds up rebuilds compared to a massive RAID 5.
The key benefit over a flat RAID 5 array with the same number of drives is failure isolation and faster rebuilds. When a drive fails in RAID 50, the rebuild is confined to the RAID 5 subgroup containing the failed drive. For example, if the array has two subgroups of 4 drives each, a rebuild reads only 4 drives rather than all 8, completing in roughly half the time and at lower I/O impact on the rest of the array. Each subgroup can survive one drive failure independently, so RAID 50 can survive multiple simultaneous failures, provided each failure is in a different subgroup.
Because data is striped across multiple independent RAID 5 groups, write throughput scales with the number of subgroups. A RAID 50 array built from two 4-drive RAID 5 groups can deliver roughly twice the write IOPS of a single 4-drive RAID 5 group while still maintaining the 4x write penalty per stripe within each subgroup. For workloads that need high sequential throughput with parity protection, RAID 50 is significantly faster than a flat RAID 5 array with the same drive count.
Good fits: primary VM storage on all-flash arrays, high-throughput file servers for video and media production, and workloads that need higher raw IOPS than a single RAID 5 group can deliver without accepting RAID 10’s 50% capacity overhead.
RAID 60 (6+0): Striped RAID 6 groups
RAID 60 combines RAID 6’s dual-parity protection with RAID 0 striping. You need at least 8 drives – two RAID 6 groups of 4, striped together. Data stripes across the groups while each group provides its own dual parity.
The main difference from RAID 50 is failure domain size. In RAID 50, a single failure within a subgroup puts that subgroup at immediate risk – a second failure there kills the array. In RAID 60, each subgroup absorbs two failures before data is at risk. A RAID 60 array with two 4-drive RAID 6 groups can survive up to 4 total drive failures, as long as they’re distributed across subgroups.
Once you’re past 12 or so drives, the probability of overlapping failures during rebuild goes up. RAID 60’s double-parity subgroups ensure that a second failure during rebuild – the most dangerous window – doesn’t immediately threaten the array.
RAID 60 is expensive. You need more drives, more parity overhead, and enterprise-grade controllers. Writes are slower than RAID 50 because of the dual parity calculations. We’ve seen it deployed primarily in backup repositories running Veeam, Commvault, or Zerto, in large archive systems where rebuild risk on high-capacity HDDs must be minimized, and in deployments where the recovery SLA can’t tolerate data loss from a second failure during rebuild.
Is RAID 5 dead?
I still hear this claim every few months. It started in the late 2000s when drive capacities crossed 1 TB and rebuild times stretched past 24 hours. The underlying fear was unrecoverable read errors (URE).
The URE problem
Every drive has what’s called an unrecoverable read error rate – a URE spec. For many enterprise drives, that rate is 1 in 10^14 bits read, meaning one uncorrectable error per roughly 12.5 TB of data read.
During a RAID 5 rebuild, the controller reads every block from every surviving drive. On a 6-drive array with 4 TB drives, that’s about 20 TB of data. With a 10^14 URE rate, the probability of hitting an unrecoverable error during rebuild is roughly 16%. Scale to 8 TB drives and it climbs above 30%. Those numbers scared a lot of storage admins in 2000s, and for good reason.
What’s changed
Three things have improved RAID 5’s safety profile since then.
Modern enterprise HDDs now commonly specify URE rates of 1 in 10^15 or better – ten times the 10^14 spec that caused the original concern. NVMe SSDs have dramatically lower URE rates than spinning disks, and their rebuild times are measured in minutes rather than days, which shrinks the exposure window. Modern RAID controllers, ZFS, and dRAID implementations handle URE recovery more gracefully than legacy firmware, often retrying at the sector level instead of aborting the rebuild.
The verdict
RAID 5 isn’t dead, but its safety depends entirely on your media and array size. On all-flash and NVMe arrays, it’s still practical and efficient. On HDD arrays with more than 6 drives or drives larger than about 4 TB, RAID 6 or RAIDZ2 is the safer choice. The risk isn’t theoretical – it’s statistical, and the numbers don’t favor RAID 5 on large spinning-disk arrays.
Rebuild times: the real risk variable
Rebuild time’s the single most important factor when you’re choosing a parity RAID level. During rebuild, the array’s degraded, under elevated I/O load, and vulnerable to data loss if a second drive fails. Faster rebuild means shorter exposure. This is the number we look at first when sizing an array.
The table below shows approximate rebuild times for a single failed drive in a 6-drive RAID 6 array under moderate concurrent I/O load. Actual times vary based on controller, workload, and configuration – treat these as ranges, not guarantees.
| Media type | Drive size | Read speed, approx. | Approx. rebuild time |
|---|---|---|---|
| Modern enterprise HDD, 7200 RPM | 8 TB | ~180 MB/s | 15-24 hours |
| Modern enterprise HDD, 7200 RPM, helium CMR | 20 TB | ~250 MB/s | 45-72 hours |
| Modern enterprise SATA SSD | 3.84 TB | ~550 MB/s | 4-6 hours |
| PCIe Gen 5 NVMe | 3.84 TB | ~10 GB/s | 10-30 minutes |
These estimates assume moderate concurrent I/O during rebuild on a dedicated hardware RAID controller. Under heavy load, rebuilds take longer.
Declustered RAID implementations like OpenZFS dRAID and IBM Storage Scale cut rebuild times further by distributing rebuild I/O across every drive in the pool instead of concentrating it on a single spare. In a 6-drive dRAID pool, a 20 TB drive that might take over 60 hours to rebuild traditionally can resilver in under 15 hours because all 5 surviving drives contribute simultaneously.
Parity vs. mirroring: the real decision
The most common RAID decision isn’t between RAID 5 and RAID 6. It’s between parity-based RAID and RAID 10. Honestly, choosing between RAID 6 and RAID 10 for mixed workloads is a judgment call we’ve gotten wrong before – the “right” answer depends on your write ratio, capacity budget, and how much downtime you can tolerate during rebuild.
RAID 10 is what you want when write performance and recovery speed are what you care about most. It’s got a 2x write penalty instead of 4x or 6x, and it rebuilds from a single mirror rather than reading the entire array. That makes RAID 10 the safest option for OLTP databases, active VM datastores, and anything with heavy random write patterns. The downside is that you’re stuck at 50% usable capacity no matter how many drives you add.
RAID 5 works for read-dominated or mixed workloads on all-flash arrays where capacity efficiency matters and the write penalty is acceptable. RAID 6 is the safer default when arrays are large enough or drives slow enough that rebuilds take many hours. For HDD arrays with 6 or more drives, RAID 6 should be your baseline. On all-flash arrays, RAID 5 stays viable because fast rebuilds shrink the exposure window.
Storage efficiency comparison
I always start with this table when someone asks me to recommend a RAID level. It compares all four parity levels on the metrics that matter. Write penalty is physical I/O operations per logical write.
| RAID Level | Minimum Drives | Recommended Drives | Write penalty | Storage Efficiency Formula | Example (8 drives) | Best use | Notes |
|---|---|---|---|---|---|---|---|
| RAID 5 | 3 | 5-7 | 4 I/Os | (n−1)/n×100% | 87.5% (7/8) | All-flash, small arrays | Loses 1 drive capacity for parity. |
| RAID 6 | 4 | 6-10 | 6 I/Os | (n−2)/n×100% | 75% (6/8) | Large HDD arrays, NAS | Loses 2 drives capacity for parity. |
| RAID 50 | 6 | 8-12 | 4 I/Os per group/span | (n−k)/n×100% | 75% (e.g., 2x RAID 5 of 4 drives: (8-2)/8) | VM storage, Media | Loses 1 drive per RAID 5 group. |
| RAID 60 | 8 | 12-16 | 6 I/Os per group/span | (n−2k)/n×100% | 50% (e.g., 2x RAID 6 of 4 drives: (8-4)/8) | Backup and archive | Loses 2 drives per RAID 6 group. |
(n = total number of drives, k = number of underlying RAID 5 or RAID 6 arrays)
Usable capacity formula: n minus the number of parity drives, divided by n. For RAID 50, k represents the number of underlying RAID 5 groups. For RAID 60, it’s RAID 6 groups. More redundancy means less usable capacity. The question is whether the extra safety justifies the cost.
Which parity RAID fits your workload?
Picking the right parity level comes down to three variables: how long your rebuilds take, what your write ratio looks like, and how large your failure domains are. Capacity math alone won’t answer it. If you don’t know your write ratio, check your storage array’s performance counters or your hypervisor’s I/O stats first. Then use these as starting points:
- Small all-flash or NVMe array, 3-6 drives, mixed or read-heavy workload – RAID 5. Efficient capacity, fast rebuilds, manageable write penalty on flash.
- Large HDD array, 6+ drives, or any drive above ~4 TB – RAID 6. Double parity protects against second-failure risk during long rebuild windows.
- High-IOPS all-flash pools needing throughput and parity protection – RAID 50. Multiple RAID 5 groups give both write throughput and faster per-group rebuilds.
- Backup repositories, object-storage front ends, large archival systems with 12+ drives – RAID 60. Maximum resilience per subgroup.
- Mixed HDD/flash with strict compliance or SLA requiring zero data loss during any rebuild – RAID 60 or ZFS RAIDZ2/dRAID. Don’t rely on RAID 5 or RAID 50 on large spinning-disk arrays.
- Array expected to grow beyond 16-20 drives – Consider erasure coding with MinIO or Ceph, or dRAID. Traditional RAID levels don’t scale efficiently past a certain point.
FAQ
What’s the minimum number of drives for RAID 5?
Three. Two contribute data blocks and one contributes parity per stripe, rotating. In practice, 4 or more drives are more common for a better capacity-to-overhead ratio.
Can RAID 6 survive two simultaneous drive failures?
Yes. That’s its defining feature. It computes two independent parity values, P and Q, per stripe. Any two drives fail, and the controller reconstructs both from the survivors. A third simultaneous failure destroys the array.
Is RAID 5 safe on SSDs?
Yes. SSDs have much lower URE rates than spinning disks, and rebuild times are minutes to hours instead of days. The remaining concerns are controller cache behavior and SSD write endurance, not rebuild risk.
What’s the write penalty for RAID 5 and RAID 6?
RAID 5 requires 4 physical I/O operations per logical write: read old data, read old parity, write new data, write new parity. RAID 6 requires 6 because it maintains two independent parity blocks. Hardware controller write cache and full-stripe write optimizations partially mitigate both.
How do RAID 50 and RAID 60 handle multiple drive failures?
Both survive multiple simultaneous failures, provided each failure is in a different subgroup. RAID 50 with two subgroups handles one failure per subgroup, 2 total. RAID 60 with two subgroups handles two per subgroup, 4 total. Multiple failures in the same subgroup remain fatal.
When should I choose RAID 6 over RAID 10?
When capacity efficiency matters more than write performance, and your workload is read-heavy or mixed. A 12-drive RAID 6 array gives you roughly 83% usable capacity vs. RAID 10’s 50%. The trade-off is RAID 6’s higher write penalty and longer rebuild.
Can I add drives to an existing RAID 5 or RAID 6 array?
It depends on your controller. Most modern hardware RAID controllers and software implementations (Linux mdadm, ZFS 2.3+) support online expansion – adding a drive and redistributing data and parity across the enlarged array. The process is called reshaping and can take many hours on large arrays. Verify controller support before planning.
Does RAID 6 protect against silent data corruption?
No. Like RAID 5, it detects and recovers from complete drive failures, but it can’t detect a drive that silently returns corrupted data – bit rot. For that, you need ZFS with per-block checksums or a storage system with end-to-end data integrity verification.
Making the call
When we’re sizing a new array and the conversation turns to parity RAID, the first question isn’t “RAID 5 or RAID 6?” – it’s “how long will this thing take to rebuild?” On a 6-drive NVMe array, RAID 5 is the efficient choice. Rebuilds finish in hours. The write penalty is tolerable for most mixed workloads. Got 6 or more HDDs? RAID 6 is the safer baseline. The second parity buys you real protection during the long rebuild windows spinning disks create.
RAID 50 gives you speed and parity when you need both. RAID 60 is for environments where losing data during any rebuild is unacceptable. Match the level to your rebuild time, your write ratio, and your failure-domain size. If you’re still on the fence, start with RAID 5 for small all-flash arrays and RAID 6 for everything else on spinning disks. You can always migrate up as the array grows – just make sure your controller supports it.
