Expanding a TrueNAS Pool: Your Three Real Options (Including RAIDZ Expansion)

You filled the pool sooner than you expected. Or you bought 4 TB drives two years ago and 16 TB drives are now the same price. Either way, you want more usable space without rebuilding from scratch and restoring from backup. Good news: TrueNAS gives you three legitimate ways to do this, and a couple of dead ends to avoid. Bad news: each path has trade-offs that aren’t obvious until you’ve committed, and the right answer depends on your current pool layout.

This guide walks through the three real options — adding a vdev, replacing drives one at a time, and the newer RAIDZ expansion feature — and how to pick.

First: the rule that decides everything

ZFS pools are made of vdevs, and the topology of a vdev is largely fixed once created. You cannot, for example, convert a RAIDZ1 into a RAIDZ2, and you cannot remove a RAIDZ vdev from a pool. The expansion strategies below all work within those constraints. If you got the original RAIDZ vs mirrors choice wrong for your future needs, no amount of expansion will fix that — only a destroy-and-restore will.

So before you pick an expansion strategy, look at what you have now and decide whether you’re trying to grow the existing vdev or grow the pool by adding a new vdev.

Option 1: Add a new vdev to the pool

The classic ZFS expansion path. Your pool already has, say, one 6-disk RAIDZ2 vdev. You add a second 6-disk RAIDZ2 vdev to the pool, and the pool’s usable space roughly doubles. Writes stripe across both vdevs from that point on.

When this is the right call:

• You have physical bays and budget for a full vdev worth of new drives (typically 4–8 drives).
• You want the simplest, fastest, lowest-risk expansion.
• You’re fine with the operational note below.

The operational notes that matter:

• Every vdev added to a pool is a single point of failure for the pool. If a vdev dies (more drives fail than its parity tolerates), the entire pool is gone — both vdevs. Practically this means the new vdev should match or exceed the redundancy level of the existing one. Don’t add a single-drive vdev or a 2-wide mirror to a pool whose existing vdev is a 6-wide RAIDZ2; you’d be making the whole pool’s redundancy as weak as the weakest vdev.
• Existing data does not rebalance. Old data stays on the old vdev; new writes prefer the emptier (new) vdev for a while, then balance out. The pool isn’t “broken,” but if you want existing data spread across both vdevs you have to rewrite it (see “rebalancing” later).

This is the cleanest path when you have the bay count. It’s a single zpool add operation in concept, fully online, and the new space is available immediately.

Option 2: Replace drives one at a time with larger ones

For a homelab pool that has no spare bays but where larger drives have become affordable, this is often the right move. ZFS lets you replace the disks in a vdev one at a time with larger ones; once every disk in the vdev has been replaced (and autoexpand=on is set, or you run a manual expand), the vdev’s usable size grows to the smallest new disk.

The process, in concept:

1. Set autoexpand=on on the pool (so the vdev auto-grows once all members are bigger).
2. Offline one drive, physically replace it with the larger drive, run a resilver (zpool replace), wait for it to finish.
3. Repeat for every drive in the vdev.
4. After the last replace + resilver, the vdev expands to the new size.

When this is the right call:

• You’re stuck with the bay count you have.
• The price-per-TB on bigger drives has dropped enough that doubling capacity per drive makes sense.
• You can afford the time (one resilver per drive — could be many days end-to-end on large pools).

The hard part: resilver risk. Replacing one drive at a time in a RAIDZ1 vdev means that during the resilver, you have no redundancy until it completes. A second drive failing mid-resilver loses the pool. For RAIDZ2/Z3 you still have parity to spare during a single replace, which is one of the reasons RAIDZ2 is the modern home default for wider vdevs. If you’re on RAIDZ1 with old drives, consider this risk seriously — and have a verified snapshot/replication backup before you begin.

Option 3: RAIDZ expansion (OpenZFS 2.3+, TrueNAS Fangtooth)

This is the new option, and it changes the playbook. RAIDZ expansion lets you add a single drive to an existing RAIDZ vdev, widening it. So a 4-wide RAIDZ2 becomes a 5-wide RAIDZ2 by adding one drive — not a whole new vdev.

The feature shipped in OpenZFS 2.3.0 and is included in TrueNAS 25.04 (“Fangtooth”), per the TrueNAS release announcement. (TrueNAS ↗)

What it does well:

