Hardware RAID vs Software RAID

The split is simple. Hardware RAID puts a dedicated controller between your disks and the operating system. The card has its own processor, its own firmware, and usually cache memory backed by a battery or a flash module. It builds the array, calculates parity, and hands the OS a single logical volume. The OS never sees the individual disks.

Software RAID does the same job on the host CPU. Linux mdadm, ZFS (RAIDZ and mirrors), Btrfs, Windows Storage Spaces, Synology SHR, and Unraid's parity array are all software RAID. The disks connect straight to the motherboard or to a plain host bus adapter, and the OS assembles them.

The old argument for hardware RAID was that parity was too heavy for the CPU. That stopped being true years ago. A modern processor computes RAID 5 or RAID 6 parity at many gigabytes per second, so on a homelab the CPU cost of software RAID is a rounding error. What the card still buys you is a battery-backed write cache and a volume the BIOS can boot from without help, not raw speed.

This is the real difference, and it is the reason TrueNAS, Unraid, and Proxmox all lean on software RAID. A hardware controller checks parity, but it trusts that what the disk returns is correct. If a drive quietly hands back bad data (bit rot, a firmware bug, a flipped bit) the card has no way to know, and it can even write that corruption across the array during a rebuild.

ZFS and Btrfs checksum every block and verify it on every read. On a redundant pool they do more than detect corruption; they repair it automatically from a good copy, which ZFS calls self-healing. A scheduled scrub walks the whole pool and fixes silent errors before they spread. Hardware RAID has nothing equivalent. For data you plan to keep for years, that checksumming is worth more than any cache module.

This is also why you do not stack the two. Put ZFS on top of a hardware RAID volume and the card hides the individual disks, so ZFS loses the direct access it needs to detect and heal errors. For ZFS you want the opposite of a RAID card: a plain HBA in IT mode that passes each disk through untouched. Picking the filesystem is its own decision, covered in Btrfs vs ZFS.

Benchmarks have been clear for a long time: software RAID on a modern CPU matches or beats mid-range hardware cards for throughput. mdadm and ZFS both drive a stack of drives without breaking a sweat, and a single spinning disk already fills a gigabit link, so the network is your bottleneck long before the RAID engine is.

The one place a hardware controller still has a real edge is small synchronous writes, the pattern a busy database or a VM datastore produces. The card's battery-backed write-back cache acknowledges the write the instant it lands in cache, then flushes to disk in the background, which cuts latency. Software RAID can match this, but you build it: a ZFS pool with a fast, power-loss-protected SLOG device, or an mdadm array behind a UPS with the right cache settings. For sequential media, backups, and general homelab use, there is no difference you will feel.

The cost software RAID does carry is host resources. ZFS in particular likes RAM for its ARC read cache; a rough rule is a few gigabytes plus about 1 GB per TB of pool if you want it snappy. On a box with 16 GB or more that is fine, and it is the reason ZFS wants a real machine rather than a Raspberry Pi.

Hardware RAID writes its metadata in a format tied to the controller family. If the card dies, you cannot just plug the disks into another machine and read them. You need a compatible replacement controller, often the same brand and a close firmware version, before the array comes back. People have lost data waiting on a discontinued card. If you run hardware RAID on anything you care about, buy the spare controller at the same time.

Software RAID has no such trap. An mdadm array or a ZFS pool is described by metadata on the disks themselves, so you can move the drives to any machine running the same software and import them. A dead motherboard becomes a thirty-minute swap, not a parts hunt. That portability, plus full SMART visibility on every disk (hardware cards often hide drive health behind the controller), is a quiet but large advantage for a homelab that gets rebuilt and re-shuffled over time.

There is a third thing that pretends to be hardware RAID: the RAID mode in your motherboard firmware, Intel RST/VROC or AMD RAIDXpert. It is not real hardware RAID. There is no dedicated processor or cache; the work still happens on your CPU through a driver, which is why people call it fakeRAID. You inherit the downsides of hardware RAID (a proprietary on-disk format, poor portability, driver dependence) with none of the upsides (no battery-backed cache, no offload).

Leave the SATA controller in AHCI mode and use real software RAID instead: mdadm or ZFS on Linux, Storage Spaces on Windows. The only defensible reason to touch fakeRAID is a Windows install that has to boot from a mirror on a board with no other option. Before you commit to any layout, size it in the RAID and ZFS storage calculator so you know the usable capacity and fault tolerance you are signing up for.