HN Debrief

How to Build a Minimal ZFS NAS Without Synology, QNAP, TrueNAS (2024)

  • Infrastructure
  • Open Source
  • Hardware
  • Developer Tools

The post argues that a DIY NAS does not need a vendor appliance or a heavyweight distro. You can get most of the value with plain Debian, OpenZFS, Samba, and a few backup and maintenance tools. That hit a nerve because a lot of people are rebuilding aging Synology and QNAP boxes, or avoiding them entirely, while current drive and RAM prices make every design choice sting.

If you build your own NAS, treat ZFS as the storage layer, not the whole product. The missing work is operational: disk identification, alerts, replacement drills, and tested restores. Also revisit inherited ZFS advice before overspending. ECC, huge RAM budgets, and rigid free-space rules were all challenged, while scrub schedules and backup validation were not.

Discussion mood

Mostly positive on building a DIY ZFS NAS, with a strong bias toward plain Linux or Proxmox over appliance software. The sharpest concerns were not about ZFS itself but about omitted operations work, flaky USB storage, overpriced current hardware, and backup plans that have never been restored.

Key insights

  1. 01

    A NAS needs failure operations

    What the post leaves out is the part that turns a pile of disks into a dependable appliance. You need active alerting, scheduled scrubs, a way to map a ZFS device name to the physical drive, and a rehearsed replacement flow using tools like smartmontools, a mailer, zpool status, and zpool replace. The core point is that the filesystem is not the product. The operating discipline around failure is.

    Write the runbook before you trust the box. Make sure the server can tell you a disk is sick without you logging in, and prove you can replace the right disk under time pressure.

      Attribution:
    • beagle3 #1 #2
    • denkmoon #1
    • ahofmann #1
    • shric #1
  2. 02

    ECC is helpful, not a ZFS prerequisite

    The useful correction here is narrow but important. Non-ECC RAM can corrupt data in flight, but that risk is not unique to ZFS and does not make ZFS more dangerous than other filesystems. The notorious claim that scrubs will amplify a single RAM bit flip into pool destruction was treated as the actual myth. That shifts ECC from "mandatory for ZFS" to a normal reliability upgrade whose value depends on budget and failure tolerance.

    Do not abandon ZFS just because your platform lacks ECC. If ECC pushes the build out of budget, spend first on good disks, backups, and monitoring, then add ECC when the platform economics make sense.

      Attribution:
    • Confiks #1
    • StrangeWill #1
    • dijit #1
    • layer8 #1
    • magicalhippo #1
  3. 03

    Free space guidance is really about fragmentation

    The 20 percent free-space rule held up badly as a universal law. The better framing is that high pool utilization raises fragmentation and write amplification, which hurts some workloads much more than others. Large mostly-append media files can run near full with little drama, while rewrite-heavy SSD pools and fragmented datasets will feel the squeeze early. The key nuance is that the old allocator cliff has been softened, but full pools still punish writes.

    Size pools around your write pattern, not a folklore threshold. Leave extra headroom for SSD-heavy or rewrite-heavy workloads, and worry less for mostly static large-file storage.

      Attribution:
    • Confiks #1
    • barrkel #1
    • gpt5 #1 #2
    • Dylan16807 #1
    • vladvasiliu #1
  4. 04

    USB is the most common reliability trap

    Several of the ugliest failures described here had nothing to do with ZFS and everything to do with the transport. USB SATA bridges miss TRIM, overheat, drop off the bus during scrub, and hide bad behavior behind flaky firmware. That is why people were much more comfortable recommending direct SATA or SAS, even on old surplus machines. Encryption, snapshots, and careful filesystem choices do not save you from an adapter that disappears under load.

    Avoid USB for primary pools unless you have already qualified the exact enclosure and bridge chipset under sustained load. If the data matters, attach drives over SATA or SAS.

      Attribution:
    • 6581 #1 #2
    • ahepp #1
    • toast0 #1
  5. 05

    Untested restore paths are fake backups

    One comment cut through all the design talk with a blunt failure story. A cloud backup existed, encryption was enabled, and the data was still lost because the restore path was not rehearsed and the key material was not recoverable. That is more valuable than generic 3-2-1 advice because it shows where home setups actually fail. Metadata, credentials, and procedures rot faster than disks do.

    Run a full restore drill and document every secret it needs. Store backup keys, commands, and account details somewhere separate from the NAS itself.

      Attribution:
    • dannyw #1
  6. 06

    ZFS wins on rebuild ergonomics

    People with scars from mdadm, LVM, and mixed Linux storage stacks were unusually emphatic here. ZFS collapses volume management and filesystem behavior into one model, which makes degraded-state recovery and rebuilds easier to reason about than ext4 on mdadm or LVM snapshots layered underneath. Even when other stacks can do similar things, the operational surface area is larger and the docs are worse.

    If you expect to replace disks yourself over years, optimize for the recovery model you will face at 2 a.m. Simpler rebuild semantics are worth real money in home and small-business storage.

      Attribution:
    • KaiserPro #1 #2
    • traches #1
    • dapperdrake #1

