I have rebuilt more failed RAID arrays than I would like to admit, and every single one of those late nights taught me the same lesson: understanding RAID is not optional if you are responsible for data. It is one of those topics that seems simple on the surface — “it protects against disk failure” — until you actually have to calculate usable capacity, rebuild time, and failure probability for a real deployment. Let me walk through this properly, from the beginner concepts up through the enterprise-scale math.
What Is RAID?
RAID stands for Redundant Array of Independent Disks (originally “Inexpensive,” but that fell out of use). It is a method of combining multiple physical disks into a logical unit to achieve some combination of increased performance, increased capacity, and/or fault tolerance, depending on the RAID level chosen.
The fundamental trade-off in every RAID level is the same triangle: capacity efficiency, performance, and fault tolerance. You can optimize for two of these fairly well, but rarely all three at once.
RAID 0 — Striping
Data is split (striped) across all disks in the array with no redundancy at all.
- Fault tolerance: None — a single disk failure loses all data in the array
- Usable capacity: 100% of raw capacity (N disks x disk size)
- Performance: Excellent read/write throughput, since I/O is spread across all disks simultaneously
- Minimum disks: 2
Usable capacity = N x disk_size
Example: 4 x 2TB drives = 8TB usable, 8TB raw (no overhead)
Use case: Scratch space, temporary data, or workloads where performance matters more than data protection and data is fully replicated elsewhere.
RAID 1 — Mirroring
Data is duplicated identically across two (or more) disks.
- Fault tolerance: Can survive failure of all but one disk in the mirror set
- Usable capacity: 50% of raw capacity for a standard 2-disk mirror
- Performance: Good read performance (can read from either disk), write performance roughly equal to a single disk since both copies must be written
- Minimum disks: 2
Usable capacity = N/2 x disk_size (for a simple 2-way mirror)
Example: 2 x 2TB drives = 2TB usable, 4TB raw (50% overhead)
Use case: Boot volumes, small mission-critical volumes where simplicity and fast rebuild matter more than capacity efficiency.
RAID 5 — Striping with Distributed Parity
Data and parity information are striped across all disks, with parity distributed rather than concentrated on one disk.
- Fault tolerance: Survives exactly one disk failure
- Usable capacity: (N-1) x disk_size — one disk’s worth of capacity is consumed by parity
- Performance: Good read performance; write performance suffers from the “write penalty” (read-modify-write cycle needed to recalculate parity)
- Minimum disks: 3
Usable capacity = (N-1) x disk_size
Example: 5 x 2TB drives = (5-1) x 2TB = 8TB usable, 10TB raw (20% overhead)
RAID 5 Write Penalty: Every write requires reading the old data, reading the old parity, calculating new parity, then writing new data and new parity — commonly modeled as a 4x I/O penalty per write operation on the back-end disks, which is why RAID 5 is discouraged for write-heavy workloads.
RAID 6 — Striping with Dual Distributed Parity
Like RAID 5, but with two independent parity blocks distributed across the array.
- Fault tolerance: Survives two simultaneous disk failures
- Usable capacity: (N-2) x disk_size
- Performance: Similar to RAID 5 but with an even higher write penalty (typically modeled as 6x I/O per write, since two parity calculations are needed)
- Minimum disks: 4
Usable capacity = (N-2) x disk_size
Example: 8 x 4TB drives = (8-2) x 4TB = 24TB usable, 32TB raw (25% overhead)
Why RAID 6 matters with large drives: As drive capacities have grown into the 16TB–20TB+ range, RAID 5 rebuild times have grown long enough (often 24+ hours) that the probability of a second drive failure during rebuild has become a real, statistically meaningful risk. RAID 6’s ability to survive a second failure during that rebuild window is why most enterprise arrays now default to RAID 6 for large-capacity drives.
RAID 10 (1+0) — Mirrored Stripes
A combination of mirroring and striping — disks are mirrored in pairs, and those mirrored pairs are then striped together.
- Fault tolerance: Can survive multiple disk failures, as long as no mirrored pair loses both of its members
- Usable capacity: 50% of raw capacity
- Performance: Excellent — combines the read/write performance of striping with the redundancy of mirroring, no parity write penalty
- Minimum disks: 4 (must be even number)
Usable capacity = N/2 x disk_size
Example: 8 x 2TB drives = 8TB usable, 16TB raw (50% overhead)
Use case: High-performance databases and transaction logs where write performance and fault tolerance both matter more than raw capacity efficiency.
Comparison Table
| RAID Level | Min Disks | Usable Capacity | Fault Tolerance | Write Performance | Rebuild Time | Typical Use Case |
|---|---|---|---|---|---|---|
| RAID 0 | 2 | 100% | None | Excellent | N/A | Scratch/temp data |
| RAID 1 | 2 | 50% | 1 disk (per mirror) | Good | Fast | Boot volumes, small critical data |
| RAID 5 | 3 | (N-1)/N | 1 disk | Fair (write penalty) | Moderate–Slow | General purpose, read-heavy |
| RAID 6 | 4 | (N-2)/N | 2 disks | Fair–Poor (higher write penalty) | Slow | Large-capacity arrays, archival |
| RAID 10 | 4 | 50% | Multiple (per mirror pair) | Excellent | Fast | Databases, high-transaction workloads |
RAID Rebuild Time and Risk Calculation
This is the calculation that convinced most of the industry to move away from RAID 5 on large drives. Rebuild time depends on drive capacity, array controller throughput, and whether the array remains under production load during rebuild.
Approximate rebuild time = Drive capacity / Effective rebuild throughput
Example with a 12TB drive at ~150MB/s effective rebuild throughput
(throttled to allow production I/O to continue):
12,000,000 MB / 150 MB/s = 80,000 seconds ≈ 22.2 hours
During that 22-hour window in a RAID 5 array, the array has zero fault tolerance — any second disk failure means data loss. With modern annualized failure rates (AFR) for enterprise drives typically in the 0.5%–1.5% range, and multiple drives in an array all from the same batch (meaning correlated failure risk from manufacturing defects or workload stress), a 22-hour exposure window is a real, non-trivial risk at scale — which is exactly the scenario RAID 6 is designed to protect against.
Nested and Alternative RAID Levels
- RAID 50 (5+0): Multiple RAID 5 groups striped together — improves performance over a single large RAID 5 group while retaining single-disk-per-group fault tolerance.
- RAID 60 (6+0): Multiple RAID 6 groups striped together — similar logic, with dual-parity protection per group.
- Triple Parity / RAID-TP: Some vendors (e.g., NetApp’s RAID-TP, or ZFS’s RAID-Z3) offer three parity blocks for extremely large drive arrays where even two-disk fault tolerance is not enough headroom during long rebuilds.
RAID vs. Erasure Coding
Modern scale-out and object storage systems often replace traditional RAID with erasure coding, which generalizes the parity concept across many more nodes/disks:
Erasure coding notation: k+m
k = number of data fragments
m = number of parity/redundancy fragments
Can tolerate up to m simultaneous failures
Example: 10+4 erasure coding
Usable capacity = k / (k+m) = 10/14 ≈ 71.4% of raw capacity
Fault tolerance = up to 4 simultaneous fragment failures
Erasure coding is more flexible than fixed RAID levels and is common in object storage platforms (Dell EMC ECS, Ceph, Amazon S3 internally) where data is spread across far more than the handful of disks in a traditional RAID group.
Hardware RAID vs. Software RAID
| Aspect | Hardware RAID | Software RAID |
|---|---|---|
| Parity calculation | Dedicated RAID controller/ASIC | Host CPU |
| Performance impact on host | None | Some CPU overhead |
| Battery-backed cache | Common, protects against power loss during writes | Depends on implementation |
| Cost | Higher (dedicated controller hardware) | Lower (built into OS, e.g., Linux mdadm, ZFS) |
| Flexibility | Vendor-locked to controller | Portable, open implementations (mdadm, ZFS, Storage Spaces) |
Practical Example: Building a mdadm RAID 6 Array on Linux
mdadm --create /dev/md0 --level=6 --raid-devices=6 /dev/sd[b-g]
mkfs.xfs /dev/md0
mount /dev/md0 /data
# Check array status and rebuild progress
cat /proc/mdstat
mdadm --detail /dev/md0
A Decision Framework for Choosing a RAID Level
When I get asked “which RAID level should I use,” I walk through the same set of questions every time:
- How write-heavy is the workload? Transaction logs and OLTP databases favor RAID 10 because of the parity write penalty on RAID 5/6. Read-heavy archival or media workloads tolerate RAID 5/6 well.
- How large are the individual drives? Drives above roughly 4–8TB push strongly toward RAID 6 (or erasure coding) over RAID 5, purely because of rebuild-time risk.
- How much usable capacity can you afford to give up? RAID 10’s 50% overhead is a real cost at scale; RAID 6’s smaller overhead is more capacity-efficient but at a performance cost.
- What is your tolerance for a second failure during rebuild? Mission-critical systems where downtime is unacceptable should default to RAID 6 or RAID 10 rather than RAID 5.
- Is this workload latency-sensitive? RAID 10 has no parity calculation overhead at all, making it the best choice when consistent low latency matters more than capacity efficiency.
Calculating Failure Probability Across an Array
It is worth understanding, at least at a conceptual level, why redundancy matters more as arrays grow larger. If each individual drive has an independent annual failure probability of p, the probability that at least one drive in an N-drive array fails in a given year is approximately:
P(at least one failure) ≈ 1 - (1 - p)^N
Example: p = 1% annual failure rate, N = 24 drives
P(at least one failure) ≈ 1 - (0.99)^24 ≈ 1 - 0.786 ≈ 21.4%
A 21% chance that some drive in a 24-drive array fails in a given year is a meaningful number, and it is exactly why the rebuild-time exposure window discussed earlier matters so much — with that many drives, you should expect to go through a rebuild cycle periodically, not treat it as a rare edge case.
Common Mistakes
- Using RAID 5 with large (8TB+) drives in write-intensive environments, ignoring the rebuild-window risk.
- Confusing RAID with backup. RAID protects against disk failure; it does not protect against accidental deletion, ransomware, corruption, or site disasters. I have seen this misunderstanding lead to real data loss when people assumed RAID meant they did not need backups.
- Ignoring the write penalty of parity RAID levels when sizing for write-heavy database workloads, leading to unexpected performance problems after go-live.
- Mixing drive models/batches without considering correlated failure risk — drives from the same manufacturing batch, all installed and aged identically, can fail in clusters.
- Not replacing failed drives promptly. A degraded RAID array sitting in that state for weeks dramatically increases the risk of a second failure causing data loss.
FAQs
Q: Which RAID level is best? There is no universally “best” level — it depends on the workload. RAID 10 for performance-critical databases, RAID 6 for large-capacity general storage, RAID 1 for small critical volumes, RAID 0 only when redundancy is handled elsewhere.
Q: Does RAID protect against ransomware or accidental deletion? No. RAID only protects against physical disk failure. You still need snapshots, backups, and (ideally) immutable/air-gapped copies for logical corruption or malicious deletion scenarios.
Q: Why do enterprise arrays increasingly avoid RAID 5? Primarily due to rebuild time risk on large-capacity drives, as covered in the rebuild time calculation above — the exposure window during rebuild has grown to the point where a second failure is a realistic risk.
Q: Is RAID still relevant with all-flash and NVMe storage? Yes, though flash drives fail differently (wear-based rather than mechanical) and rebuild much faster than spinning disks, which reduces (but does not eliminate) the rebuild-window risk that drove the RAID 5-to-6 shift on HDDs.
Summary
RAID levels represent different points along the capacity/performance/fault-tolerance triangle, and choosing correctly requires understanding your workload’s actual read/write mix, capacity needs, and tolerance for rebuild-window risk. RAID 0 and RAID 1 are the simplest building blocks; RAID 5 and RAID 6 trade write performance for capacity efficiency via parity; RAID 10 gives you the best combination of performance and fault tolerance at the cost of capacity. And regardless of which level you choose, RAID has never been, and never will be, a substitute for proper backups.
References
- SNIA — RAID terminology and technical tutorials, snia.org
- Dell EMC — PowerEdge RAID Controller (PERC) documentation, dell.com/support
- NetApp — RAID-TP and RAID-DP technical documentation, docs.netapp.com
- Red Hat — Linux mdadm and Software RAID documentation, access.redhat.com/documentation
- IBM — Storage RAID configuration guides, ibm.com/docs
- Oracle — ZFS RAID-Z documentation, docs.oracle.com
