MODDA.se
GuidesNASDIYStorageZFSUnraidTrueNASProxmoxMergerFSSnapRAIDHardwareHomelab

Building a Custom NAS: Operating Systems, Drive Mixing, and the Real Math of Usable Capacity

27 juni 2026

For DIY enthusiasts, building a Network Attached Storage (NAS) server is a true rite of passage. Moving away from locked-down commercial enclosures opens up endless possibilities for hardware customization, virtualization, and massive cost savings per terabyte. However, selecting the right operating system and underlying storage architecture is a critical decision that dictates your system's expansion options, data safety, and total upfront cost.

This comprehensive guide breaks down the core NAS solutions favored by the homelab community, dissects the financial realities of licensing versus hardware overhead, explains how drive mixing works across different platforms, and runs real-world math on how much usable storage you actually get.

1. The NAS Software Landscape: Pricing & Philosophy

The home server ecosystem generally divides into two paradigms: Turnkey Appliances that handle management via polished web dashboards, and DIY Linux Configurations that prioritize granular control and lower system overhead.

  • TrueNAS Scale: Free & Open Source (Community Edition). The gold standard for data integrity and speed via ZFS. Recent architectural shifts toward native Docker Compose have solidified its status for app hosting, though ZFS layout rules remain rigid.
  • Unraid: Paid Tiered License (Starter: ~$49, Unleashed: ~$109, Lifetime: ~$249). The ultimate "media hoarder" OS. Hugely popular because it allows unmatched flexibility in mixing mismatched drives and features an incredibly mature, painless application template system.
  • OpenMediaVault (OMV): Free & Open Source. A highly efficient web GUI layered directly over native Debian. Perfect for low-power setups, older office PCs, or single-board computers where minimal resource overhead is a strict requirement.
  • MergerFS + SnapRAID: Free & Open Source. The ultimate DIY combination for pure storage efficiency. Drives can spin down independently to conserve energy, making it a favorite for massive, cold-storage media libraries.
  • Proxmox VE (as Base): Free & Open Source (Optional paid support). An increasingly dominant approach. Users install Proxmox on bare metal to manage ZFS pools directly, then deploy lightweight Linux Containers (LXCs) or VMs to share out network protocols (SMB/NFS).

2. The Drive Mixing Conundrum: Can You Combine Sizes?

One of the largest hidden expenses in building a NAS is the long-term cost of adding storage. Can you grab whatever hard drive is currently on sale, or are you locked into buying identical drives forever?

ZFS (TrueNAS Scale / Proxmox / Ubuntu)

ZFS organizes drives into Virtual Devices (VDEVs). If you create a RAID-Z1 or RAID-Z2 VDEV using a mix of drive capacities, ZFS automatically throttles all drives to match the capacity of the smallest disk in that VDEV. The extra space on larger drives is completely wasted.

ZFS Exception Rule: To safely expand or use different sizes in ZFS, you must either create entirely separate VDEVs (e.g., a VDEV of 14TB drives mirrored alongside a VDEV of 18TB drives) or replace every single drive in an existing VDEV one-by-one with a larger size, allowing the pool to expand only after the final drive is replaced.

Unraid

Unraid offers absolute freedom. You can mix 4TB, 14TB, and 18TB drives seamlessly. The only strict rule is that the parity drive(s) must be equal to or larger than the largest data drive in the array. If your biggest data drive is 18TB, your parity drive must be at least 18TB.

MergerFS + SnapRAID (Perfect Media Server)

Similar to Unraid, MergerFS simply aggregates independent underlying file systems into a single virtual mount point, completely ignoring drive size. SnapRAID handles parity asynchronously. The rule mirrors Unraid: your SnapRAID parity drive must be at least as large as the largest data drive in the pool.

3. Usable Storage Math: Real-World Scenarios

To see how your choice of architecture directly impacts your wallet and space efficiency, let us calculate the exact usable storage yielded by a common real-world scenario.

The Test Bench Drive Collection:

  • 3 × 14TB Drives
  • 2 × 18TB Drives
  • Total Raw Capacity: (3 × 14) + (2 × 18) = 42 + 36 = 78 TB

Scenario A: Unraid (Dual Parity)

Unraid requires the two largest drives to act as parity. Thus, the two 18TB drives become parity disks. The remaining three 14TB drives form the data array.

  • Parity Drives: 2 × 18TB (Consumed for parity)
  • Data Drives: 3 × 14TB
  • Usable Storage Calculation: 14TB + 14TB + 14TB = 42 TB
  • Result: 42.00 TB usable (Efficiency: 53.8%)

Scenario B: MergerFS + SnapRAID (Single Parity)

SnapRAID requires one parity drive to protect against a single disk failure, which must be chosen from the largest available size (18TB). This leaves one 18TB drive and three 14TB drives for data pooling.

  • Parity Drive: 1 × 18TB (Consumed for parity)
  • Data Drives: 1 × 18TB + 3 × 14TB
  • Usable Storage Calculation: 18TB + 14TB + 14TB + 14TB = 60 TB
  • Result: 60.00 TB usable (Efficiency: 76.9%)

Scenario C: ZFS RAID-Z2 (Dual Parity VDEV)

If you force all five drives into a single RAID-Z2 VDEV, ZFS applies its lowest-common-denominator rule. Every drive is treated as a 14TB drive. The 4TB of extra space on each of the two 18TB drives (8TB total) is permanently lost.

  • Effective Drive Capacity: 5 × 14TB = 70TB Virtual Raw Space
  • Parity Deductions: 2 Drives worth of space (2 × 14TB = 28TB)
  • Usable Storage Calculation: 70TB - 28TB = 42 TB
  • Wasted Capacity: 2 × (18TB - 14TB) = 8 TB
  • Result: 42.00 TB usable (Efficiency: 53.8% | 8TB Wasted)

4. The Nuance of Native ZFS on Ubuntu & Debian

Many builders look to skip a dedicated storage OS altogether, pointing out that Ubuntu Server packs native, integrated OpenZFS support (zfsutils-linux). While functionally excellent, homelabbers emphasize several trade-offs:

  • The UI Gap: Pure Ubuntu requires executing all administrative actions via the CLI (e.g., zpool status, zfs set compression=lz4). For visual status indicators or disk failure alerts, users generally layer on Cockpit alongside the community-developed cockpit-zfs-manager plugin.
  • Package Freshness: Ubuntu Long Term Support (LTS) releases tie their OpenZFS versions to the native kernel shipping at launch. Cutting-edge ZFS improvements, such as the highly anticipated block cloning mechanisms and native RAID-Z expansion options, often drop much faster in rolling distributions or specialized storage platforms like TrueNAS Scale.
  • System Bloat: The homelab community frequently favors a minimal Debian Stable install over Ubuntu for pure storage nodes, citing a preference for avoiding pre-installed snap frameworks (snapd) and ensuring maximum system predictability.

5. Core Takeaways for the DIY Builder

If you are looking to deploy a machine immediately, use these operational profiles to match your storage architecture to your hardware availability:

  • Choose Unraid or MergerFS+SnapRAID if: You are actively recycling old internal drives of random capacities, your data growth pattern involves adding one single disk at a time, and your primary workload is media streaming where ultimate IOPS performance is not required.
  • Choose TrueNAS Scale or Proxmox+ZFS if: You can afford to buy uniform hard drives upfront, your network environment supports 10GbE+ transfer speeds, data self-healing against silent corruption is an absolute priority, and you intend to host heavy database applications or high-performance virtual machine backends.
Diskutera artikeln i forumet