RAID (redundant array of independent disks) is a method of combining several physical drives into one logical volume by distributing data across them with striping, mirroring or parity, so that the array gains speed, survives drive failures, or both. In server storage, RAID is the standard way to keep a system running when a single disk dies.
The concept was formalized in 1988 by researchers at the University of California, Berkeley, who originally expanded the acronym with “inexpensive” disks. Each RAID level describes a different layout, and the choice of level sets the usable capacity, the number of tolerated failures and the cost of every write.
How RAID distributes data across disks
RAID levels are built from three techniques. Striping splits data into chunks, commonly 64 KB to 512 KB, and writes consecutive chunks to different disks so that several drives work in parallel. Mirroring writes identical copies of every block to two or more disks. Parity stores a computed value, typically an XOR of the data chunks in a stripe, from which any single missing chunk can be reconstructed.
When a member disk fails, the array enters a degraded state: it keeps serving data by reading mirrors or recomputing missing chunks from parity. After the failed disk is replaced, or a hot spare takes over automatically, a rebuild rewrites the missing data onto the new drive. During the rebuild, the array runs with reduced performance and, for most levels, without remaining redundancy.
Standard and nested RAID levels
Five layouts cover nearly all server deployments. In the table, N is the number of disks and S is the capacity of the smallest disk, because RAID uses only that amount on every member.
| Level | Technique | Minimum disks | Usable capacity | Failures tolerated |
|---|---|---|---|---|
| RAID 0 | Striping only | 2 | N × S | None |
| RAID 1 | Mirroring | 2 | S | N − 1 |
| RAID 5 | Striping with distributed single parity | 3 | (N − 1) × S | 1 |
| RAID 6 | Striping with dual parity | 4 | (N − 2) × S | 2 |
| RAID 10 | Striping across mirrored pairs | 4 | N × S / 2 | 1 guaranteed, up to one per pair |
Applied to six 4 TB drives, the formulas give clearly different results. The next table shows the usable space and efficiency for that same set of disks.
| Level | Usable capacity | Capacity efficiency | Disks that may fail |
|---|---|---|---|
| RAID 0 | 24 TB | 100% | 0 |
| RAID 5 | 20 TB | 83% | 1 |
| RAID 6 | 16 TB | 67% | 2 |
| RAID 10 | 12 TB | 50% | 1 to 3, depending on which disks |
RAID 2, 3 and 4 also exist in the original classification but are practically obsolete in servers. Nested levels such as RAID 50 and RAID 60 stripe across several RAID 5 or RAID 6 groups to shorten rebuilds in large arrays.
Performance and the RAID write penalty
Reads scale well on most levels because data can be fetched from several disks at once, but small random writes cost extra disk operations. This write penalty is the number of physical I/O operations one logical write requires: 2 for RAID 1 and RAID 10, 4 for RAID 5 (read data, read parity, write data, write parity) and 6 for RAID 6.
Effective IOPS can be estimated as raw IOPS divided by the read share plus the write share multiplied by the penalty. The table applies this to eight hard drives of about 150 IOPS each, giving 1,200 raw IOPS, under a workload of 70% reads and 30% writes.
| Level | Write penalty | Calculation | Effective IOPS |
|---|---|---|---|
| RAID 0 | 1 | 1,200 / (0.7 + 0.3 × 1) | About 1,200 |
| RAID 10 | 2 | 1,200 / (0.7 + 0.3 × 2) | About 923 |
| RAID 5 | 4 | 1,200 / (0.7 + 0.3 × 4) | About 632 |
| RAID 6 | 6 | 1,200 / (0.7 + 0.3 × 6) | About 480 |
These figures explain why databases and virtual machine hosts favor RAID 10, while archives and backup targets with mostly sequential or read-heavy access accept the penalty of RAID 6 in exchange for capacity. A battery-backed or flash-backed write cache on a hardware controller hides much of the penalty by acknowledging writes before they reach the disks.
Hardware, software and file system RAID
The same RAID levels can be implemented in different layers of the storage stack, and the layer determines portability, monitoring and data integrity features.
| Implementation | Where parity and layout are handled | Strength | Main caveat |
|---|---|---|---|
| Hardware RAID | Dedicated controller with its own processor | Protected write cache, OS-independent | Array tied to a controller family |
| Software RAID | Operating system, such as Linux mdadm | Portable, transparent, no extra hardware | Uses host CPU and needs write hole protection |
| Firmware RAID | Motherboard chipset with OS drivers | Bootable arrays at low cost | Weak tooling and portability |
| File system RAID | ZFS RAID-Z or Btrfs | Checksums detect and repair silent corruption | Requires that file system and its tuning |
Classic RAID protects against whole-disk failure, not against corrupted data on a disk that still responds. File systems such as ZFS combine redundancy with end-to-end checksums, so they can identify which copy is correct, a capability that conventional RAID 5 or RAID 1 does not provide on its own. Volume managers such as LVM can also create RAID layouts internally.
Rebuild risks and common mistakes
The most dangerous period for any array is the rebuild window. A rebuild must read every sector of the surviving disks, and its duration grows with drive size: copying a 16 TB drive at about 150 MB/s takes roughly 30 hours even with no competing load.
- Treating RAID as a backup: RAID does not protect against deletion, ransomware, controller faults or site loss, so separate backups remain mandatory.
- Using RAID 5 with large hard drives: a second failure or an unreadable sector during a long rebuild can lose the array; RAID 6 or RAID 10 is the safer choice for multi-terabyte disks.
- Ignoring the write hole: a power loss in the middle of a parity update can leave stripes inconsistent unless a protected cache, a journal or a copy-on-write file system is used.
- Disks from one batch: drives with identical age and workload tend to fail close together.
- No monitoring: a degraded array that nobody notices offers no protection, so alerts on array state and periodic scrubbing are essential.
In simple terms
RAID makes several disks act like one larger, safer or faster disk. Some layouts keep a full copy of everything on two disks, some spread pieces of each file across many disks for speed, and some store a clever summary that can rebuild a lost disk from the others.
The key idea is that one broken disk does not stop the server. It is still not a backup, because a mistake such as deleting a file is copied to every disk at once.
A practical example
A company’s file server stores project archives on eight 12 TB hard drives. The administrator compares RAID 5, which would offer 84 TB, with RAID 6, which offers 72 TB and survives two failed disks, and chooses RAID 6 because a rebuild of a 12 TB drive can take a full day or more.
Fourteen months later, one drive fails on a Friday evening. A hot spare starts rebuilding automatically, and during that rebuild a second drive reports unreadable sectors. Because RAID 6 still holds a second parity block for every stripe, the array reconstructs the affected data and finishes the rebuild in about 26 hours without data loss. Nightly backups to a separate system remain in place as the protection against deletion and ransomware.