ZFS vs mdadm vs hardware RAID for a one-box homelab

Choose who gets the keys to your disks. ZFS manages the pool and filesystem together. Linux MD, managed with mdadm, puts an array beneath your chosen filesystem. Hardware RAID hands array management to a controller. Pick the stack you can maintain—and recover when the box has a bad day.

This guide uses OpenZFS, Linux MD and controller documentation checked on October 19, 2026.

Compare complete stacks before choosing a RAID label

The OpenZFS project describes OpenZFS as a filesystem and volume manager. Its storage and filesystem responsibilities therefore belong in the same design discussion: layout, integrity policy, supported software and recovery tools need to fit together.

The mdadm manual describes Linux software RAID devices implemented by the kernel’s MD driver. An array presents a virtual block device that can hold a filesystem. mdadm manages that array; the chosen filesystem remains a separate part of the stack.

With hardware RAID, identify the controller and the logical device it exposes, then identify the filesystem above it. A controller’s array status and the filesystem’s status are different observations. Any extra encryption, volume-management or virtualisation layer also belongs in the inventory.

Write a simple ownership map before comparing features: which component manages member devices, which manages files, and which tools are needed to recover each? A familiar RAID level alone does not answer those questions.

Use a requirement-based decision table

Match your main requirement to a stack, then plan its recovery path.

Requirement	Starting choice	Check before committing
Integrated filesystem/pool administration and end-to-end checksumming are priorities	ZFS with suitable direct-drive access	Supported host software, exact layout, repair prerequisites and a recovery environment
A supported Linux block-array workflow with an independently chosen filesystem fits the task	Linux MD managed by mdadm, plus that filesystem	Array metadata, filesystem features, boot assembly and monitoring of both layers
An existing validated controller/logical-volume workflow is a real requirement	Hardware RAID plus a supported filesystem	Exact controller/firmware, cache protection, management tools and replacement/import support
Available hardware hides the member drives behind an uncertain mode	Resolve access and ownership first	What the OS actually sees and whether the selected stack supports that presentation
Recovery depends on moving storage to replacement hardware	Treat portability as an acceptance requirement	Compatible software or controller, metadata, keys and a completed recovery test
The requirement is recovery after losing the box or deleting data	Add an independent recovery layer whichever stack is chosen	Surviving copy, access and tested application restoration

The RAID, snapshots and backups guide covers that last recovery layer. This article chooses the implementation and its maintenance responsibilities. Redundancy within any chosen layout does not remove the separate-copy requirement.

Choose ZFS when its ownership model fits

Choose ZFS for integrated filesystem and pool administration on a supported host. Define what must be checksummed, how redundancy is configured, which errors will be monitored and how the storage will be accessed after a host failure.

OpenZFS’s hardware guidance advises against putting ZFS behind hardware RAID. It explains that hiding redundancy in the controller limits ZFS’s opportunities to repair checksum failures. Give ZFS direct access to the drives and their redundancy instead of stacking it over controller-managed RAID.

Verify the actual controller mode and drive presentation. Use a supported driver and mode that expose member drives, health information and errors directly. Treat per-drive controller virtual disks as a different arrangement from direct-drive access.

Keep the plan simple enough to document. Extra cache devices, storage classes or tuning settings need their own workload justification and failure analysis. Size memory and cache devices for your workload. For drive choices, compare NVMe SSDs for NAS cache and app pools.

For a buying decision about the connection layer, our SATA and IT-mode HBA guide compares direct-drive cards, slot requirements and cables. Choose the controller path before adding pool data; a hardware-RAID label does not settle ZFS compatibility.

Choose mdadm with a deliberate filesystem plan

Choose Linux MD when its supported block-array workflow and a separately chosen filesystem meet the task. Record each layer’s tools, features and monitoring responsibilities.

Verify any required file history, encryption or filesystem integrity feature in that chosen implementation. Array management does not settle those requirements.

Record member identity, layout, metadata and the supported assembly environment, including filesystem and encryption dependencies. A recovery plan should explain how existing data will be recognised after reinstalling or replacing the host.

Test assembly and data access in your replacement environment.

Choose hardware RAID with a controller recovery plan

Choose hardware RAID when you need an established controller and logical-volume workflow. That choice adds specific hardware and management dependencies to retain: controller identity, firmware, configuration, supported tools, cache/protection components and the documented replacement path.

