TrueNAS Storage Planning: Pools, Datasets and Shares

TrueNAS is a storage appliance operating system built on Linux, with OpenZFS acting as both the filesystem and the volume manager. Most of the decisions made in the first hour of a deployment are the ones that are expensive to reverse, so it helps to understand the layers before running through the setup wizard.

A note on the name

Guides written before 2025 call this product TrueNAS SCALE, to distinguish the Linux version from the FreeBSD-based TrueNAS CORE. That distinction ended with TrueNAS 25.04 “Fangtooth”, which merged both lines into a single Linux product published as TrueNAS Community Edition. Current releases are simply TrueNAS, and 25.10 “Goldeye” is the version the software status page recommends for general users.

Everything below applies to both, because the storage layering has not changed. The parts that did change are on the app side, and are covered in moving apps from k3s to Docker, along with a full version map.

The boot device is separate from your data

TrueNAS installs to its own boot device. The disks that hold your data are never part of that install. This separation is deliberate: the appliance keeps its configuration in an exportable file, so a failed boot device is recovered by reinstalling and importing that configuration, then importing the existing pool. Export a copy of the configuration to somewhere off the machine, and do it again after any significant change.

Pools are built from vdevs, and vdevs set the rules

A pool is made of one or more virtual devices, called vdevs. Redundancy belongs to the vdev, not to the pool. A vdev can be a mirror, or a RAIDZ group carrying one, two or three parity disks. The pool stripes data across all of its vdevs, which means the pool lives only as long as every vdev in it survives. Losing one vdev loses the whole pool, including data that physically sat on healthy disks.

That single fact drives the layout choice. Mirrors give the highest random IOPS per disk and the shortest rebuild, at the cost of usable capacity. Wider RAIDZ groups give more usable capacity per parity disk but put more data behind one redundancy group and take longer to resilver, which lengthens the window in which a second failure is fatal. Pick the shape before creating the pool rather than after.

Vdev shape	Usable capacity	Rebuild time	Best suited to
Two-way mirror	50% of raw	Shortest	Virtual machine disks, iSCSI, databases
Three-way mirror	33% of raw	Shortest	Data where a second failure during rebuild is unacceptable
RAIDZ1	Raw minus one disk per group	Long	Small groups of small disks, replaceable data
RAIDZ2	Raw minus two disks per group	Long	General bulk storage, the common default
RAIDZ3	Raw minus three disks per group	Longest	Wide groups of large disks, archival pools

The controller in front of those disks matters as much as their arrangement, because a RAID card that hides disk state prevents ZFS from managing redundancy at all. That constraint, and the memory the pool will want alongside it, are covered in TrueNAS hardware sizing.

Datasets are where the properties live

Inside a pool you create datasets. A dataset is a mount point and a boundary for properties: compression, record size, quotas, snapshot schedules and the access control model. Split datasets by workload instead of creating one dataset for everything. Bulk media, virtual machine disks, database files and backup targets all have different write patterns.

Record size matters here because it applies to newly written data only. Changing it later does not rewrite blocks that already exist. The same applies to several other properties, so the cheapest time to get them right is before the data lands.

Snapshots are per dataset and cost almost nothing at creation, growing only as live data diverges from the snapshot point. They are not backups, because they sit in the same pool as the data they protect. Replicating them to a second system is what turns them into a backup.

The sharing protocol decides the permission model

SMB, NFS and iSCSI are different models rather than interchangeable front ends. SMB works with user accounts and NFSv4 style ACLs. NFS exports lean on host based trust and POSIX permissions. iSCSI hands the client a raw block device, and the client owns the filesystem on top of it. Presenting one dataset over several protocols at once is a reliable way to create permission problems that are hard to unpick. Choose one primary protocol per dataset.

Note what is not on that list. TrueNAS shares datasets, not devices, and its Samba configuration is generated by the appliance rather than hand-edited. Anything that shares hardware rather than storage, a printer being the usual example, is a container app rather than a share type.

Before you load real data

Confirm that scrubs and disk self tests are scheduled, that alert notifications reach somewhere you actually read, and that you have restored a file from a snapshot at least once. A recovery path you have never exercised is an assumption, not a plan.

Where to go next

• Sizing the machine itself: memory by drive count, controller firmware mode and network interface choice in TrueNAS hardware sizing.
• Running services alongside storage: what changed when the app backend moved from k3s to Docker.
• A worked custom-app example, including storage and networking choices, in running CUPS as an app.
• A rough memory and throughput estimate for a planned configuration, from the TrueNAS sizer.