• Lets you grow a RAIDZ vdev one drive at a time — useful when you only have one free bay or only one drive of budget.
• Works on all parity levels (Z1, Z2, Z3).
• Pool stays online and fault-tolerant during the expansion, and the operation resumes after an interruption like a reboot. (The Register ↗)

What it does not do — read this part twice:

• Existing data keeps its old parity ratio. If you expand a 4-wide RAIDZ2 to a 5-wide RAIDZ2, the blocks that were already on the pool are still laid out as if they were on a 4-wide vdev. You only see the improved space efficiency for newly written data. To reclaim that space on old data, you have to rewrite it — typically with zfs send | zfs receive to another dataset, or file-level copy and delete. (OpenZFS GitHub Discussion #15232 ↗)
• You cannot change parity level. RAIDZ1 stays RAIDZ1, RAIDZ2 stays RAIDZ2. Expansion adds width, not redundancy.
• It’s slow. Expansion is bound by CPU more than IO and only adds one drive at a time, so growing a wide vdev is days of work per drive.
• Once expansion is “active” on the pool’s feature flags, you can’t downgrade to an older OpenZFS version. Plan for that one-way door.

When this is the right call:

• You have one free bay (or one drive of budget) and want more capacity without committing to a whole-new-vdev purchase.
• You’re already on TrueNAS Fangtooth (25.04) or later, or on a community ZFS distro shipping OpenZFS 2.3+.
• You’re comfortable with the parity-ratio caveat and either plan to do a rewrite pass afterwards or accept that old data won’t benefit from the new geometry.

If you only have one bay free and you’re staying on TrueNAS Electric Eel or earlier (no 2.3), Option 2 (drive-by-drive replace) remains your move.

What about removing a vdev?

A real limitation worth naming: you cannot remove a RAIDZ vdev from a pool. Mirror vdevs can be removed in some cases (top-level mirror vdev removal is supported with restrictions), but if your pool has any RAIDZ vdev in it, you’re locked into that topology until you destroy and recreate the pool. This is the main reason “just add a junk vdev for now” is a bad strategy — that junk vdev is forever, as far as the pool is concerned.

If your situation calls for a different topology than you have, accept that you’ll need to back up, destroy, recreate, and restore. See snapshot replication for how to do that with minimal downtime.

Rebalancing after expansion

Both adding a vdev and RAIDZ expansion leave existing data sitting in its old layout. ZFS does not have an automatic “spread the data out” operation. The practical rebalance methods:

• Per-dataset replication trick: snapshot a dataset, zfs send it to a new dataset on the same pool, swap mountpoints, destroy the old one. The new dataset’s data is written fresh and will spread across the current vdev layout (and pick up the new parity ratio on a freshly expanded RAIDZ).
• File-level rewrite: copy files to a new location, delete originals. Crude but works for small datasets.
• Just live with it: for many home pools the imbalance is harmless. New writes will gradually equalize the vdevs, and old data sitting in its old layout doesn’t hurt anything but space efficiency.

There’s a community-maintained zfs-inplace-rebalancing script that automates the file-level rewrite if you want to push the issue, but it’s not a built-in TrueNAS feature.

Quick decision tree

• Have spare bays for a full new vdev’s worth of drives? Add a new vdev (Option 1). Simplest, fastest, best.
• Out of bays, but bigger drives are now affordable? Replace drives one at a time (Option 2). Slow but works on any TrueNAS version.
• One free bay, on TrueNAS Fangtooth or newer, and willing to accept old-data parity-ratio caveats? RAIDZ expansion (Option 3).
• Need to change topology (RAIDZ1 to RAIDZ2, mirrors to RAIDZ, etc.)? Back up, destroy, recreate, restore. There is no in-place path.

A note on planning the next pool

Most expansion pain comes from a pool that was sized assuming “I’ll never need more than X.” Next time, pick a vdev topology and bay count that gives you a realistic upgrade path: a case with extra bays for a future vdev, or wide-enough RAIDZ2 that drive-by-drive replacement is viable. And keep scrubs and SMART tight so when you do start replacing drives, you’re not discovering surprises mid-resilver.

Next steps

• ZFS Pool Design: RAIDZ vs Mirrors — get the topology right the first time.
• TrueNAS Snapshot and Replication Strategy — the verified backup you want before any expansion operation.
• The TrueNAS Hardware Guide — including HBA choice when you outgrow your motherboard’s SATA ports.

See also

• Docker homelab tutorials ↗
• Minilab and small-footprint homelab builds ↗