RAID controllers used to be obviously worth it. Parity calculation was expensive, CPUs were slow, and offloading it mattered.

That has not been true for years, and the calculation has mostly inverted. Our mdadm guide covers software RAID; this covers the comparison.

Why hardware RAID lost its advantage

Parity is cheap now. A modern CPU computes RAID 5 or 6 parity at many gigabytes per second, on cores that are otherwise idle. The offload that justified the card no longer offloads anything you notice.

cat /proc/mdstat | head -3
dmesg | grep -i 'raid6:'
# raid6: avx2x4   gen() 15234 MB/s

The kernel benchmarks its parity routines at boot and prints the result. That number is typically far above what your disks can absorb.

Portability is the real difference. A software RAID array assembles on any Linux machine:

sudo mdadm --assemble --scan
cat /proc/mdstat

A hardware array frequently needs the same controller model to read, because the on-disk metadata is proprietary. Controller dies, and you are sourcing an identical card, possibly with matching firmware, before you can read your own data.

That is a real failure mode, and it is worse for being unexpected: people buy hardware RAID for reliability and acquire a single point of failure that is harder to replace than a disk.

What hardware RAID still buys

One thing, and it is genuine.

A battery-backed or flash-backed write cache.

The controller acknowledges a write as soon as it is in the controller’s cache, before it reaches the disks. Power fails, the battery keeps the cache alive, and the writes complete on the next boot.

For a write-heavy workload with many small synchronous writes, a database doing fsync() constantly, that is a large latency improvement that software RAID cannot replicate safely.

# check the battery, because a dead one silently disables the cache
sudo megacli -AdpBbuCmd -aALL
sudo storcli /c0/bbu show

A dead BBU turns the cache write-through, which means a quiet and dramatic performance drop. Monitoring it is not optional, and it is exactly the kind of thing nobody checks until someone asks why the database got slow.

The other advantages are minor: hot-swap handling is sometimes smoother, and a hardware array boots before the OS, which simplifies booting from it.

The write hole

Worth understanding because it is the thing parity RAID gets wrong.

A RAID 5 write updates a data block and the parity block. Power fails between the two, and the stripe is inconsistent: the parity no longer matches the data, and nothing knows. Later, when a disk fails and the array rebuilds from parity, it reconstructs wrong data and reports success.

Three answers:

Hardware: the battery-backed cache completes the write.

mdadm: a write-intent journal.

sudo mdadm --create /dev/md0 --level=5 --raid-devices=4 \
  /dev/sd[bcde] --write-journal=/dev/nvme0n1p1

ZFS: the problem does not exist, because copy-on-write never updates a stripe in place. Our Btrfs versus ZFS guide covers this, and notes that Btrfs’s RAID 5 and 6 still have the write hole, which is why its own documentation advises against them.

What neither detects

The gap that matters most, and it is not about disk failure.

mdadm and hardware RAID both trust the disks. If a disk returns wrong data without reporting an error, silent corruption, neither notices. RAID 1 has two copies and no way to know which is right; RAID 5 has parity it only consults when a disk is missing.

# mdadm can check consistency, but cannot say which side is correct
sudo echo check > /sys/block/md0/md/sync_action
cat /sys/block/md0/md/mismatch_cnt

A non-zero mismatch count tells you the array is inconsistent and not which copy to believe.

ZFS and Btrfs checksum every block, so they detect corruption and, with redundancy, repair it from a known-good copy. That is a categorically stronger guarantee and the main reason to prefer them for data you care about.

Fakeraid

The motherboard option, and the answer is no.

Onboard “RAID” on consumer boards is usually a firmware option ROM plus a driver doing the work in software. You get:

• Proprietary metadata, so the array is tied to that chipset
• Software performance, because it is software
• Worse Linux support than mdadm

The worst of both. Set the controller to AHCI and use mdadm.

# identify what you actually have
lspci | grep -i raid
sudo dmraid -r

dmraid finding something means fakeraid. Real hardware RAID presents a single logical disk and the individual drives are invisible to the OS.

Choosing

	Hardware	mdadm	ZFS
Parity speed	Fine	Fine	Fine
Write cache with BBU	Yes	No	SLOG, partially
Portable between machines	No	Yes	Yes
Detects silent corruption	No	No	Yes
Repairs corruption	No	No	Yes
Controller is a failure point	Yes	No	No
Works under any filesystem	Yes	Yes	No

mdadm for straightforward redundancy under any filesystem, on a machine where you want the array readable elsewhere.

ZFS for data integrity, which is the strongest option and means adopting its whole storage model.

Hardware RAID when you have a write-heavy workload that genuinely benefits from a battery-backed cache, and you accept the controller as a dependency and monitor its battery.

Never fakeraid.

The thing that matters more than any of this

RAID is not a backup.

It protects against a disk failing. It does nothing about:

• Deleting a file, which is deleted on every disk instantly
• Filesystem corruption, faithfully replicated
• Ransomware, encrypting the array as readily as a single disk
• Theft or fire, taking the whole machine
• A controller writing garbage to every member

Our restic and Borg comparison covers what does protect against those, and our self-hosting introduction makes the same point at more length: an untested backup is a hypothesis, and RAID is not one at all.

RAID buys uptime through a disk failure. That is worth having and it is not the same thing.

Frequently Asked Questions

Is hardware RAID still worth using?

Rarely on modern systems. CPU parity calculation is no longer a bottleneck, software RAID is portable between machines, and a failed controller can make an array unreadable without an identical replacement. The remaining case is a battery-backed write cache, which genuinely helps write-heavy workloads.

What happens if my RAID controller fails?

You typically need an identical or closely compatible controller to read the array, because the on-disk metadata format is proprietary and vendor specific. Software RAID arrays can be assembled by any Linux machine, which is one of the strongest practical arguments for it.

What is a write hole and which RAID types have it?

It is the window where a parity RAID stripe is partially written when power is lost, leaving data and parity inconsistent without any indication. It affects RAID 5 and 6, and is addressed by a battery-backed cache in hardware, a journal in mdadm, or by ZFS’s copy-on-write design which avoids it structurally.

Should I use my motherboard RAID?

No. Onboard RAID is usually fakeraid, meaning a firmware option ROM plus a driver doing the work in software anyway. You get the portability problems of hardware RAID and the performance of software RAID, which is the worst combination. Use mdadm instead.

Is ZFS better than mdadm for RAID?

For data integrity yes, because ZFS checksums every block and can repair corruption from a good copy, which mdadm cannot detect at all. mdadm is simpler, works under any filesystem, and is in the mainline kernel, so it suits cases where you want redundancy without adopting a whole storage stack.

Does RAID replace backups?

No, and this is the most important thing to understand about it. RAID protects against a disk failing. It does nothing about deleting a file, a filesystem corrupting, ransomware, or the machine being stolen, all of which are replicated across the array instantly.