Skip to content
Storage

Storage

TrueNAS SCALE provides centralized storage for personal files, media, application data, and backups. The server separates its operating-system pool from the six-disk data pool.

Pool layout

PoolLayoutPurpose
boot-poolOne 500 GB NVMe deviceTrueNAS SCALE operating system
data-poolThree two-disk mirror vdevsShared datasets and durable data

The data pool is a stripe across two 12 TB mirrors and one 8 TB mirror. Each mirror contributes the capacity of one member, for approximately 32 TB nominal capacity before ZFS metadata, unit conversion, snapshots, and free-space reserve.

    flowchart TB
  truenas["TrueNAS SCALE"]
  boot[("boot-pool")]
  nvme["500 GB NVMe"]
  data[("data-pool<br/>≈ 32 TB nominal")]

  subgraph mirrors["MIRRORED VDEVS"]
    direction LR
    subgraph m0["mirror-0 · 12 TB usable"]
      d0a["12 TB HDD"] --- d0b["12 TB HDD"]
    end
    subgraph m1["mirror-1 · 12 TB usable"]
      d1a["12 TB HDD"] --- d1b["12 TB HDD"]
    end
    subgraph m2["mirror-2 · 8 TB usable"]
      d2a["8 TB HDD"] --- d2b["8 TB HDD"]
    end
  end

  truenas --> boot --> nvme
  truenas --> data
  data --> d0a
  data --> d1a
  data --> d2a

  classDef platform fill:#182033,stroke:#778cc7,color:#dbe3ff;
  classDef pool fill:#10271e,stroke:#58b184,color:#c7efda;
  classDef disk fill:#282416,stroke:#c6a95b,color:#f2e4b8;
  class truenas platform;
  class boot,data pool;
  class nvme,d0a,d0b,d1a,d1b,d2a,d2b disk;
  

ZFS stripes allocations across the mirror vdevs while maintaining two copies within each mirror. The pool can survive one failed disk in every mirror simultaneously, but it cannot survive the loss of both members of any mirror.

Dataset organization

Separate datasets let different kinds of data have different snapshot, quota, sharing, permission, and backup policies.

Dataset purposeNotes
MoviesLargest media collection
TelevisionEpisodic video library
MusicMusic collection
AudiobooksSpoken-word library
E-booksReading library
Personal photos and videoIrreplaceable personal media
Documents and private vaultRecords and document-management inputs
Personal home dataUser-oriented files
Software archiveInstallers and retained software
Video surveillanceNVR-managed recordings
Virtual-machine dataVM-related storage
BackupsApplication and system recovery material
Downloads, torrents, and uploadsStaging and transfer areas
Web-log filesAssets and data used by the personal web log

Protection model

The mirror layout provides disk redundancy and ZFS checksums detect corruption. Regular scrubs read the pool and verify stored checksums. Important datasets are snapshotted at varying frequencies based on their rate of change and recovery needs, providing fast point-in-time recovery from accidental changes.

Those mechanisms all operate within the same storage system. They do not protect against deletion replicated into snapshots, administrative mistakes, theft, electrical damage, or loss of the complete machine. Important datasets therefore also need independent backup copies, with the most irreplaceable personal material receiving stricter treatment than replaceable media or download caches.

Important datasets are also copied manually to the external backup drive approximately once a month. This adds a second storage medium for that subset, although its limited capacity prevents it from mirroring the complete pool and its local location does not provide off-site disaster protection.