What is RAID? RAID storage levels 0, 1, 5, 6 and 10 explained

Short answer: RAID (redundant array of independent disks, originally “inexpensive” disks) combines several physical disks into one logical drive for more speed, protection against a failed disk, or both. Mirroring and parity (RAID 1, 5, 6 and 10) keep data available when a disk dies; striping alone (RAID 0) only adds speed. RAID is not a backup.

What does RAID stand for?

The term comes from a 1988 paper by David Patterson, Garth Gibson and Randy Katz at the University of California, Berkeley: “A Case for Redundant Arrays of Inexpensive Disks (RAID)”. The idea was that several cheap disks, arranged cleverly, could match or beat one large, expensive drive in speed and reliability. The storage industry later swapped “inexpensive” for “independent”, and both expansions are still in use. The paper defined numbered levels, and the numbers stuck: they describe layouts, not a ranking, so RAID 6 is not “better” than RAID 5 in every way.

The three building blocks: striping, mirroring, parity

• Striping splits data into chunks and spreads them across the disks, so a large read or write is served by all of them at once. It adds speed and no protection at all.
• Mirroring writes the same data to two or more disks. Any one copy is enough to read it, so a mirror survives losing all but one of its disks.
• Parity stores a calculated value from which a missing chunk can be rebuilt. It protects data for the space of one disk (RAID 5) or two (RAID 6) instead of a full copy.

Parity is plain XOR. With two data chunks A = 1011 and B = 0110, the parity is A XOR B = 1101. Lose the disk holding B, and A XOR parity = 1011 XOR 1101 = 0110 gives B back. The same works across any number of data disks, which is why one parity disk’s worth of space can protect a whole stripe.

RAID levels compared: 0, 1, 5, 6 and 10

The write column is the classic “write penalty” for small random writes. Parity levels have to read the old data and parity before writing the new ones, which is why RAID 5 and 6 feel slow under databases and virtual machines. Large sequential writes that fill a whole stripe skip the extra reads. The RAID calculator works out usable space and fault tolerance for any disk count, including RAID 50 and 60, in TB and TiB.

RAID 0

Fast and fragile: one failed disk takes the whole array with it, and the risk grows with every disk you add. Fine for scratch space, caches and data you can regenerate; never for anything you need to keep.

RAID 1

Two (or more) identical copies. Simple, quick to rebuild because a rebuild is a plain copy, and every disk holds the complete data, so either one can run the array alone. The usual choice for boot disks and small servers with two drives. You pay with half the raw space.

RAID 5

Parity spread over all disks, one disk’s worth of space lost. Good capacity efficiency, decent reads, slower small writes. Its weak point is the rebuild: while one disk is missing there is no redundancy left, and the rebuild has to read every other disk completely. That makes it a better fit for a few smaller or fast disks than for many large hard drives.

RAID 6

Two independent parity blocks per stripe, so any two disks may fail. It costs a second disk of space and more write work than RAID 5, and it is the usual answer for large hard drives and archives, because it still has redundancy left while a rebuild runs.

RAID 10

Mirrored pairs, striped together. Half the raw space, the best random write performance of the redundant levels, and short rebuilds that only copy one disk’s partner. It survives one failure in every pair, but not both disks of the same pair. The default choice for databases and virtual machine storage. Linux software RAID implements RAID 10 as its own level, which per the md(4) man page needs at least as many disks as copies of each block, not a multiple of them, so with two copies it also runs on two or three disks.

Levels 2, 3 and 4 exist but are rarely deployed today. RAID 50 and 60 stripe across several RAID 5 or RAID 6 groups for very large arrays, and JBOD (“just a bunch of disks”) joins disks end to end with no redundancy.

Hardware RAID vs software RAID

On modern servers, software RAID is no longer the poor cousin. CPUs calculate parity quickly, most NVMe drives connect straight to PCIe lanes rather than to a RAID controller, and ZFS and Btrfs add something a controller cannot: checksums that detect silent corruption and repair it from the good copy. The Proxmox VE project, for example, does not support mdadm, citing its missing integrity checks and its sensitivity to O_DIRECT writes, and recommends ZFS instead (see what Proxmox VE is).

RAID is not a backup

RAID keeps a server running when a disk fails. It copies every other kind of damage to all disks at once, instantly:

• A deleted file or a dropped database table is deleted on every mirror.
• Ransomware encrypts the array as happily as a single disk.
• A buggy update or a corrupted file system is consistent, redundant and broken.
• A failed controller, a fire, theft or a cancelled server takes all copies with it.

Backups live on another machine, ideally in another place, and you have restored one at least once to prove they work. Incremental vs differential backup explains the backup types and the 3-2-1 rule.

Rebuilds, large disks and read errors

When a disk fails, a redundant array keeps running in a degraded state. Put in a replacement and the array rebuilds it from the others: for a mirror that is a copy, for parity it means reading every remaining disk end to end. Three things follow from that.

