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
| Pool | Layout | Purpose |
|---|---|---|
boot-pool | One 500 GB NVMe device | TrueNAS SCALE operating system |
data-pool | Three two-disk mirror vdevs | Shared 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 purpose | Notes |
|---|---|
| Movies | Largest media collection |
| Television | Episodic video library |
| Music | Music collection |
| Audiobooks | Spoken-word library |
| E-books | Reading library |
| Personal photos and video | Irreplaceable personal media |
| Documents and private vault | Records and document-management inputs |
| Personal home data | User-oriented files |
| Software archive | Installers and retained software |
| Video surveillance | NVR-managed recordings |
| Virtual-machine data | VM-related storage |
| Backups | Application and system recovery material |
| Downloads, torrents, and uploads | Staging and transfer areas |
| Web-log files | Assets 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.