Two fundamentally different approaches to data protection. Hardware RAID dominated servers for decades, but ZFS — Sun's copy-on-write filesystem — changed the game with checksumming, self-healing, and a design that eliminates entire categories of data corruption. Which one belongs in your NAS?
Architecture: Software-Defined vs Dedicated Hardware
A hardware RAID card is a dedicated PCIe device with its own processor (ROC — RAID-on-Chip), DRAM cache (often battery-backed), and firmware that manages disk groups at the block level. The operating system sees a single virtual disk — it has no idea what is happening on the individual spindles underneath. This made sense when CPU cycles were scarce and SATA was slow; the card offloaded parity calculations and presented a clean block device.
ZFS is the opposite. It is a combined filesystem, volume manager, and RAID engine running entirely in software. Every byte passes through ZFS's own checksumming, compression, and parity pipeline. The OS sees each physical disk individually, and ZFS's Adaptive Replacement Cache (ARC) in system RAM does the heavy lifting that a hardware RAID card's onboard cache would otherwise do.
The practical consequence: ZFS is far more flexible (mix disk sizes, expand online, add cache vdevs) but demands system RAM and CPU. Hardware RAID is simpler, OS-agnostic, and can boot without a ZFS-aware bootloader, but locks you into a specific vendor's card and hides disk health from the filesystem.
The RAID Write Hole — and Why ZFS Eliminates It
What is the write hole?
Imagine a RAID 5 array writing a stripe across four disks. Power is lost after two of the writes complete but before parity lands. When the system comes back up, the stripe contains a mix of old data, new data, and no valid parity — making reconstruction from the remaining disks impossible. This partial-stripe corruption is the RAID write hole, and it affects every hardware RAID card that relies on in-place writes.
Hardware RAID cards attempt to mitigate the write hole with a battery-backed unit (BBU) or non-volatile cache — if power is interrupted, the card flushes its cache from battery when power returns. But the design still allows a partial stripe to land if the cache is exhausted or the battery fails.
ZFS avoids the write hole entirely through copy-on-write (CoW). ZFS never overwrites data in place. A transaction is written to a new location on disk, the checksum is computed, and only when every block in the transaction group (txg) is committed does ZFS atomically update the uberblock to point at the new data. If power is lost mid-write, the old uberblock — and all the old data it points to — remains intact. No partial stripes, no corrupted parity.
Bottom line
ZFS guarantees that the filesystem is always consistent after an unclean shutdown. Hardware RAID relies on battery-backed cache as a band-aid — if the battery is dead or the cache is flushed, you will lose data.
ARC vs Hardware RAID Cache
Hardware RAID cards carry 512 MB – 4 GB of onboard DRAM, often protected by a BBU. This cache absorbs writes (write-back mode) so the OS can continue immediately without waiting for spinning rust. The cache is small, fixed in size, and only helps the RAID card's stripe calculations.
ZFS's ARC, by contrast, lives in system RAM and can use all available memory. On a 32 GB RAM home server, ZFS may dedicate 24 GB to ARC — ten times what any hardware RAID card carries. ARC caches frequently-read data, prefetched blocks, directory entries, and metadata. It adapts to workload: sequential streams, random I/O, and metadata-heavy operations all get different treatment.
ARC sizing guideline
Minimum: 1 GB of RAM per 1 TB of raw storage. Recommended: 5 GB per 1 TB if you plan to use deduplication (dedup's DDT lives in ARC). Hardware RAID: Onboard cache is fixed at 512 MB – 4 GB regardless of pool size.
RAIDZ Expansion: Flexible but Limited
Hardware RAID cards let you add a hot-spare or swap a single drive (on supported controllers). But expanding a RAID 5 or RAID 6 array by adding more disks to the existing group is rare — most cards require you to destroy and re-create the array to change its geometry.
ZFS RAIDZ supports online RAIDZ expansion (added in OpenZFS 2.2). You can add one or more disks to an existing RAIDZ vdev and the free space is redistributed. However, the expansion is not a re-stripe — new data fills the added space but old data stays where it is unless you manually rewrite it. For optimal performance, prefer creating a new vdev and striping across vdevs rather than expanding an existing one.
ZFS mirrors are trivially expandable: just attach a disk to any mirror vdev and it becomes a 3-way mirror, or create a new mirror vdev and the pool automatically stripes across both. Hardware RAID 1 expansion is similarly simple on many cards, but hardware RAID 5/6 expansion remains painful.
HBA IT Mode: The ZFS-Friendly Alternative
A used LSI 9207-8i or 9300-8i flashed to IT mode (Initiator Target) costs $30–50 on the secondhand market and is arguably the best investment you can make for a ZFS NAS. In IT mode the card acts as a pure HBA (Host Bus Adapter) — it passes every disk through as an individual device with no RAID, no cache, and no translation layer.
Why does this matter? ZFS needs raw disk access to:
Read and verify its own per-block checksums (hardware RAID hides the real blocks behind its virtual disk)
Detect and report disk errors via S.M.A.R.T. and SCSI sense data
Manage the vdev layout and handle disk replace/scrub/resilver at the physical level
Use ZFS's own cache, compression, and encryption without double-caching conflicts
Running ZFS on top of a hardware RAID card in RAID mode is strongly discouraged. The RAID card's firmware can reorder writes, present late or incorrect error status, or fail in ways that ZFS cannot detect — defeating the very purpose of ZFS's self-healing design. Flash the card to IT mode, or buy a pre-flashed HBA. Your data will thank you.
TrueNAS and Hardware RAID Don't Mix
TrueNAS (both CORE and SCALE) is built on OpenZFS. The TrueNAS installers and forums universally recommend against hardware RAID. The official TrueNAS hardware guide specifies that controllers must operate in JBOD or HBA mode.
Why? Beyond the checksumming argument, hardware RAID introduces write hole risks, cache coherency conflicts (the RAID card caches data that ZFS also wants to cache), and drive identity problems — the OS sees one large block device instead of individual drives, which breaks ZFS's ability to manage vdev health.
Never use a hardware RAID card in RAID mode with TrueNAS. Use an HBA in IT mode.
ZFS vs Hardware RAID — At a Glance
Feature
ZFS (Software)
Hardware RAID
Per-block checksums
Yes — every block has a cryptographic checksum, verified on read
No — relies on disk's own CRC, cannot detect silent corruption
Limited — most cards require recreating the array to change geometry
RAM usage
Dynamic: uses available RAM for ARC (1 GB/TB min)
Uses system RAM only for I/O buffers; cache is onboard (512 MB–4 GB)
OS-independent boot
Requires ZFS-aware bootloader (GRUB, rEFInd, or UEFI ZFS driver)
Yes — card presents a standard block device; any OS can boot
Hardware lock-in
None — pool can be imported on any system with OpenZFS
Significant — broken card of a different brand may not import the array
Self-healing (scrub)
Yes — scrub reads all blocks, verifies checksums, repairs from parity
Limited — consistency check only; cannot detect silent bit rot
Mixed disk sizes
Yes — within a vdev the smallest disk sets the usable size; across vdevs disks can differ
Usually yes — smallest disk sets the group size; larger disks waste space
Frequently Asked Questions
Is ZFS faster than hardware RAID?
Not inherently. Hardware RAID with write-back cache can outperform ZFS on sequential writes by absorbing latency. ZFS with a SLOG device (separate write cache) and sufficient ARC memory is competitive, and on reads with a large ARC pool ZFS oftenexceeds hardware RAID performance. See our performance methodology guide for detailed benchmarks.
Can I mix ZFS and hardware RAID in the same system?
Yes, but it is rarely beneficial. If you already own a hardware RAID card, you can flash it to IT mode (JBOD) and let ZFS manage the disks directly. If the card cannot be flashed to IT mode, do not use ZFS on top of its virtual disks — use a different filesystem (like ext4 or XFS) for that array and a separate HBA for ZFS.
What size pool needs ECC RAM with ZFS?
ECC RAM is recommended for any ZFS pool where data integrity matters — even small pools. A single bit flip in ARC can corrupt the block it is caching, and while ZFS checksums catch that corruption on read, the data is already gone. For home NAS builds under 32 TB, non-ECC with regular scrubs is a common compromise. For production or pools over 32 TB, use ECC.
Should I use RAID 5/6 or ZFS RAIDZ?
RAIDZ (particularly RAIDZ2) is strongly preferred. RAIDZ2 gives two-disk redundancy — equivalent to RAID 6 — with ZFS's copy-on-write, checksums, and self-healing. Use our ZFS RAID calculator to compare usable capacity and fault tolerance across configurations. Also see our RAID comparison page for side-by-side capacity, speed, and parity tradeoffs.
Plan your ZFS pool
Not sure which RAID level gives you the right balance of capacity, redundancy, and performance? Our interactive calculator does the math.