How it works

ZFS is both a filesystem and a volume manager: disks are grouped into vdevs, vdevs form a pool, and datasets (with optional snapshots and clones) live on that pool. Writes are copy-on-write, so in-place overwrites do not silently trash the previous block. Every block carries an end-to-end checksum; on read, ZFS compares the checksum and, when the pool has redundancy, can fetch a good copy from another disk and repair the bad one (self-healing). A scrub walks the pool on a schedule to find silent corruption early; a resilver rebuilds a replaced member.

Vdevs are the redundancy units. Common shapes: a mirror (two or more disks holding the same data), raidz1 (one parity disk, similar idea to RAID-5), raidz2 (two parity, RAID-6-like), and raidz3 (three parity). Stripe capacity across multiple vdevs to grow a pool. You generally cannot add a single disk to an existing raidz vdev to expand it; plan the layout before you fill the pool. Datasets are the folders/filesystems you share; snapshots are cheap point-in-time views; clones are writable copies of a snapshot. The ARC is the in-RAM read cache; optional L2ARC (SSD cache) and SLOG/ZIL devices speed specific workloads but are not free capacity.

Appliance NAS boxes that ship Btrfs or Synology SHR hide a different stack. Hardware RAID controllers present one virtual disk and own rebuilds outside ZFS. ZFS wants raw disks (or a JBOD/single-disk DAS), not a hardware RAID volume. TrueNAS CORE and TrueNAS SCALE are the common home ways to run a ZFS pool with a web UI; some x86 NAS appliances can install SCALE instead of the vendor OS.

When it matters

It matters when you want checksums and snapshots on home storage, when you are building a pool on a mini PC or dedicated NAS, and whenever silent bit-rot or a single failed disk would ruin months of photos and backups. ZFS shines for media libraries, Time Machine / SMB shares, and lab VMs where you want frequent snapshots before upgrades. ECC RAM is nice-to-have for home, not a hard requirement; many home pools run fine without it. The real planning traps are expanding raidz later, mixing SMR archive drives into a vdev that must resilver quickly, and putting ZFS on top of a hardware RAID virtual disk.

Shopping path for a home ZFS pool: an x86 box that can run TrueNAS (or similar), enough CMR NAS HDDs for your chosen mirror or raidz layout, and optionally a USB JBOD/single-disk DAS to hang extra disks as another vdev. Prefer hot-swap trays so a failed member can leave without tearing the chassis open. Watch SMART during burn-in before disks join the pool.

An x86 4-bay NAS that can run TrueNAS SCALE for a local ZFS pool, a USB DAS that presents raw disks for extra vdevs, and a CMR NAS HDD suited to mirror or raidz members.

The UGREEN NASync DXP4800 Plus is an x86 4-bay NAS (Pentium Gold, DDR5, 10GbE) that can run TrueNAS SCALE (or similar) for a home ZFS pool; do not confuse it with appliance-only Btrfs/SHR boxes that never expose raw disks to ZFS.

The TerraMaster D4-320 is a 4-bay USB 3.2 Gen 2 DAS in single-disk mode, so a TrueNAS host can see each SATA drive as a raw member for a mirror or raidz vdev (not enclosure RAID).

The WD Red Plus 4TB CMR (WD40EFPX) is a CMR NAS HDD commonly used in ZFS mirror and raidz vdevs; avoid SMR drives when resilver time and scrub load matter.

Start with What Is RAID? for how striping and parity protect (or fail to protect) data, then How to Replace a Failed RAID Drive for the swap workflow. Disk presentation without enclosure RAID: JBOD. Trays and health while members stay online: Hot-swap, SMART, TRIM. Appliance NAS vs a more open x86 box: Synology DS225+ vs UGREEN NASync DXP4800. DAS shopping: TerraMaster D4-320 vs ORICO HDD Dock.