Ask how the replacement controller would recognise the existing configuration, and what compatibility is required. Do not assume any card from the same brand can import the array. Preserve configuration records and follow the exact vendor’s recovery procedure before considering changes to surviving members.

The used enterprise gear guide adds the pre-purchase identity, firmware and accessory checks for a used controller or HBA. Resolve the required mode and supported maintenance route before putting important data behind an uncertain part.

Keep the filesystem and application checks even when the controller reports healthy logical storage. A controller-managed volume is a layer in the recovery plan, not a replacement for every layer above it.

Distinguish integrity checks from successful recovery

OpenZFS’s checksum documentation describes corruption detection and conditional repair using suitable RAID protection or redundant copies. Checksums detect corruption; repair needs a suitable surviving copy.

Linux MD has its own maintenance operations. The kernel documentation describes check as a redundancy check and notes that repairs can happen for some RAID levels. Its mismatch counter concerns sectors rewritten, or that would be rewritten for a check. Do not describe that counter as a count of files verified correct or assume every operation named check is non-writing.

For any stack, keep device health, array/pool state, filesystem verification and application operation as separate evidence. Decide what a successful maintenance report proves, then add known-file and application checks where the requirement needs them. Finish with a known-file or application restore check.

When an error appears, preserve observations and identify the affected layer before acting. Choose the repair procedure for that exact stack before changing valuable data.

For member-drive reporting, use the SMART drive-health guide. A device log and a pool or filesystem integrity result answer different questions, so preserve both when investigating an error.

Understand cache acknowledgement and protection

A protected-cache feature needs a documented configuration and a healthy protection mechanism. Broadcom’s historical CacheVault engineering note describes a MegaRAID write-back implementation that acknowledges a write when controller cache has received the data. It also warns that forced write-back without a functional protection component leaves data unprotected by cache offload.

For your controller, document the selected policy, protection-module health, reported fault state and fallback when protection is unavailable.

Do not force unprotected write-back or disable write-safety settings to make a benchmark look better. Keep write-safety settings enabled while you establish that behaviour. Plan UPS protection separately from the storage stack’s acknowledgement and flush rules.

Plan the one-box boot and resource dependencies

Identify the boot device, the controller exposing it and the software needed to reach application data. Record the actual activation order for your platform, including encryption keys or other required access. Keep a recovery route that can obtain those dependencies when the normal installation is unavailable.

For virtualised storage, explicitly assign ownership of physical devices and of the filesystem. The Proxmox architecture guide covers the separate host/guest boundary. Adding a VM does not remove the need to identify where member drives, metadata and recovery tools remain accessible.

Include scrubbing, rebuilding and reshaping in your workload plan. If CPU use, RAM, completion time or throughput decides the purchase, measure your intended combination with expendable data and keep the method.

Verify growth and upgrades against the exact layout

Ask how the chosen layout can grow and what is required to reverse or recover from a failed change. Check the installed software release, topology, metadata, controller firmware and filesystem support. Use the expansion procedure for that exact version and layout.

Do not carry forward a blanket rule that a topology can never expand, or that adding a disk is always simple and non-disruptive. Supported paths evolve and depend on the configuration. Read the applicable documentation before buying around an assumed upgrade route.

Treat software, feature and firmware changes as recovery changes too. Preserve a working recovery copy and the recorded configuration, then verify which replacement environment can read the resulting storage. Recheck the documented maintenance and monitoring route after a change.

Make an acceptance record before relying on the stack

Use expendable data for the trial and define the expected file contents, metadata and application operation before testing. Keep the working source and an independent recovery copy safe. A trial should close a named uncertainty, not introduce an uncontrolled failure into important storage.

Test stage	Evidence to retain	Question it answers
Inventory and access	Exact components, software, ownership map and visible members	Does the implementation match the planned stack?
Workload and observation	Defined workload, completion result and monitoring output	Can the required operation and its status be observed?
Supported restart	Boot/activation steps, keys and successful data/application access	Does the normal startup path cover every dependency?
Intended recovery scenario	Supported replacement environment, preserved configuration and verified contents	Can useful data and operation return under that scenario?
Maintenance/change review	Documented check or change, observed result and remaining gaps	What was actually established, and which earlier observations need repeating?

Record which files, startup paths and recovery scenarios you exercised, then repeat the relevant checks after a change.

Choose ZFS for integrated pool and filesystem management, mdadm for a Linux array beneath your filesystem, or hardware RAID for an established controller workflow. Keep the ownership map and recovery instructions beside your backup plan.