RAID 0, 1, 5, 10: which level to choose for a server
For the system volume and most production workloads use RAID 1 on two disks. For a busy database or a hypervisor use RAID 10 on four or more drives. For bulk file storage, where capacity wins, use RAID 5 or RAID 6. RAID 0 has no place in production: it protects nothing and doubles your chance of losing the data.
- RAID 1 is a mirror: usable capacity equals one disk, the array survives the loss of one drive out of two.
- RAID 10 stripes mirrored pairs: 50% usable capacity, the best random write, fast rebuild by copying.
- RAID 5 uses parity: N−1 disks are usable, but every random write costs four operations and a rebuild runs for hours.
- RAID 6 survives two simultaneous disk failures and makes sense on arrays of six drives and up.
- No level replaces backups: a deleted file or ransomware hits every disk in the array at once.
What RAID solves and what it does not
RAID joins several physical drives into one logical volume. The level describes how the data is laid out: copying (mirror), splitting into stripes, or computing a checksum (parity).
Redundant levels cover exactly one scenario: a drive that dies suddenly, or one whose reallocated sector count starts growing fast. Logical damage is invisible to the array. A bad migration, an rm -rf in the wrong directory and ransomware all land on every disk at the same moment, which is why the array and server backups solve different problems and you need both.
RAID 0: speed with no safety net
Data is cut into stripes and written to all disks in parallel. Sequential throughput and IOPS scale almost linearly with the number of drives, and usable capacity is the sum of them. There is no redundancy at all: a two-disk array dies roughly twice as often as a single disk, a four-disk one four times as often.
The level is justified only where the data comes back in minutes without your involvement: a transcoded video cache, a CI build directory, a read replica that is re-seeded from the primary.
RAID 1: a mirror on two disks
Every block is written to both drives. Usable capacity equals one disk, that is half of the raw capacity. Reads can be served from both halves, writes run at the speed of the slower drive.
This is the default for the boot volume and for servers whose data fits on a single drive. The Dedicated Start and Dedicated Pro plans on ZevsHost dedicated servers are built exactly this way: 2×500 GB SSD or 2×1 TB NVMe in RAID 1.
RAID 5 and RAID 6: parity instead of a copy
RAID 5 keeps one parity block per stripe and spreads parity across all disks. Out of N drives, N−1 are usable: six 1 TB disks give you 5 TB. Reads are fast, writes pay a penalty, because changing one block turns into two reads and two writes.
RAID 6 keeps two parity blocks, survives two consecutive disk failures, leaves N−2 drives usable and pays six operations per random write.
RAID 10: mirrors inside a stripe
Disks are grouped into mirrored pairs and the pairs are striped together. Usable capacity is 50% of raw, the minimum is four drives. On random writes RAID 10 beats RAID 5 by a factor of 4–6, because a block simply lands on both disks of a pair with no parity to recompute.
The rebuild is cheaper as well: the system copies the surviving half of one pair instead of reconstructing data from the whole array. The Dedicated Enterprise US configuration with 4×1 TB NVMe ships in RAID 10 precisely for databases and hypervisors.
Level comparison
| Level | Min disks | Usable capacity | Survives | Write penalty | Typical workload |
|---|---|---|---|---|---|
| RAID 0 | 2 | 100% | 0 disks | none | cache, scratch data |
| RAID 1 | 2 | 50% | 1 disk | none | system volume, web server |
| RAID 5 | 3 | (N−1)/N | 1 disk | 4 operations | archive, file storage |
| RAID 6 | 4 | (N−2)/N | 2 disks | 6 operations | wide HDD array |
| RAID 10 | 4 | 50% | 1 disk per pair | none | databases, virtualization |
Creating and checking an array
A software array takes two commands to build. The choice of implementation, controller or mdadm, is covered in hardware RAID or mdadm; here is only the minimum needed to see the level and the state.
# Debian/Ubuntu
apt-get install -y mdadm
# RHEL, AlmaLinux, Rocky
dnf install -y mdadm
# mirror built from two partitions
mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/nvme0n1p2 /dev/nvme1n1p2
# RAID 10 built from four disks
mdadm --create /dev/md1 --level=10 --raid-devices=4 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1
# current state of every array
cat /proc/mdstat
mdadm --detail /dev/md0 2>&1 | grep -E 'Raid Level|State|Failed|Active'
An array in the degraded state keeps working and gives no visible sign: the site loads, the database answers, load looks normal. If the second disk in a RAID 1 or RAID 5 dies at that moment, the data is gone and there is nothing left to rebuild from. Set up the check right after you create the array: cat /proc/mdstat must show every device as U inside the brackets, for example [UU], and mdadm --detail must print State : clean together with Failed Devices : 0. An underscore instead of U means a dropped drive and calls for disk replacement the same day.
Key takeaways
- System volume and a standard web server: RAID 1 on two disks.
- Database, hypervisor, heavy random writes: RAID 10 on four drives or more.
- Archive on large hard drives: RAID 6; RAID 5 only on narrow arrays of up to five disks.
- RAID 0 only for data whose loss does not create an incident.
- Every level still needs separate backups and monitoring of the array state.