Against the grain

  1. 01

    OpenZFS feature growth worries some operators

    One experienced commenter explicitly avoided ZFS, not because they wanted less capability, but because they distrust its direction on Linux. They pointed to the separate page cache and a perceived bias toward adding giant features over tightening stability, then chose dm-integrity, mdadm, and XFS instead. That does not match the dominant enthusiasm, but it is a credible reminder that ZFS is not the only serious integrity-first stack.

    If your priority is the most boring Linux-native stack possible, compare ZFS against mdadm plus XFS or similar before you commit. Feature density is not always the same thing as operational confidence.

      Attribution:
    • a-french-anon #1
  2. 02

    Many home arrays fit SnapRAID or Unraid better

    For media-heavy home servers, some people argued that ZFS solves the wrong problem. If most of the data is replaceable, capacity matters more than strong online consistency, and mixing drive sizes matters more than perfect RAID behavior, SnapRAID plus mergerfs or Unraid can be a better fit. That is especially true when offsite backup of the entire dataset is financially unrealistic.

    Match the storage model to the value of the data. If only a small slice is truly irreplaceable, split that data out and use a simpler, more capacity-efficient scheme for the rest.

      Attribution:
    • devn0ll #1
    • joshmn #1
    • ppchain #1
    • cm2187 #1
  3. 03

    A single-disk NAS can be enough

    One commenter made the case that a tightly controlled single-disk NFS setup on an always-on machine is sometimes the right answer. The caveat is that this only works if you accept the lack of self-validating integrity and compensate with disciplined external copies, file lists, and manual verification. It is not elegant, and others rightly pushed on its blind spots, but it is a valid reminder that complexity should earn its keep.

    Do not build a full storage stack out of guilt. If your actual needs are small, start simple, then add integrity tooling before you add layers of infrastructure.

      Attribution:
    • ocd #1 #2 #3
    • TacticalCoder #1

In plain english

dm-integrity
A Linux device-mapper target that adds integrity metadata and verification for block devices.
ECC RAM
Error-correcting code memory that can detect and correct certain memory bit errors.
ext4
A widely used Linux filesystem known for maturity and stability.
LSI
A vendor whose storage controller chips and cards are widely used in home and enterprise NAS builds.
LVM
Logical Volume Manager, a Linux layer for flexible disk partitioning, pooling, and snapshots.
mdadm
A Linux tool for managing software RAID arrays.
mergerfs
A union filesystem that combines multiple disks into a single directory tree without traditional RAID.
NAS
Network-attached storage, a device or server that provides file storage over a network.
NFS
Network File System, a protocol for mounting and using files over a network.
OpenZFS
The open source implementation of ZFS used on Linux, FreeBSD, and other systems.
Proxmox
A virtualization platform based on Debian that supports virtual machines, Linux containers, and often ZFS.
QNAP
A company that sells NAS appliances and related storage hardware.
Samba
Open source software that lets Linux and Unix systems share files using the Windows SMB protocol.
SAS
Serial Attached SCSI, a storage interface often used for enterprise hard drives and controllers.
SATA
Serial ATA, a common storage interface for consumer hard drives and SSDs.
scrub
A background process that reads stored data and checks it against checksums to detect and repair corruption.
smartmontools
A set of utilities for reading SMART data, running tests, and monitoring storage drives.
SnapRAID
A snapshot-parity tool for protecting mostly static collections of files across multiple disks.
Synology
A company that sells consumer and small-business NAS appliances with its own management software.
TRIM
A command that lets an operating system tell an SSD which blocks are no longer in use, helping performance and lifespan.
Unraid
A commercial home server operating system focused on flexible disk usage, containers, and easy management.
XFS
A high-performance Linux filesystem commonly used on servers.
ZFS
A combined filesystem and volume manager designed for data integrity, snapshots, replication, and pooled storage.

Reference links

ZFS myths, behavior, and documentation

Secure boot and Linux image design

  • Fitting Everything Together
    Used to explain a measured and signed Linux boot chain with UKI, dm-verity, and TPM-backed unlock.
  • ParticleOS
    Given as a project that experiments with the kind of secure image-based Linux design described above.
  • Frood
    Mentioned as inspiration for image-based home server and NAS setups.

DIY NAS build references

Shopping and hardware references

File sharing and client compatibility

Operating system alternatives

  • Rocky Linux
    Suggested as a free RHEL-compatible base for a stable NAS with Cockpit.