Alright, let’s settle this ancient, holy war. You’re standing there, looking at your server or your pile of drives, and you have to decide: do you let a dedicated piece of hardware manage your data redundancy, or do you let the Linux kernel itself do the heavy lifting? The answer, like most good things in system administration, is “it depends,” but I can tell you that for 99% of you reading this, the answer is going to be software RAID with mdadm. Let’s break down why, and more importantly, when you might actually want to reach for that expensive hardware card.

The core of the debate boils down to one concept: where the RAID intelligence lives. With hardware RAID, it’s on a dedicated controller card with its own processor and memory. With software RAID, it’s in the Linux kernel. This simple difference ripples out into everything.

The Case for Software RAID (mdadm)

I’m just going to say it: mdadm is brilliant. It’s the workhorse. It’s so deeply integrated into the Linux kernel that it often feels like magic. Here’s why I almost always recommend it.

First, portability. Your mdadm array is a citizen of the system. You can yank those drives out, plop them into literally any other Linux machine—even with a different motherboard chipset—and as long as mdadm is there, it will almost certainly reassemble the array and mount it. It’s breathtakingly resilient. Try that with a hardware RAID card. If that card dies, you better have an identical model (or sometimes even the exact same firmware revision) waiting in a drawer, or you’re facing a very stressful data recovery exercise. With mdadm, the “controller” is the kernel itself, and that’s wonderfully standardized.

Second, transparency and control. You’re not dealing with a black box. You can see everything, probe everything, and tweak everything. You can cat /proc/mdstat and get the real-time state of your arrays. You can set up monitoring trivially with simple shell scripts. There’s no proprietary BIOS to fuss with; the configuration is right there in the config files.

# Check the status of your arrays. Simple, direct, always works.
cat /proc/mdstat

# Get a detailed, glorious info dump on your array.
mdadm --detail /dev/md0

Third, it’s free. No extra $500 card required. You pay for it in CPU cycles, but on any modern CPU, the overhead for RAID 1, 5, or 6 is negligible. For RAID 5/6, you might want a slightly beefier CPU, but we’re not talking Xeon-for-a-desktop levels here.

The (Niche) Case for Hardware RAID

So, when does the expensive hardware card get to justify its existence? In a few very specific scenarios.

The biggest one is battery-backed or capacitor-backed write cache (BBWC/FBWC). This is a game-changer for write performance, especially on RAID 5/6. The card can acknowledge a write to the OS the moment it lands in its super-fast, battery-protected cache, and then lazily write it to the physical disks later. This makes random write performance absolutely scream compared to a software setup. If you’re running a high-transaction database, this is the hardware RAID card’s killer feature. Without it, the argument for hardware RAID gets very weak, very fast.

Another is offloading. On a system with a wimpy CPU from a decade ago, yeah, offloading the parity calculations to a dedicated XOR processor on the card was a big deal. Today, not so much. Your CPU has cycles to burn.

Finally, there’s the boot argument. Some folks (and some system vendors) prefer a hardware RAID card because it presents a single, nice block device (/dev/sda) to the OS, making the bootloader’s life simple. But guess what? Modern mdadm and GRUB2 can handle booting from a software RAID 1 array just fine. It’s a solved problem.

The “Fake RAID” Trap

Walk into any computer store, and your motherboard probably boasts “RAID support!” This is a lie. This is fake RAID. It’s a BIOS-level driver that uses cheap motherboard silicon to do what mdadm does, but worse. It has all the downsides of hardware RAID (non-portability, driver hell) with none of the upsides (no dedicated processor, no massive cache). Avoid this like the plague. If you see “Intel RST” or “AMD RAID,” do yourself a favor: switch it to AHCI mode in the BIOS and let mdadm, a real software RAID system, handle it properly.

The Verdict

Here’s my direct advice: Use mdadm.

It’s simpler, more portable, more transparent, and more flexible. The performance difference is meaningless for most use cases, and the safety of knowing your array isn’t tied to a flaky piece of proprietary hardware is priceless.

Only consider a real hardware RAID card (from a quality vendor like Broadcom) if you absolutely need that battery-backed write cache for a demanding, write-heavy database workload. And even then, know that you’re trading raw performance for a potential single point of hardware failure.

For your file server, your backup target, your home lab? mdadm all the way. Let’s stop thinking of it as “software RAID” and start thinking of it as what it is: the Linux-native way to build a reliable storage system.