Hardware RAID vs Software RAID for Home Servers
Quick Verdict
Use ZFS (software RAID) for most home server builds. It provides checksumming, self-healing, snapshots, and compression with no additional hardware cost. Hardware RAID only makes sense if you already own a quality controller with battery-backed cache and need raw sequential throughput. mdadm is the lightweight alternative when ZFS’s RAM requirements are too steep.
The Three Options
Hardware RAID
A dedicated RAID controller card (like the LSI MegaRAID or Dell PERC series) handles all RAID calculations on its own processor. The OS sees a single virtual disk — it has no idea multiple physical drives exist underneath.
Key components:
- PCIe RAID controller card ($50–300+ used)
- Onboard processor and cache RAM (256 MB–2 GB)
- Battery Backup Unit (BBU) or flash-backed cache to protect writes during power loss
ZFS (Software RAID)
ZFS is a combined filesystem and volume manager built into the kernel (on FreeBSD natively, on Linux via OpenZFS). It manages RAID directly — no controller card needed. Your drives connect via a simple HBA (Host Bus Adapter) in JBOD/passthrough mode.
RAID-Z levels:
- RAID-Z1 = single parity (like RAID 5)
- RAID-Z2 = double parity (like RAID 6)
- RAID-Z3 = triple parity
- Mirror = mirrored pairs (like RAID 1/10)
mdadm (Linux Software RAID)
mdadm is Linux’s built-in RAID subsystem. It operates at the block device level — you create an mdadm array, then put any filesystem (ext4, XFS) on top. Lightweight and simple, but lacks ZFS’s advanced features.
Feature Comparison
| Feature | Hardware RAID | ZFS | mdadm |
|---|---|---|---|
| Data checksumming | No | Yes (end-to-end) | No |
| Self-healing | No | Yes (with redundancy) | No |
| Snapshots | No | Yes (instant, copy-on-write) | No (needs LVM) |
| Compression | No | Yes (LZ4, ZSTD) | No |
| Deduplication | No | Yes (RAM-intensive) | No |
| Send/receive replication | No | Yes | No |
| Controller dependency | Yes (vendor lock-in) | No (any HBA/SATA) | No |
| CPU overhead | None (offloaded) | Moderate | Light |
| RAM requirements | None (uses onboard cache) | 1 GB per TB recommended | Minimal |
| Write cache protection | BBU/flash-backed cache | Requires SLOG device or accept risk | None built-in |
| Expand array with single disk | No (controller-dependent) | No (must add full vdev) | Yes |
| Hot spare support | Yes | Yes | Yes |
| Cost | $50–300+ for card | Free (software) | Free (software) |
| Portability | Low (controller-dependent) | High (export/import pool) | High (assemble on any Linux) |
Performance
In benchmarks, performance varies by workload:
Sequential reads/writes: Hardware RAID with BBU cache wins for large sequential operations. The dedicated processor and write-back cache deliver near-theoretical maximum throughput, especially with RAID 5/6.
Random I/O: ZFS competes closely with hardware RAID. ARC (Adaptive Replacement Cache) acts as a read cache using system RAM, and ZFS’s copy-on-write design reduces write amplification.
mdadm: Consistently the slowest in benchmarks, particularly for writes. The “write hole” problem (where a crash during a RAID 5/6 write can leave parity inconsistent) is a known limitation.
For home servers: The performance difference is negligible for typical self-hosting workloads (Docker containers, file sharing, media streaming). You’ll saturate your gigabit network long before you stress any of these RAID implementations.
Data Safety
This is where ZFS dominates.
The Bit Rot Problem
Hard drives silently corrupt data over time. A flipped bit in a stored file goes undetected by both hardware RAID and mdadm because neither checksums the data. You won’t know your backup of family photos has a corrupted file until you try to open it years later.
ZFS checksums every block of data written to disk. On every read, it verifies the checksum. If corruption is detected on a redundant pool (mirror or RAID-Z), ZFS automatically repairs the corrupted block using the good copy. This is self-healing — no other RAID solution offers it without additional software layers.
Controller Failure
With hardware RAID, your data is locked behind proprietary metadata. If the controller dies, you need an identical replacement (same model, sometimes same firmware version) to read the array. This is the single biggest risk of hardware RAID for home users — enterprise hardware goes end-of-life, replacements become scarce.
ZFS and mdadm arrays are portable. Move the drives to any machine with the same software and import the array.
Write Safety
Hardware RAID controllers with BBU cache protect against power-loss data corruption. Without BBU, write-back caching risks data loss on power failure.
ZFS uses copy-on-write — it never overwrites data in place. A sudden power loss leaves you with the last consistent state, not a corrupted partial write. For maximum safety, add a SLOG (ZFS Intent Log) device — a small, fast, power-loss-protected NVMe drive.
mdadm has no built-in write protection. A crash during a RAID 5/6 write can create a “write hole” where parity is inconsistent. This is mdadm’s biggest weakness.
Cost
| Solution | Hardware Cost | Software Cost | Total |
|---|---|---|---|
| Hardware RAID (used) | $50–150 (controller + cables) | $0 | $50–150 |
| Hardware RAID (new) | $200–500+ | $0 | $200–500+ |
| ZFS | $30–60 (HBA card in IT mode) | $0 (OpenZFS is open source) | $30–60 |
| mdadm | $0 (use motherboard SATA) | $0 (built into Linux) | $0 |
ZFS needs an HBA card only if your motherboard doesn’t have enough SATA ports. Many home server motherboards have 4–6 SATA ports — sufficient for most builds. If you need more, an LSI 9211-8i flashed to IT mode costs $25–40 used on eBay.
RAM Requirements
This is ZFS’s main trade-off.
ZFS: The rule of thumb is 1 GB of RAM per TB of storage for decent ARC performance. A 16 TB pool benefits from 16 GB of RAM. ZFS works with less — the minimum is around 4 GB — but performance degrades as ARC shrinks. If you enable deduplication, RAM requirements jump to 5 GB per TB (don’t enable dedup for home use).
Hardware RAID: No system RAM required — the controller has its own cache.
mdadm: Negligible RAM overhead. A few MB for metadata.
Bottom line: If your home server has 8 GB of RAM and 4 TB of storage, ZFS runs fine. If you’re building a 40 TB NAS and can’t afford 32+ GB of RAM, consider mdadm.
Which Should You Choose?
Use ZFS If:
- You care about data integrity (photos, documents, anything irreplaceable)
- You want built-in snapshots and replication
- You have 8+ GB of RAM
- You’re running TrueNAS, Proxmox, or Ubuntu Server
- You want compression to squeeze more out of your drives
- You plan to keep the server running for years (ZFS pools age gracefully)
Use mdadm If:
- You have limited RAM (4–8 GB)
- You need to expand arrays by adding single disks
- You prefer ext4/XFS as your filesystem
- You want simplicity — mdadm arrays are easy to create and manage
- You’re running a Raspberry Pi or low-RAM thin client
Use Hardware RAID If:
- You already own a quality controller with BBU (Dell PERC H710P, LSI MegaRAID)
- You need maximum sequential throughput for large file transfers
- You’re repurposing enterprise server hardware that came with a RAID card
- You’re comfortable with controller vendor lock-in
Never Use:
- Motherboard “fake RAID” (Intel RST, AMD RAIDXpert) — this is software RAID that depends on specific BIOS firmware. Offers the worst of both worlds: vendor dependency of hardware RAID with the performance of software RAID. Use mdadm or ZFS instead.
Setting Up ZFS (Quick Start)
On Ubuntu Server 22.04+:
sudo apt install zfsutils-linuxCreate a mirrored pool with two drives:
sudo zpool create tank mirror /dev/sda /dev/sdbCreate a RAID-Z1 pool with three drives:
sudo zpool create tank raidz /dev/sda /dev/sdb /dev/sdcEnable compression:
sudo zfs set compression=lz4 tankFor full ZFS configuration, see our ZFS Hardware Requirements guide.
Setting Up mdadm (Quick Start)
Create a RAID 1 mirror:
sudo mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda /dev/sdbFormat and mount:
sudo mkfs.ext4 /dev/md0
sudo mount /dev/md0 /mnt/storageSave the configuration:
sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf
sudo update-initramfs -uFAQ
Can I mix ZFS with hardware RAID?
Don’t. ZFS needs direct access to individual disks to manage checksumming and redundancy. Putting ZFS on top of a hardware RAID virtual disk negates ZFS’s data integrity features. Use an HBA in JBOD/passthrough mode instead.
Is ZFS stable on Linux?
Yes. OpenZFS on Linux has been production-ready for years. It’s the default filesystem on TrueNAS, Ubuntu offers it as a root filesystem option, and Proxmox VE uses it natively. The licensing debate (CDDL vs GPL) hasn’t affected stability or usability.
Can I convert from hardware RAID to ZFS?
Not in-place. You need to back up your data, replace the RAID controller with an HBA (or flash it to IT mode), create a ZFS pool on the bare drives, and restore your data.
How many drives do I need?
- Mirror: 2 drives minimum (50% usable space)
- RAID-Z1: 3 drives minimum (~67% usable)
- RAID-Z2: 4 drives minimum (~50% usable)
- mdadm RAID 5: 3 drives minimum (~67% usable)
Related
Get self-hosting tips in your inbox
Get the Docker Compose configs, hardware picks, and setup shortcuts we don't put in articles. Weekly. No spam.
Comments