TrueNAS SCALE: Installing It Is Easy, Planning the Pool Is the Hard Part

Once I'd bought all four 4TB drives, I spent more time planning the storage pool than installing the OS. ZFS is unforgiving: once the vdev layout is baked in, changing it usually means a full migration. Before I clicked "next" on the SCALE installer, I turned "what am I willing to lose if a drive dies" into arithmetic, not vibes.

Boot drive and data pool: split them before you lay anything out

CORE runs on FreeBSD and its plugin ecosystem is aging; SCALE runs on Debian and handles containers and K3s more naturally. I picked SCALE because I already live in Docker at home and didn't want to learn a second set of jails. This box's job is storage; apps live on Proxmox and my small host. Clear boundaries mean fewer arguments.

The OS sits on one small SSD; the data pool is exactly those four 4TB drives. Don't mix the system and the media library in one pool — a reinstall shouldn't threaten your photos. The pool is named tank, and every calculation below revolves around it.

A "4TB" drive gets quoted two ways, and the gap is real. By marketing math, 4×4 = 16TB raw; in GiB, you typically get around 3.64TiB per drive. I'll use the rough TB numbers here so they line up with your shopping receipt — once the pool actually exists, zpool list is the source of truth.

Three layouts: capacity, fault tolerance, and the expansion path, counted together

Option A: two mirrors, striped (RAID10 shape)

Fault tolerance: one drive can die in each mirror and you still read; losing two drives in the same mirror is the fatal case
Rough usable: about 8TB (half goes to mirroring)
Resilver: only the surviving drive in the pair gets read, so rebuilds are comparatively short and put less stress on the disks
Expansion: buy two more drives later, add a mirror pair to the pool — I can explain that path clearly

Option B: RAIDZ1 (like RAID5)

Fault tolerance: the whole pool survives only 1 drive failure
Rough usable: about 12TB (three data + one parity, intuitively)
Resilver: nearly every surviving byte gets read, so it takes a long time, and losing one more drive in that window can wipe everything
Buying one batch of drives at once, "the second one dies during resilver" isn't a campfire story

Option C: RAIDZ2

Fault tolerance: survives 2 drives
Rough usable: about 8TB, close to Option A
Expansion semantics differ from a mirrored stripe: a RAIDZ vdev's width is fixed, so you can't just "add one more drive"
With four drives, RAIDZ2 trades flexibility for double-drive fault tolerance

I went with Option A. The reason is unglamorous: photos and documents are worth more than "an extra 4TB"; resilver is a smaller mental burden; and when I add drives later, I can add another mirror pair — the expansion path is written down in my notes and executes cleanly. If you prioritize capacity, Option B is defensible, but budget for the psychological cost of that rebuild window and keep a hot spare or a same-model cold spare.

Before deciding, I ran the numbers through a table three times and simulated "buying two more drives next year." Once the digits are on the table, arguments shrink: it's not about who's loudest, it's about who wrote down usable capacity and the drive-loss scenarios in full.

The comparison table is taped to the inside of my case:

Layout	Rough usable	Simultaneous drive loss	Expansion intuition
2×mirror stripe	~8TB	1 per mirror	Add a mirror pair
RAIDZ1	~12TB	1 drive	Whole vdev is hard to shrink or rework
RAIDZ2	~8TB	2 drives	Same as left; double parity feels safer

Drive failure isn't probability zero: how I set my own SLA

Home drives don't have an enterprise array's monitoring team. My goals for myself:

Single drive failure: services go read-only or briefly slow, no data loss
Both drives in a mirror failing: "restore from off-site backup" is acceptable, "this was the only copy" is not
Accidental deletion: recovered within hours from snapshots, not by hoping a weekly full-disk copy happens to catch it

So snapshots and off-site backups are the other half of the arithmetic. Local redundancy handles hardware; snapshots handle fat fingers; off-site handles fire and ransomware. Skip any one of the three and you're relying on luck.

Some people think home storage doesn't deserve a service level. I wrote mine anyway — not for a boss, but for my future panicked self. When you're panicking, numbers beat slogans.

Datasets split by "how much would losing this hurt," not by mood

After the pool was built, I split it into these datasets:

tank/media: movies and TV; compression off or lz4, sparse snapshots
tank/photos: Immich originals; dense snapshots
tank/backup: landing zone for backups from other machines
tank/apps: for app data, in the rare case something must run on SCALE

Permissions and quotas split cleanly by dataset, which beats smearing Linux ACLs across one directory. NFS/SMB shares also export per dataset, so I never end up with one mega-share where quota and snapshot granularity spiral out of control.

Example snapshot policy (still arithmetic: retention count × change rate ≈ snapshot footprint):

photos: keep 24 hourly, 14 daily, 6 monthly
media: 7 daily is enough

Scrub runs monthly, staggered away from the full-disk backup window. Email or Telegram gets wired up: disk errors, degraded pool, scrub finding checksum errors — those three must get a response. And a snapshot is not a backup — if the house burns down it saves nothing; only an off-site restic/cloud copy closes the loop.

Migration and drive replacement: turn unknowns into rehearsed numbers

My old NAS was a single-disk ext4 box. I migrated with rsync -aHAX --info=progress2 into the new dataset, then spot-checked file hashes afterward. The first scrub of a big library takes a while, so don't schedule a full-disk backup the same day and saturate the bus.

Walk through TrueNAS's drive replacement once yourself — on a blank box or in a VM: offline → replace → resilver → confirm status. Note roughly how long resilver takes; that's your budget for "how much spare time I need the week a drive dies." "I know how to click through it" without ever having rehearsed it is the same as not being prepared.

SCALE can run apps, but I keep the heavy apps on other machines; SCALE focuses on NFS/SMB/snapshots. The fatter a storage node gets, the scarier upgrades and reboots become. A single-purpose pool helps me sleep better than an all-in-one wonder box.

The pool structure goes into my notes: drive serial numbers, vdev layout, scrub day, snapshot policy, and the rough-usable-vs-real zpool list comparison. That's worth more than any "enterprise-grade" adjective.