What Is RAID? RAID 0, 1, 5, 6 and 10 Explained, With Real Tests (2026)

What is RAID? RAID stands for Redundant Array of Independent Disks. It means combining several hard drives or SSDs so that the operating system sees them as one single drive. Depending on the method, called the RAID level, that drive becomes faster, more fault tolerant, or both. RAID 1, for example, mirrors every disk onto a second one so the server keeps running when one of them dies. RAID 0, on the other hand, only spreads data across several disks and makes the system faster, but not safer.

That is the textbook answer. Because we did not want to just copy textbook sentences, on October 8, 2026 we built real RAID arrays with mdadm (version 4.3, kernel 6.8) on a Linux server, failed disks on purpose, deleted data and flipped bits. Three results up front:

1. Pulling a disk out of a RAID 1 went completely unnoticed: the checksum of a 200 MiB file was identical afterwards. Deleting a file, however, was instantly final on both disks. RAID protects against hardware, not against mistakes.

2. We quietly destroyed 8 MiB of data on one of the two mirror disks. The repair command found it and “fixed” it, by copying the corrupted copy over the good one. Afterwards both disks were identical again, and both were wrong.

3. The server this blog runs on has no RAID at all: /proc/mdstat is empty and there is exactly one virtual disk. That is normal for a VPS and not a mistake. The reason is further down.

What Is RAID? The Basic Idea in One Minute

A single hard drive has two problems: at some point it is too slow, and at some point it breaks. RAID solves both by having several disks work together. There are exactly three tools, and every RAID level is built from them:

The name comes from a 1988 paper by David Patterson, Garth Gibson and Randy Katz at the University of California, Berkeley. Back then the “I” stood for Inexpensive: instead of one expensive mainframe disk, many cheap PC disks were supposed to work together. Today most people say Independent. It means the same thing.

One point is key to understanding everything else: to the operating system and every program above it, a RAID is a perfectly normal drive. On Linux it is called something like /dev/md0, it carries a file system like ext4, and no application knows whether two, four or twelve disks sit underneath. That is exactly why RAID cannot replace backups, more on that shortly.

A clear walkthrough of the common levels from a NAS and homelab perspective (2022). The fundamentals have not changed since.

The RAID Levels at a Glance

Officially there are RAID 0 through RAID 6 plus a number of combinations. In practice you will almost only meet five today: RAID 0, 1, 5, 6 and 10. RAID 2, 3 and 4 are historical and rarely matter outside of exam questions.

RAID 0: Striping, Fast and Without a Net

RAID 0 spreads data block by block across all disks. With two disks, block 1 lands on disk A, block 2 on disk B, block 3 on A again, and so on. Both disks work in parallel when reading and writing, so for large files RAID 0 is roughly as many times faster as there are disks.

The catch: there is no redundancy whatsoever. Every file is scattered across all disks. If a single disk dies, nearly every file is missing a piece and the whole drive is lost. A two-disk RAID 0 is therefore twice as likely to fail as a single disk. Strictly speaking, the “R” in RAID 0 is a lie.

In our test, mdadm even refused to mark a disk in the RAID 0 as failed: “Cannot remove /dev/loop4 from /dev/md94, array will be failed.” The tool protects you from the click, but not from the hardware. When a disk really dies, it does not ask.

Good for: scratch space, video editing caches, build directories, anything you can regenerate at any time.

RAID 1: Mirroring, Simple and Robust

RAID 1 writes every block identically to two (or more) disks. If one fails, the system simply continues with the other. Only the capacity of one disk is usable, so half of what you bought goes to safety.

RAID 1 is the standard for rented dedicated servers: most providers ship their machines with two disks for exactly this reason. We also recommend it as the absolute minimum in our comparison VPS vs. dedicated server.

Good for: system disks, small servers, anything with two drives.

RAID 5: Parity Across Three or More Disks

RAID 5 needs at least three disks. Data is spread like RAID 0, and for each stripe a parity block is calculated and stored, rotating across the disks. At its core, parity is an XOR operation: if you know every block of a stripe except one, you can calculate the missing one.

That means any one disk may fail. One disk’s worth of capacity goes to parity, so with three disks two thirds are usable, with eight disks seven eighths. On paper that makes RAID 5 very attractive.

In practice RAID 5 has a bad reputation, and it has earned it. After one disk fails, the array has no redundancy at all until the rebuild is finished. For that, every single bit on all remaining disks has to be read without errors. With large hard drives that takes many hours, and that is exactly when the old disks are under the heaviest load. More on that in the section on rebuilds.

