RAID 0 vs 1 vs 5 vs 6 vs 10
Understand theoretical disk capacity, redundancy, and key tradeoffs before selecting an array layout.
RAID is about availability, not backup
RAID groups multiple disks into a logical storage system. Different levels exchange storage efficiency, write overhead, and disk-failure tolerance. RAID does not protect against accidental deletion, malicious encryption, application corruption, catastrophic events, or a damaged site. A separate recoverable backup is still necessary.
Common RAID levels
| Level | Minimum disks | Usable capacity for N equal disks | Failure tolerance |
|---|---|---|---|
| RAID 0 | 2 | N × drive size | None |
| RAID 1 | 2 | 1 × drive size for an N-way mirror | Up to N − 1 copies |
| RAID 5 | 3 | (N − 1) × drive size | 1 disk |
| RAID 6 | 4 | (N − 2) × drive size | 2 disks |
| RAID 10 | 4, even count | (N / 2) × drive size | Depends on which mirror pairs fail |
Capacity example: six 4 TB disks
Six marketed 4 TB disks provide 24 TB raw. RAID 5 offers about 20 TB theoretical usable capacity, RAID 6 about 16 TB, and RAID 10 about 12 TB. The operating system may display this using tebibytes (TiB), a binary unit. Since one TB is 1012 bytes and one TiB is 240 bytes, 16 TB is approximately 14.55 TiB before filesystem and controller overhead.
When would you choose each level?
RAID 1 is uncomplicated mirroring and common for boot volumes. RAID 5 maximizes usable capacity among parity layouts shown here but only tolerates one disk failure. RAID 6 sacrifices another disk of capacity for two-disk fault tolerance. RAID 10 often suits latency-sensitive applications but requires mirror pairs and has different fault-tolerance behavior based on which drives fail.
Other factors beyond the formula
Array rebuild times, disk size, workload, controller cache, drive firmware, monitoring, spare policies, scrubbing, and filesystem overhead all affect real deployments. A theoretical formula cannot tell you whether a storage configuration is suitable for a particular database, virtualization host, or backup repository.
When possible, test application performance and restore procedures before production use. Keep at least one protected copy of critical data outside the RAID array.