What’s up guys — welcome (or welcome back) to the blog. Storage sits at the center of everything we build. No matter how advanced your environment gets — containers, VMs, apps, backups — none of it works without solid storage underneath. And TrueNAS SCALE, with all the updates and extra features they’re pushing, is still one of the best open-source storage platforms you can start with.
So, in this deep-dive series, we’re going to slow things down, break everything apart, and really understand how TrueNAS SCALE handles storage, starting with disks and pools.
Before We Dive In
I’m skipping the installation walkthrough here because I already made a separate video covering that step-by-step. If you need it, you can check out my blog on installing TrueNAS on the AOOSTAR WTR PRO.
And if you're reading this on my site or following along on the channel, hit subscribe, drop a comment, and say hi — I promise I don’t bite. I love hearing about what you’re building.
The Test Device
For this series, I’m using the TerraMaster F4-425 Plus as the “guinea pig.” It’s a simple setup: the OS is installed on a mirrored pair of SSDs/NVMes, I’ve added a few larger HDDs for bulk storage, and the system has enough RAM to comfortably test everything. None of this affects how TrueNAS behaves, though — SCALE works the same whether you're running it on a small NAS box, a repurposed server, or a full rackmount in your homelab. I’m keeping things general so this guide applies to whatever setup you’re building.
Where Storage Begins: Disks
In TrueNAS SCALE, disks are the raw building blocks, and every storage pool starts with them. A disk can be an HDD, SSD, NVMe, or basically anything TrueNAS recognizes as block storage. Since TrueNAS uses ZFS — which is a file system, volume manager, and integrity engine wrapped into one — the platform is incredibly powerful.
When you open the Disks menu, you’ll see your drives listed with options to edit them, wipe them, or view details like serial numbers, sizes, and temperatures. Two settings matter the most: HDD Standby and Advanced Power Management (APM).
HDD Standby controls how long a disk stays idle before spinning down. It can help reduce noise or power usage, but most 24/7 setups keep it disabled because constant spin-up and spin-down can shorten a drive’s lifespan. APM determines how aggressively a drive should save power. Some drives respect it, others ignore it, and a few get noisy when it’s enabled. Most server and homelab environments leave it off unless there’s a very specific need for power savings.
Wiping a Disk
Before adding a disk to a pool, especially if it came from another system, wiping it first is a good idea. TrueNAS gives you three levels of wipe: Quick, which removes partition tables and metadata; Full with zeros, which overwrites every sector; and Full with random data, which provides stronger data destruction for sensitive environments. For new or test drives, a Quick wipe is usually plenty.
Storage Pools: The Foundation of Everything
A storage pool is where all your data ultimately lives. You can think of it as the container ZFS manages. To create a pool, you start with your physical disks, group them into vdevs, and ZFS uses those vdevs to form the actual pool.
Understanding VDEVs
A vdev (virtual device) is a group of disks that provide redundancy and performance. Your pool can contain one or more vdevs, but the key rule is that a pool is only as strong as its weakest vdev. If one vdev fails, the entire pool fails — even if the others are perfectly fine. This is why you never mix strong layouts (like RAIDZ2) with weak ones (like a Stripe). TrueNAS will even gray out incompatible options to prevent bad combinations.
VDEV Layout Options
Here’s a quick and clear explanation of each layout.
- A Stripe uses all disks as one large volume with zero redundancy. It’s fast but extremely risky because a single disk failure destroys everything.
- A Mirror stores a copy of the data on each disk in the mirror, typically using two or more drives. It offers great read performance and can survive one or more disk failures depending on how many mirrors you create.
- RAIDZ1 provides one disk’s worth of parity, requires at least three disks, and can survive a single disk failure.
- RAIDZ2 offers two disks of parity, needs at least four disks, and can survive two failures.
- RAIDZ3 provides three disks of parity, requires at least five disks, and can survive three failures.
- And then there’s DRAID, a newer distributed RAID format built primarily for large-scale deployments. Most homelabs won’t use it, but it’s part of modern ZFS so it’s worth mentioning.
Exporting, Importing, and Destroying Pools
This is an area that can be confusing. Exporting (or disconnecting) a pool simply takes it offline without destroying the data, much like safely ejecting a USB drive. You might export a pool if you're migrating it to another TrueNAS system, reinstalling TrueNAS, or testing something risky.
When exporting, you’ll see options like “Destroy Data on Pool,” which wipes all the data, and “Delete Saved Configurations,” which removes dataset and share settings stored in TrueNAS but not the data itself. TrueNAS also asks you to confirm the export because accidentally destroying a pool is a nightmare. Once exported, a pool can be re-imported any time — unless you chose to destroy it, in which case the data is gone and the disks return to the unused list.
Final Thoughts
To keep this guide (and the video) from dragging on, we’re stopping here and calling this Part 1. We covered disks, pool creation, vdevs, redundancy layouts, expanding and removing vdevs, and how exporting or destroying pools works.
Part 2 will dive into datasets and shares — how they work, how to organize them, and how to build a clean, scalable storage structure. If you enjoyed this, drop a comment, say hi, or ask a question — I respond to as many as I can. As always: stay geeking, stay curious. I'll See you in Part 2.