RAID 6: Double Parity

RAID 6 works like RAID 5 but stores two independent parity blocks per stripe. It needs at least four disks, and any two may fail at the same time. The price is two disks’ worth of capacity and a little more computation on writes. For large arrays with many hard drives, RAID 6 is the sensible choice today instead of RAID 5.

RAID 10: Mirror and Stripe

RAID 10 (said “one-zero”, not “ten”) combines both: disks are mirrored in pairs, and data is striped across the pairs. With four disks you get two mirror pairs with data spread across them. The result is speed close to RAID 0, fault tolerance like RAID 1, and very fast rebuilds, because only one disk has to be copied instead of recalculated from all the others.

The downside is capacity again: only half is usable. In exchange, RAID 10 is the favorite for databases and virtual machines, where lots of small random writes happen that RAID 5 and 6 slow down with their parity calculations.

One detail that is often explained wrong: RAID 10 survives at least one failed disk, at best even two, but only if they come from different mirror pairs. If both disks of the same pair die, the array is lost.

RAID Levels Compared: Capacity, Fault Tolerance, Use Cases

We created all five levels with mdadm, each from equally sized test drives (512 MiB each), and read off how much space was left. These values are measured, not calculated:

The small differences (1,020 instead of 1,024 MiB) are the metadata mdadm stores at the start of each disk. The formulas for real life:

• RAID 0: sum of all disks
• RAID 1: one disk
• RAID 5: (number − 1) × disk size
• RAID 6: (number − 2) × disk size
• RAID 10: half the sum

With disks of different sizes, the smallest one always counts. Mirror a 4 TB disk with an 8 TB disk and you get 4 TB; the remaining 4 TB sit unused.

What We Tested: RAID 1 Under Fire

For the tests we created four image files on our server and attached them as loop devices. That is the usual way to try RAID safely without sacrificing real disks. If you want to follow along:

# Create four test "disks" of 512 MiB each as files
for i in 0 1 2 3; do truncate -s 512M d$i.img; done
for i in 0 1 2 3; do losetup -f --show d$i.img; done
# Output e.g.: /dev/loop4 /dev/loop12 /dev/loop19 /dev/loop21

# Build a RAID 1 from two of them
mdadm --create /dev/md90 --level=1 --raid-devices=2 /dev/loop4 /dev/loop12
cat /proc/mdstat

Creating it took 0.04 seconds; afterwards mdadm synchronizes the two disks in the background. In /proc/mdstat it looks like this:

md90 : active raid1 loop12[1] loop4[0]
      523264 blocks super 1.2 [2/2] [UU]
      [=======>.............]  resync = 38.5% (201728/523264)

[2/2] [UU] is the most important line to remember: two of two disks active, both Up. If it says [2/1] [_U], one is missing.

Test 1: A Disk Fails

We created an ext4 file system, wrote a 200 MiB random file, noted its checksum and then declared one disk failed:

mdadm /dev/md90 --fail /dev/loop4
cat /proc/mdstat
# md90 : active raid1 loop12[1] loop4[0](F)
#       523264 blocks super 1.2 [2/1] [_U]

Then we dropped the kernel’s read cache and checked the file again. Result: identical checksum (ade88f31… before and after). For every application on the server, nothing had happened. That is exactly what RAID is built for.

And that is also the danger: a degraded RAID looks perfectly healthy from the outside. If nobody looks at /proc/mdstat, the server may run on a single disk for months, and the actual protection only exists on paper.

Test 2: A File Gets Deleted

On the same, now degraded array we deleted the file. It was gone. Not from one disk, but from the RAID, because to the RAID a deletion is a perfectly normal write that is dutifully applied to every mirror. The same goes for ransomware, a broken update, an accidental rm -rf or a faulty database migration script.

Test 3: Rebuild After a Disk Swap

Next we removed the “failed” disk, wiped it and added it back as a fresh disk:

mdadm /dev/md90 --remove /dev/loop4
wipefs -a /dev/loop4
mdadm /dev/md90 --add /dev/loop4
mdadm --wait /dev/md90

The rebuild of 511 MiB took 2.2 seconds. That sounds impressive, but it is a test setup: the loop devices sit on an SSD and it was only half a gigabyte. With real hard drives the math is different, and that is the part that really matters.

Test 4: Silent Data Corruption, and Why repair Makes It Worse

