RAID 0 vs 1 vs 5 vs 10: one comparison table, then choose by workload

RAID 0 vs 1 vs 5 vs 10 is really a question of how each level stores redundancy. RAID 0 cuts data into chunks and writes them across all drives in turn, with no redundancy at all. RAID 1 keeps identical copies on two drives. RAID 5 stores a parity block alongside each row of data, so the contents of any single failed drive can be recalculated. RAID 10 mirrors drives in pairs and then stripes across the pairs. Everything else follows from that choice: the minimum number of drives, the usable capacity, how many extra disk I/Os each write costs, whether the array keeps running after a failure, and how much data a rebuild has to read.

RAID 0 vs 1 vs 5 vs 10 comparison table

N is the number of drives and C is the capacity of one drive:

	RAID 0	RAID 1	RAID 5	RAID 10
How it works	Striping: data split into chunks, written across drives in turn	Mirroring: two drives hold the same data	Striping with distributed parity	Mirror pairs, striped together
Minimum drives	2	2	3	4, even number
Usable capacity	N × C	C (half, with two drives)	(N − 1) × C	N / 2 × C
Random read	About N drives	About 2 drives	About N drives	About N drives
Random write (write penalty)	About N drives (1)	About 1 drive (2)	About N / 4 drives (4)	About N / 2 drives (2)
Large sequential write	About N drives	About 1 drive	About N − 1 drives	About N / 2 drives
Drive failures tolerated	0	1	1	At least 1, up to N / 2 (one per mirror pair)
After one drive fails	All data on the volume is lost	Reads and writes continue, without redundancy	Runs degraded; reading data from the failed drive means reading every other drive and recalculating	Only that mirror pair has lost a copy
Data read during a rebuild	Cannot be rebuilt	The surviving drive	All N − 1 remaining drives	The one mirror partner
Rebuild effort	—	Low: a straight drive copy	High: calculated stripe by stripe, slow and heavy on production I/O	Low: a straight drive copy
Typical use	Scratch data, caches that can be regenerated	Boot drives, small workloads	Read-heavy, capacity-first storage	Databases, virtualization

The row that matters most is random write. The number in brackets is the write penalty: how many disk I/Os it takes to complete one write from the application.

• RAID 0: 1. The data is written once.
• RAID 1 and RAID 10: 2. The same data goes to both drives of a mirror.
• RAID 5: 4. Updating a single data block means reading the old data and the old parity, calculating new parity, then writing the new data and the new parity: two reads plus two writes.

For random reads the four levels are close, since all of them can use nearly every drive. What separates them is random writes, behavior after a failure, and rebuilds.

Four 8 TB drives, four ways

Four drives is the smallest number that lets you build all four levels (RAID 1 as two pairs), so it makes the clearest comparison. Assume each 7,200 RPM hard drive delivers about 150 random IOPS and 200 MB/s of sequential writes. The figures below are theoretical estimates:

Layout	Usable capacity	Shown in the OS as about	Random read	Random write	Sequential write	Failures tolerated
RAID 0	32 TB	29.10 TiB	About 600 IOPS	About 600 IOPS	About 800 MB/s	0
RAID 5	24 TB	21.83 TiB	About 600 IOPS	About 150 IOPS	About 600 MB/s	1
RAID 10	16 TB	14.55 TiB	About 600 IOPS	About 300 IOPS	About 400 MB/s	1, or 2 if they fail in different mirror pairs
Two RAID 1 pairs	Two separate 8 TB volumes	7.28 TiB each	About 300 IOPS per volume	About 150 IOPS per volume	About 200 MB/s per volume	1 per pair

How to read it:

1. RAID 5 gives 8 TB more than RAID 10 but only half the random write performance. A controller with a battery- or flash-backed write-back cache absorbs bursts of writes, so real results look better than this estimate; once sustained writes exceed what the cache can hold, the ratio comes back.
2. Two RAID 1 pairs have the same capacity as RAID 10, but as two independent volumes, each with half the performance of RAID 10. That works when the workload splits cleanly by directory, such as the OS on one pair and data on the other. Otherwise RAID 10 is the better fit.
3. RAID 0 has the best numbers, and its risk grows with every drive. Any single failure loses all 32 TB. If each drive has, say, a 2% chance of failing within a year, a four-drive RAID 0 has about 1 − 0.98⁴ ≈ 7.8% chance of losing data in that year, nearly four times the single-drive risk.
4. With only two drives, it is one or the other. RAID 0 gives 16 TB, about twice the speed and no fault tolerance; RAID 1 gives 8 TB, single-drive write speed and survives one failure. Unless the data can be regenerated at any time, choose RAID 1.

Switch to SSDs and per-drive random IOPS rise by two or three orders of magnitude. For most workloads the bottleneck moves from performance to capacity, and the RAID 5 write penalty matters much less. The differences in degraded operation and rebuilds remain.

After a drive fails: fault tolerance and rebuilds

What usually decides whether a RAID level works for you is not everyday performance but the hours or days after a drive fails. Again with four 8 TB drives:

