The Cheapest NAS

Original Article ↗ Hacker News Discussion ↗

Building the “cheapest NAS” with a tiny ARM single-board computer and USB drive prompts broader debate over what actually matters for home storage: raw cost, power efficiency, or long‑term data integrity. Commenters weigh the trade-offs between low-end SBC-based setups and used small-form-factor PCs or commercial boxes like Synology, arguing about network speed limits, ZFS without ECC RAM, and how much redundancy is “enough” for personal data. Many emphasize that backup strategy (second NAS, offline disks, or cloud storage) and ease of remote access via tools like Tailscale or WireGuard often matter more than squeezing out the lowest possible hardware price.

Hardware choices for a “cheapest NAS”

  • Many argue SBC-based NAS is fine but fiddly; others prefer used small form factor PCs (Dell/HP/Lenovo/NUC/thin clients) as more expandable, better supported, and often very cheap on the used market.
  • Ex-corporate SFF desktops and thin clients are highlighted as sweet spots: $40–$200, low idle power, good connectivity, often enough for 1–2 drives plus NVMe.
  • Some recommend dedicated NAS appliances (Synology/QNAP/TerraMaster) for people who value ease, monitoring, and vendor support over DIY savings.
  • USB enclosures and DAS are discussed; reliability depends heavily on the USB–SATA bridge quality, and some brands are reported as failure-prone.

Performance, networking, and small files

  • Several say 100 Mbps Ethernet is a real bottleneck; gigabit or 2.5 Gbps is preferred, especially for small-file workloads and Time Machine-like backups.
  • Small files are dominated by latency, where faster links help even when bandwidth isn’t saturated.

ECC RAM, ZFS, and data integrity

  • Strong debate over ECC:
    • One side: ECC is essential for any important data, especially with ZFS, to prevent RAM bit-flips corrupting on-disk data and checksums. Real anecdotes of silent corruption and bad memory are cited.
    • Other side: many have run ZFS/non-ECC for years without noticed issues; risks may be overstated for home use and most data (e.g., media) is not critical.
  • Point made that backups solve different problems than ECC; silent corruption can propagate into all backups if not detected by checksums/scrubbing.

Backup strategies and cost

  • For large home NASes (e.g., 28 TB), cloud backup is often expensive.
  • Options discussed: B2, Wasabi, Glacier/Deep Archive, rsync.net, Interserver+borg, Storj, Hetzner storage boxes.
  • Many conclude that for multi‑10‑TB datasets, a second NAS/backup server in another location is often more economical.
  • Some use low‑tech rotation of external drives or a friend’s house NAS as offsite.

Access protocols and remote access

  • Common local protocols: SMB/CIFS and NFS; also SFTP/SSHFS, WebDAV, Seafile, Syncthing.
  • Remote access typically via VPN: Tailscale, WireGuard, ZeroTier, sometimes OpenVPN or Tor.
  • Opinion that VPN is safer than exposing NAS ports directly; some rely on vendor “QuickConnect”-style relay services.

NAS vs just putting disks in PCs

  • Some argue home “NAS” is cargo cult: often simpler and cheaper to put disks in existing desktops/laptops and share over the network.
  • Counterpoints:
    • Laptops/phones/tablets dominate; they can’t easily host lots of disks.
    • Dedicated NAS avoids noise, uptime interruptions, and desktop reboots, and centralizes services like Plex, Docker apps, or Time Machine.

Expandability and storage layouts

  • People ask for NAS systems where redundancy automatically adjusts as disks are added/removed; closest suggestions include Unraid, mergerfs+SnapRAID, Windows Storage Spaces, Greyhole.
  • Note that automatic transition from mirrored to non‑mirrored as disks fill is generally seen as undesirable for anyone who truly cares about redundancy.

Power, reliability, and “cheap vs good”

  • Low idle power is a recurring goal; SBCs and some mini‑PCs/NUCs can idle under ~10 W, but used desktops may be 20–50 W.
  • Some emphasize that “cheapest” often ignores costs of power, time spent debugging flaky USB/SBC setups, and the higher risk of data loss without redundancy or robust hardware.