Disks do not always fail loudly. Sometimes they simply return wrong data without any error. This is called silent data corruption or bit rot. To see how RAID handles it, we bypassed mdadm and wrote 4 MiB of random data directly onto one of the two mirror disks, then started the built-in consistency check:

echo check > /sys/block/md90/md/sync_action
mdadm --wait /dev/md90
cat /sys/block/md90/md/mismatch_cnt
# 8192

8,192 sectors of 512 bytes are exactly the 4 MiB we had destroyed. So the check found the damage. The logical next step is repair; afterwards a new check reported mismatch_cnt=0. All green.

But with RAID 1, green only means the two disks are the same again. Not that they are correct again. So we repeated the test, this time without a file system in between, with a known 500 MiB data pattern written directly to the array, and deliberately damaged the first disk:

The RAID served the broken data to applications without any warning, on every read. And repair did not restore the good copy; it copied the broken one onto the good disk. After that, both mirrors were consistently wrong.

This is not a bug in mdadm but a limit of the method: a classic RAID 1 has two copies and no way of knowing which one is right. There is no per-block checksum, so when they disagree it simply picks the first. The kernel’s md documentation says essentially the same thing: repair makes the copies consistent, not correct. Protection against silent errors only comes from file systems with their own checksums, such as ZFS or Btrfs. They notice on every read which copy matches the stored checksum and repair from the right one.

In practice silent corruption is rare, because modern disks check themselves internally. But the test shows why a green RAID status light says less than it seems to.

Test 5: RAID 5 Loses a Disk

On a three-disk RAID 5 we wrote a 300 MiB file, marked one disk as failed and read the file again: identical checksum, the missing blocks were recalculated live from parity. Status afterwards: [3/2] [_UU], “clean, degraded”.

mdadm would not let us simulate the second failure: “Cannot remove … array will be failed.” That is honest too: from here on there is nothing left to save. With real hardware, mdadm does not get to decide whether a second disk dies.

The Rebuild: The Most Dangerous Hours in a RAID’s Life

In our test the rebuild took seconds. On real hardware it is the most critical moment, for three reasons.

First, duration. A rebuild has to write the entire new disk, regardless of how much is actually used (with mdadm; ZFS is smarter here and only copies used blocks). A large hard drive writes roughly 200 to 250 MB/s sequentially. For a 16 TB disk that means:

16,000,000 MB ÷ 200 MB/s = 80,000 seconds ≈ 22 hours, in the very best case.

If the server is under load at the same time, the kernel throttles the rebuild (defaults live in /proc/sys/dev/raid/speed_limit_min and speed_limit_max), and one day easily turns into two or three.

Second, stress. With RAID 5 and 6, the rebuild has to read every single remaining disk completely. The disks are usually the same age, from the same batch, with the same power-on hours. When one dies, the others are statistically not far behind, and now they get the heaviest load of their lives.

Third, read errors. Drive makers often specify an error rate for consumer disks of one unreadable sector per 10¹⁴ bits read, which is about 12.5 TB. That is a worst-case figure; real disks are usually much better. But a rebuild of a RAID 5 made of four 16 TB disks reads 48 TB. Even if the real-world rate is ten times better, there is a residual risk of hitting an unreadable sector mid-rebuild, and with RAID 5 there is no second parity left to step in. That is exactly why many admins advise against RAID 5 with large hard drives and recommend RAID 6 or RAID 10 instead.

What follows from this:

• With large HDDs: RAID 6 or RAID 10, not RAID 5.
• Mix disks from different batches or with staggered purchase dates where possible.
• Plan a hot spare so the rebuild starts immediately, not when someone notices the failure.
• Have a current backup before the rebuild. Always.

RAID Is Not a Backup

This is the most important sentence in this article, and it is in every forum. People still mix it up, because RAID and backups both have to do with “data safety”. But they solve two completely different problems:

In short: RAID provides availability, backups provide recoverability. RAID keeps your server from going down at 3 a.m. because a disk died. A backup keeps your data from being gone because something else went wrong. You need both, and if you have to pick one, pick the backup.

What a backup worth the name looks like is described, with real restore tests, in our article on the 3-2-1 backup strategy. There, RAID is explicitly not allowed to count as the “second medium”.

Hardware RAID, Software RAID or ZFS?

RAID can be implemented in three ways, and the choice is clearer today than ten years ago.

Hardware RAID

A dedicated controller (an expansion card or a chip on the mainboard) does the work. The operating system only sees a finished drive. Good controllers have a cache with a battery or capacitor that saves pending writes during a power failure.