• Rebuild time grows with disk size. As pure arithmetic, a 16 TB disk rebuilt at a sustained 200 MB/s takes 80,000 seconds, about 22 hours, and that is the best case for an idle array. Linux md throttles rebuilds between /proc/sys/dev/raid/speed_limit_min and speed_limit_max, by default 1,000 and 200,000 KiB/s per device according to md(4), and slows down when the array is busy.
• A read error during a rebuild hurts most when no redundancy is left. Drive datasheets give a rate of unrecoverable read errors, written as one error per so many bits read. A rebuild reads a lot of bits. In a degraded RAID 5, a sector that cannot be read on a surviving disk cannot be reconstructed: depending on the implementation the rebuild stops, or it carries on and marks those blocks as lost. RAID 6 and three-way mirrors still have a second source for that sector.
• Disks bought together tend to age together. A second failure during a long, heavy rebuild is a real risk, which is the practical argument for RAID 6 or RAID 10 on large disks.

Regular scrubs find bad sectors while the array still has redundancy to fix them. On mdadm, echo check > /sys/block/md0/md/sync_action (as root) reads the whole array and counts inconsistencies in mismatch_cnt; repair instead of check also corrects them. Debian and Ubuntu schedule periodic checks with their mdadm package. ZFS does the same with zpool scrub.

SSD and NVMe in RAID

• Mirrored SSDs wear evenly, which is a mixed blessing: both copies receive the same writes, so two identical drives can reach their endurance limit at about the same time. Watch the wear indicators (Percentage Used in smartctl -a /dev/nvme0) on every member, not just one.
• Parity adds writes. Each small write also rewrites parity, which costs SSD endurance as well as time; mirrors and RAID 10 are the common choice for flash.
• TRIM: md passes discards through on RAID 0, 1 and 10; for RAID 5 and 6 the kernel only does it when the raid456 module parameter devices_handle_discard_safely is set.
• NVMe means software RAID in most servers, because the drives sit directly on PCIe lanes. What is NVMe covers why that is rarely the bottleneck.

How to check a RAID array on Linux

For Linux software RAID, /proc/mdstat is the quick look. A healthy two-disk mirror shows [2/2] [UU]: two devices expected, two up.

Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 sdb2[1] sda2[0]
      1952854016 blocks super 1.2 [2/2] [UU]
      bitmap: 1/15 pages [4KB], 65536KB chunk

unused devices: <none>

An underscore marks a missing member, (F) a failed one, and a progress bar a rebuild in progress:

md0 : active raid1 sdb2[1](F) sda2[0]
      1952854016 blocks super 1.2 [2/1] [U_]

md0 : active raid1 sdb2[2] sda2[0]
      1952854016 blocks super 1.2 [2/1] [U_]
      [===>.................]  recovery = 17.4% (340080256/1952854016) finish=142.3min speed=188816K/sec

mdadm --detail gives the full picture: state, member roles and rebuild status.

/dev/md0:
           Version : 1.2
        Raid Level : raid1
        Array Size : 1952854016 (1862.39 GiB 1999.72 GB)
      Raid Devices : 2
     Total Devices : 2
             State : clean, degraded, recovering
    Active Devices : 1
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 1
    Rebuild Status : 17% complete

    Number   Major   Minor   RaidDevice State
       0       8        2        0      active sync   /dev/sda2
       2       8       18        1      spare rebuilding   /dev/sdb2

Replacing a failed member: take it out of the array before the disk is swapped, then partition the new disk and add it.

# before the swap
mdadm --manage /dev/md0 --fail /dev/sdb2 --remove /dev/sdb2

# after the new disk is in
sfdisk -d /dev/sda | sfdisk /dev/sdb          # copy the partition table from the good disk
mdadm --manage /dev/md0 --add /dev/sdb2       # the rebuild starts on its own
watch cat /proc/mdstat

Double-check the device names with lsblk -o NAME,SIZE,MODEL,SERIAL before the sfdisk line: copying a partition table onto the wrong disk destroys it. On GPT disks the copy also clones the disk and partition GUIDs, so give the new disk fresh ones (sgdisk -G /dev/sdb, from the gdisk package). If the server boots from the array, install the boot loader on the new disk as well. For other setups: zpool status for ZFS, btrfs device stats /mnt for Btrfs, and the vendor’s command-line tool for a hardware controller. smartctl -H checks each physical disk behind any of them.

RAID on a dedicated server

On a rented dedicated server the disks are yours, and so is the decision how to use them. Before you put data on one, find out:

• How many disks it has, of which type and size, and whether they match.
• Whether a hardware controller is involved, or the disks are passed straight to the OS.
• Which layout the delivered system uses, and whether you can choose another at install.
• Who notices a failed disk, and how quickly it is swapped.

Then check what you actually received: lsblk lists the disks, cat /proc/mdstat shows any software array. Our dedicated servers in Amsterdam list the disk type and size of every build in the table; if you need a different disk layout, ask for a custom quote before ordering. Whichever level you end up with, it buys uptime, not safety, so the backup still has to go somewhere else.

Frequently asked