Level	Production after one failure	Data read to rebuild	What loses data before the rebuild finishes
RAID 0	The whole volume is gone	—	Data is already lost; restore from backup
RAID 1	Mostly normal; reads can only use the surviving drive	8 TB	The surviving drive failing, or unreadable sectors on it
RAID 5	Noticeably slower; data from the failed drive is rebuilt on the fly from the other 3	24 TB	Any of the other 3 drives failing; an unreadable sector on any of them means that stripe’s missing block cannot be recovered
RAID 10	Only the affected mirror pair is impacted	8 TB	Only a problem on the failed drive’s mirror partner

On an idle server, rebuild time mostly depends on how long it takes to write the new drive end to end, and the levels are not far apart. Under production load the difference shows. A RAID 1 or RAID 10 rebuild involves only two drives. A RAID 5 rebuild has to read every remaining drive for every stripe, so it competes with production for the I/O of the entire array, and the controller throttles the rebuild to protect production, which stretches it out further. For all that time, the array has no redundancy at all.

So the argument that “RAID 5 survives any one failure while RAID 10’s second failure depends on which drive it is, therefore RAID 5 is safer” does not hold. Both guarantee only one failure, and after it happens RAID 5 has a longer window of exposure and more drives that can end it.

Start with the number of drives you have

The number of drives often rules out half the options before you start:

Drives	Possible levels	Common choice
1	No redundancy	Store only data you can recreate, and back it up separately
2	RAID 0, RAID 1	RAID 1; RAID 0 only for scratch data
3	RAID 0, RAID 5, or RAID 1 plus a hot spare	RAID 5 for capacity; RAID 1 plus a spare for write-heavy work or when safety after a failure matters most
4	RAID 0, RAID 5, RAID 10	RAID 10 for write-heavy work, RAID 5 for read-heavy work that needs capacity
6 to 8	As above, or split into two groups	Two drives in RAID 1 for the OS, the rest in RAID 10 or RAID 5 for data
More than 8 large hard drives	As above	RAID 5 rebuild risk gets high; use RAID 10 or RAID 6

The last row goes beyond the four levels compared here, but it is worth remembering: the larger the drives and the more of them there are, the more data a RAID 5 rebuild must read and the longer it takes. Arrays of large hard drives generally no longer use RAID 5.

Then choose by workload: databases, virtualization, backups

Databases: RAID 10

Database writes are small random writes. InnoDB uses 16 KB data pages by default, and the transaction log is flushed to disk constantly, so write latency matters a great deal. On RAID 5 every small write costs four I/Os, and latency is high and uneven; when the array is degraded, slower queries often show up directly as application timeouts.

A typical eight-bay database server: two 480 GB SSDs in RAID 1 for the OS, and six 1.92 TB SSDs in RAID 10 for the data directory, giving 5.76 TB usable. Read-only replicas and reporting databases, which read far more than they write, can use RAID 5 for extra capacity. Some teams run RAID 0 on replicas that can be rebuilt from the primary at any time, accepting that a drive failure means several hours of resyncing a full copy of the data.

Virtualization hosts: RAID 10, or RAID 5 on a few SSDs

A host running dozens of virtual machines turns each VM’s sequential I/O into random I/O at the disk level, and when one drive degrades the array, every VM slows down together. Local storage should therefore start from RAID 10: for example, two drives in RAID 1 for the hypervisor and eight SSDs in RAID 10 for virtual disks. For small all-flash setups with three to five drives and light writes, RAID 5 for extra capacity is also common.

VMware ESXi adds a hard constraint: redundancy for a single host’s local storage has to come from a RAID controller, because ESXi has no software RAID of its own. Distributed storage across hosts, such as vSAN, is a separate matter.

Backup servers: capacity first, RAID 5 at minimum

Backups are large sequential writes, which is exactly where RAID 5 avoids its write penalty: a full-stripe write calculates parity directly without reading old data. RAID 10’s random write advantage, paid for with half the capacity, is wasted here. Four 8 TB drives in RAID 5 give 24 TB usable; at eight or more drives, or with larger drives, move to RAID 6. Never use RAID 0 on a backup server, since it often holds the last copy of the data. And the backup server itself should not be the only copy: keep important data in a second location as well.

Other common workloads

• Websites, file shares, download mirrors: read-heavy; RAID 1 with few drives, RAID 5 when you need capacity.
• Build caches, transcoding scratch space, CDN cache nodes: the data can be regenerated, so RAID 0 or a single drive is fine. Capacity and speed matter more than redundancy.
• Boot drives: two drives in RAID 1, separate from the data drives, so reinstalling the OS and changing the data array’s level never affect each other.

Changing the RAID level on a rented server

On rented dedicated servers the RAID level is usually set before handover. The customer sees one virtual disk, and reinstalling the OS does not change the array. If the customer later wants a different level, say RAID 10 instead of RAID 5, a reinstall will not do it: the array has to be deleted and recreated, and everything on the drives is lost. A smooth process has three steps. The customer backs up their data elsewhere. An engineer opens the VNC console that runs over the BMC in IPMI remote management, enters the RAID controller’s setup utility and recreates the virtual disk at the new level, with no trip to the data center to plug in a monitor. The customer then reinstalls the OS from an image in the customer portal and restores their data.

In the Toplink DCIM customer portal, risky actions such as reinstalling and rescue mode only run after the customer enters a one-time password from their phone, and reinstall progress appears in the task queue, where the job can also be cancelled. Stating in the plan description that changing the RAID level requires a backup first prevents a lot of disputes later.