The big drawback: the array is tied to the controller. If the card dies, you usually need the same model, or at least the same vendor, to read the disks again. The controller also hides the state of the individual disks from the operating system; SMART data is often only reachable through vendor tools.

By the way, the so-called fake RAID on consumer mainboards is usually not hardware RAID at all, but driver software with a BIOS menu, combining the downsides of both worlds.

Software RAID (mdadm on Linux)

Linux has shipped a mature software RAID with mdadm for more than twenty years. The CPU does the math, which no longer matters with modern processors. The advantage: the disks can be plugged into any other Linux machine and reassembled there with mdadm --assemble --scan. No controller, no vendor lock-in.

Almost all rented dedicated servers ship with software RAID or can be set up with it during installation. For most Linux servers this is the right choice.

ZFS and Btrfs

ZFS (and, with caveats, Btrfs) combines file system and volume manager. They offer their own RAID variants: mirror, RAID-Z1 (similar to RAID 5), RAID-Z2 (RAID 6) and RAID-Z3. The decisive difference is the per-block checksum. That solves exactly the problem from our test 4: when copies disagree, they know which one is right. On top come snapshots, compression and rebuilds that only copy used data.

The price is more complexity and higher RAM requirements with ZFS. And ZFS wants to see the disks directly, not through a hardware RAID controller. Proxmox points this out explicitly in its documentation; we quoted it in our comparison Proxmox vs. ESXi.

A visual explanation that also covers ZFS RAID-Z1 and Z2, aimed at people building a NAS or home server (2025).

Does My Server Even Need RAID?

That depends on who owns the hardware.

On a VPS or in the cloud: no, at least not one you build yourself. A VPS gets a virtual disk that lives on redundant storage at the provider, typically RAID 10, Ceph or something similar. Mirroring two virtual disks inside the same VPS achieves nothing, because both end up on the same physical hardware. Our own server is exactly such a case: lsblk shows a single disk sda, and /proc/mdstat reports unused devices: <none>. The redundancy exists, just one layer down and outside our control. That makes the off-site backup all the more important.

On a dedicated server: yes, absolutely. Here the hardware is yours for the rental period, and so are its failures. Without RAID, a dead disk means: server offline, ticket to the provider, disk swap, reinstall the operating system, restore the backup. With RAID 1 it means: ticket, disk swap, mdadm --add, done, and the server was running the whole time.

On a NAS at home or in the office: yes, usually RAID 1 with two disks, RAID 6 or RAID-Z2 from four or five large disks upward. Plus an off-site backup, because the NAS sits in the same room as everything else and shares its fate in a fire or burglary.

On a desktop PC: rarely worth it. A proper backup does more there than a mirror.

Monitoring RAID: The Part Everyone Forgets

A RAID whose failure nobody notices protects you exactly once. After that it runs on one disk, and the next failure is the last. These three things should be set up on every server with software RAID:

1. Email on failure. mdadm has a built-in monitor mode. On Debian and Ubuntu it already runs as a service after installation; it just needs a recipient address:

# /etc/mdadm/mdadm.conf
MAILADDR admin@example.com

# Send a test mail for every array
mdadm --monitor --scan --test --oneshot

For the mail to arrive, the server needs a working mail setup (for example msmtp or a Postfix relay). Actually run the test, otherwise you do not know whether the alert gets through.

2. Regular consistency checks. Debian and Ubuntu ship a monthly check that runs exactly the check from our test 4. On our Ubuntu 24.04 it runs as the systemd timer mdcheck_start.timer (next run according to systemctl list-timers: November 1, 03:52); older releases use checkarray via cron. The value in mismatch_cnt should be 0 afterwards. If it is not, something is wrong with a disk.

3. SMART data of each disk. RAID only reports once a disk has already failed. smartmontools often detects beforehand that it is dying (for example from rising reallocated sectors):

apt install smartmontools
smartctl -H /dev/sda   # quick verdict
smartctl -a /dev/sda   # all values

Configure the smartd service to send an email as well. How to run checks like these automatically on a schedule is shown in our guide on how to create a cron job.

Replacing a Disk: Step by Step With mdadm

When the email arrives, the process for a RAID 1 looks like this:

1. Check the status: cat /proc/mdstat and mdadm --detail /dev/md0. Which disk is marked (F) or missing?
2. Note the serial number: smartctl -i /dev/sdb. So the data center technician pulls the right disk. Pulling the wrong one is the classic way to turn a degraded RAID 1 into a dead one.
3. Remove it from the array: mdadm /dev/md0 --fail /dev/sdb1 --remove /dev/sdb1 (for each partition or array on the disk).
4. Have the disk replaced (on a dedicated server, via a ticket with your provider).
5. Copy the partition table: with GPT, for example sgdisk -R /dev/sdb /dev/sda followed by sgdisk -G /dev/sdb for new GUIDs. Watch the direction: the target comes first.
6. Add it back: mdadm /dev/md0 --add /dev/sdb1. The rebuild starts automatically.
7. Write the bootloader to the new disk, otherwise the server will not boot if the other disk fails later. Depending on the system, grub-install /dev/sdb.
8. Wait and watch: watch cat /proc/mdstat until it says [UU] again.

Before step 3, check your latest backup. A rebuild is the moment you are most likely to need it.

Frequently Asked Questions

What is RAID in simple terms?

RAID is a method of combining several hard drives into one drive. Depending on the variant, that drive becomes faster (spreading data), more fault tolerant (mirroring data or calculating parity), or both.

What does RAID stand for?

Redundant Array of Independent Disks. Originally the I stood for Inexpensive.

Which RAID level is best?

There is no best one, only a fitting one. With two disks, RAID 1 is the default choice. For databases and VMs with four or more disks, RAID 10. For large amounts of data on many HDDs, RAID 6 or RAID-Z2. RAID 0 only for data you can regenerate at any time.

Is RAID a backup?

No. RAID protects against a disk failure, not against deletion, ransomware, software bugs, fire or theft. In our test a deleted file was instantly gone on every mirror. You also need a backup, ideally following the 3-2-1 rule.

What is the difference between RAID 1 and RAID 0?

RAID 1 mirrors: the same data on two disks, one may fail, half the capacity is usable. RAID 0 stripes: data alternates across two disks, twice as fast and twice as large, but if one disk fails, everything is gone.

How many disks do I need for RAID 5?

At least three. Usable capacity is all disks minus one. With large hard drives (roughly 8 TB and up), RAID 6 with at least four disks is the safer choice because rebuilds take very long.

What happens when a disk fails in RAID 1?

Nothing you would notice without monitoring. The server keeps reading and writing with the remaining disk. In our test a file’s checksum was identical before and after the failure. You still need to replace the disk quickly, because until then there is no redundancy left.

Can I use SSDs in RAID?

Yes, without problems. SSDs avoid some HDD issues (rebuilds are much faster), but add a new one: two identical SSDs with identical write load can wear out at a similar pace. With mdadm, TRIM should be enabled; current kernels pass it through for RAID 1 and RAID 10.

Hardware RAID or software RAID?

For Linux servers today, usually software RAID with mdadm or ZFS. It is hardware independent, well documented and the CPU load is negligible. Hardware RAID mainly makes sense when you need controllers with battery-backed cache, or when an operating system lacks a usable software RAID.

Does a VPS need RAID?

No. Redundancy lives with the provider at the host level. Mirroring two virtual disks inside the same VPS protects against nothing, because they sit on the same hardware. What a VPS needs instead is an off-site backup.

How long does a RAID rebuild take?

With mdadm the new disk has to be written completely. For an HDD at 200 MB/s that works out to about 1.4 hours per terabyte, so at least 22 hours for a 16 TB disk, and considerably more under load. SSDs and RAID 10 are much faster. In our test setup a rebuild of 511 MiB took 2.2 seconds.

Conclusion: What Is RAID, and What Isn’t It?

RAID is one of the oldest and most solid techniques in running servers: several disks act as one, and the failure of a single one stops nothing. In our test RAID 1 delivered exactly that: one disk gone and not a single bit lost.

But RAID only answers one question: what happens when a disk dies? For every other question it looks away. Deleted files vanish on every mirror, encrypted data is dutifully mirrored along, and when a disk silently returns wrong data, a classic RAID 1 cannot even tell which copy is right, and may well break the good one.

Our recommendation for 2026:

• VPS: no RAID of your own, but an off-site backup.
• Dedicated server: at least software RAID 1, with an email alert you have actually tested.
• Many large disks: RAID 6, RAID 10 or ZFS instead of RAID 5.
• Always: RAID and backup, never RAID instead of backup.

If you are deciding whether your own server with RAID is worth it at all, our comparison VPS vs. dedicated server has the numbers.