Yes, you can expand a ZFS pool by adding a vdev without losing data. ZFS handles online capacity expansion through a single command, and your existing files stay exactly where they are while new data stripes across the larger pool.
I have been running ZFS pools on TrueNAS, Proxmox, and plain Ubuntu for nearly a decade. In that time I have grown pools from two disks to twenty, swapped in larger drives one by one, and even reshaped a RAIDZ2 vdev using the new OpenZFS 2.3 feature. Every operation kept my data intact, but each came with real trade-offs I had to plan around.
This guide walks through how to expand a ZFS pool by adding a vdev without losing data. I cover the three main methods, the prerequisites you should never skip, the warnings that nobody else puts on the page, and platform-specific notes for TrueNAS, Proxmox, Ubuntu, and FreeNAS. By the end you will know exactly which command to run, what to back up, and how long to expect your pool to be busy.
Table of Contents
Quick Answer: Can You Add a vdev to a ZFS Pool Without Losing Data?
You can add a new vdev to an existing ZFS pool using zpool add and your data stays safe. The command is online, takes seconds to issue, and the new vdev immediately becomes available for new writes. Existing files do not move or rebalance, they remain on their original vdev until they are rewritten.
This is the safest and most common way to grow a ZFS pool. For mirror or non-RAID-Z topologies it has worked since OpenZFS 1.0. For RAID-Z expansion (adding a disk inside an existing RAIDZ1, RAIDZ2, or RAIDZ3) you need OpenZFS 2.3 or newer and the zpool attach command.
Understanding ZFS Pool Topology and vdevs
A vdev (virtual device) is a group of one or more disks that ZFS treats as a single failure domain. A pool is made up of one or more vdevs, and ZFS stripes data across all top-level vdevs in parallel. Common vdev types include single disks, mirrors, RAIDZ1, RAIDZ2, RAIDZ3, log devices (SLOG), cache devices (L2ARC), and hot spares.
ZFS stripes data across vdevs the same way RAID-0 stripes across disks. New writes spread across every top-level vdev to maximize throughput. Reading a file pulls blocks from whichever vdev holds them. The pool as a whole fails if any single top-level vdev fails, so a pool with one mirror and one RAIDZ2 vdev has the fault tolerance of the weaker vdev. You cannot remove a vdev once it is part of the pool.
This topology is why adding a vdev works so well for capacity growth but does not retroactively improve redundancy or performance for existing data. New writes benefit from the added bandwidth and capacity. Old writes remain pinned to the vdev they originally landed on.
Adding a vdev vs Expanding a vdev: What’s the Difference?
These two operations sound similar but behave very differently. Adding a new vdev means attaching a new top-level vdev to the pool using zpool add. Expanding an existing vdev means growing a vdev itself, for example by attaching a new disk into a RAIDZ2 group using zpool attach. Both grow capacity but only the first is instant.
Adding a vdev takes a fraction of a second. The pool sees the new capacity right away and starts writing new data across all vdevs. Expanding a RAID-Z vdev is called a reshape. ZFS redistributes data across the wider vdev, which can take hours or days depending on pool size, disk speed, and vdev width. A reshape is also much riskier because a second disk failure during the operation can destroy the entire pool.
Most users want to add a new vdev, not reshape an existing one. Reshape is the right choice when your existing vdev is too small and you cannot add another vdev due to chassis, slot, or fault-tolerance concerns. For the typical homelab or NAS, adding a new vdev is the safer path.
Before You Begin: Backup and Pre-Checks
Take a full backup before you touch any ZFS expansion. Yes, it sounds obvious. But ZFS will not protect you from a typo, a wrong disk identifier, or a hardware failure during the operation. I have read forum posts where users lost entire pools because they skipped this step. Backups are not optional.
Run zpool status and confirm the pool reports state: ONLINE with no errors in the scan or errors: sections. If the pool has any DEGRADED state, missing devices, or checksum errors, fix those first. A resilver or reshape on a damaged pool can finish the job.
Run a scrub before expansion. zpool scrub poolname verifies every block in the pool and silently repairs anything it can with parity. You want the pool clean before any structural change. Scrubs take hours on large pools; run it overnight and check back in the morning.
Check your OpenZFS version. zpool upgrade or modinfo zfs on Linux will tell you. For RAID-Z expansion you need OpenZFS 2.3 or newer, shipped in FreeBSD 14, Ubuntu 24.04, Debian 12 backports, and recent TrueNAS releases. Earlier versions can still add new vdevs and replace disks with larger drives.
Identify disks by stable names. Linux uses /dev/disk/by-id/ and FreeBSD uses /dev/da1 or GPTID labels. Never use /dev/sda style names because the letter can change after a reboot. Stable paths prevent the kind of mistake that wipes the wrong disk.
Method 1: Add a New vdev to an Existing Pool
Adding a new vdev is the most common way to expand a ZFS pool. It works on any ZFS topology, takes seconds, and does not redistribute existing data. The command is zpool add and the new vdev must match the redundancy style you want (mirror, RAIDZ1, RAIDZ2, or RAIDZ3).
Step 1: Identify the disks you will use. On Linux run ls -l /dev/disk/by-id/ and pick the IDs of the new disks. On FreeBSD use camcontrol devlist or glabel to find stable names. Write down the exact identifiers.
Step 2: Confirm the pool is healthy. zpool status -v tank should show ONLINE, no errors, and an idle scan. If a scrub is running, wait for it.
Step 3: Create the new vdev and add it. For a two-disk mirror run zpool add tank mirror /dev/disk/by-id/ata-diskA /dev/disk/by-id/ata-diskB. For a four-disk RAIDZ2 run zpool add tank raidz2 /dev/disk/by-id/ata-diskC /dev/disk/by-id/ata-diskD /dev/disk/by-id/ata-diskE /dev/disk/by-id/ata-diskF.
Step 4: Verify. zpool list tank should show the new size immediately. zpool status tank should now list the new vdev alongside the existing ones. New writes start striping across both vdevs.
Here is what the output typically looks like after the command succeeds:
$ zpool list tank NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT tank 7.27T 4.18T 3.09T - - 12% 57% 1.00x ONLINE -
The size jumped from the original 3.63T to 7.27T after adding a second mirror vdev. Existing data is untouched. New files spread across both vdevs automatically.
Method 2: Replace Disks with Larger Drives
If you cannot add a new vdev because your chassis is full or you want a single uniform vdev, replace every disk in the vdev one by one with a larger drive. Set autoexpand=on on the pool before you start so ZFS automatically grows the vdev once all disks are larger.
Step 1: Enable autoexpand. zpool set autoexpand=on tank. If you forget this step you will need to run zpool online -e tank vdev-name after all replacements.
Step 2: Replace the first disk. zpool replace tank /dev/disk/by-id/old-disk1 /dev/disk/by-id/new-disk1. ZFS starts a resilver that copies data from the old disk to the new one. Wait for it to finish before moving to the next disk. You can monitor with zpool status tank.
Step 3: Replace each remaining disk in the vdev one at a time. After the last disk resilvers, the vdev expands to the new size automatically. The whole process is serial because only one resilver can safely run per vdev. A four-disk RAIDZ2 with 4 TB drives replaced by 8 TB drives will take 8 to 16 hours total on a typical NAS.
Step 4: Verify the new size. zpool list tank should show the expanded capacity. If it does not, run zpool online -e tank raidz2-0 (replace raidz2-0 with your actual vdev name) to force the expansion.
This method is slow but does not require any additional slots. It also keeps your fault tolerance uniform because every disk in the vdev ends up the same size and speed.
Method 3: RAID-Z Expansion (OpenZFS 2.3+)
RAID-Z expansion, available in OpenZFS 2.3 and newer, lets you attach a new disk to an existing RAIDZ1, RAIDZ2, or RAIDZ3 vdev and have ZFS redistribute data across the wider group. It is the most flexible expansion method and the one Reddit users rave about when it works. It is also the slowest and the riskiest of the three.
Step 1: Confirm your version. zpool version should return at least 2.3. The feature was funded by the FreeBSD Foundation and took years to ship. Earlier versions will refuse the zpool attach command on a RAIDZ vdev.
Step 2: Run zpool attach tank raidz2-0 /dev/disk/by-id/new-disk. Replace raidz2-0 with the actual vdev name from zpool status. ZFS starts a long reshape that copies every block across the now-wider vdev.
Step 3: Monitor progress with zpool status -v tank. You will see a new scan: reshape line with a percent done and ETA. The reshape reads and rewrites every block in the vdev. On a 10 TB RAIDZ2 with five disks becoming six, expect 24 to 48 hours of constant disk activity.
Step 4: Wait. Do not interrupt the reshape. Do not reboot. Do not pull drives. A power loss during a RAID-Z reshape is one of the few real risks to a ZFS pool. Plug your server into a UPS if it is not already.
Once the reshape finishes, the vdev grows to its new width and you have more usable capacity inside the same vdev. No new top-level vdev is added, so the pool’s overall structure is unchanged.
Adding Hot Spares, L2ARC, and SLOG Devices
You can also grow a pool by adding auxiliary vdevs that improve performance or fault tolerance without contributing to the main capacity. Hot spares are idle disks that ZFS activates automatically when a primary disk fails. L2ARC devices cache reads and dramatically improve random read performance. SLOG devices speed up synchronous writes, especially over NFS or iSCSI.
To add a hot spare, run zpool add tank spare /dev/disk/by-id/spare-disk. To enable automatic replacement when a disk fails, set zpool set autoreplace=on tank. Without autoreplace on, ZFS only resilvers onto the spare but does not detach the failed disk.
To add an L2ARC read cache, run zpool add tank cache /dev/disk/by-id/l2arc-disk. Use a fast SSD with high endurance. L2ARC works best for workloads with many random reads, like Plex media libraries or VM storage.
To add a SLOG write log, run zpool add tank log /dev/disk/by-id/slog-disk. Always use a mirrored pair of SSDs for SLOG; a single SLOG failure can stall sync writes. SLOG is essential for VMware, NFS, and database workloads over ZFS.
None of these auxiliary vdevs add to the main pool capacity. They are performance and reliability features, not storage. Plan accordingly.
Verifying Expansion and Pool Health
After any expansion, verify the result with three commands. zpool list tank confirms the new total capacity and used space. zpool status -v tank shows the vdev topology, scrub or resilver status, and any errors. zpool iostat -v tank 2 watches live I/O per vdev so you can confirm new writes spread across the new vdev.
Run a scrub after expansion. zpool scrub tank verifies every block, including the new vdev’s blocks, and repairs any checksum mismatches. This is especially important after a RAID-Z reshape because long reshapes increase the chance of a silent read error on an aging disk.
Watch performance during the operation. Resilvers and reshapes generate heavy I/O. Frontend workloads like VMs or databases may feel sluggish while a resilver runs. You can throttle a resilver with zfs set resilver_delay=15 tank to give other workloads breathing room, at the cost of a longer total time.
Look for any error counters at the bottom of zpool status. Non-zero read, write, or cksum numbers indicate a problem disk. Address those immediately. Expansion can expose marginal hardware that a healthy scrub had masked.
Important Warnings and Caveats
You cannot remove a top-level vdev from a ZFS pool. Once a vdev is part of the pool it is permanent. Plan your vdev layout before you add a vdev, because a misclick can grow the pool into a configuration you cannot undo without backing up, destroying, and rebuilding.
ZFS does not rebalance existing data when you add a new vdev. Old data stays on its original vdev. New data stripes across all vdevs. This means the performance and capacity benefit is gradual, weighted toward recently written or rewritten files. If you want to rebalance, you would have to copy data off and back on, which is effectively a rebuild.
Mixing redundancy levels in one pool reduces overall fault tolerance to the weakest vdev. A pool with one mirror vdev and one RAIDZ1 vdev loses the entire pool if two disks fail in the RAIDZ1 portion, even though the mirror could survive two failures. Match your vdev redundancy levels unless you really know what you are doing.
Wide vdevs are risky. A 12-wide RAIDZ2 sounds great for capacity but means any two-disk failure within that vdev destroys it. Most community wisdom recommends 6 to 10 disks per RAID-Z vdev for a balance of capacity, performance, and resilience. A Reddit commenter put it bluntly: a 12-wide vdev is a terrible idea. If you need more capacity, add another vdev of the same width instead of widening an existing one.
A second disk failure during a resilver or reshape is dangerous. The operation takes hours, and during that window the pool is more vulnerable than usual. Run it on a UPS, monitor the pool, and avoid heavy use during the operation if possible.
Platform-Specific Notes: TrueNAS, Proxmox, Ubuntu, FreeBSD
TrueNAS Scale and TrueNAS Core both expose the underlying ZFS commands through the web UI. In TrueNAS Scale go to Storage, select your pool, and use the “Add vdev” action to extend a pool. Behind the scenes it runs the same zpool add command. The TrueNAS forum thread on this topic is one of the most-viewed and shows the actual error messages users encounter when they skip prerequisites.
Proxmox runs ZFS on Linux and exposes the same zpool command line. You can extend any pool used for VM storage or the root filesystem through the Proxmox shell. There is no GUI workflow for vdev addition; you SSH in and run zpool add. Proxmox is one of the most common ZFS platforms and one of the least covered in competitor guides, so this is a key gap to fill.
Ubuntu ships ZFS as a kernel module and supports all three expansion methods on supported LTS releases. Ubuntu 24.04 onward includes OpenZFS 2.3, so RAID-Z expansion works out of the box on newer installs. Older LTS releases like 22.04 may need a backport package.
FreeBSD has the longest ZFS history and has supported zpool add since the original ZFS port. RAID-Z expansion shipped in FreeBSD 14. Use camcontrol devlist for stable disk names and remember that FreeBSD disk labels can drift after a reboot if you used /dev/da0 style names.
Comparison Table: Three Expansion Methods at a Glance
The table below summarizes the three main ZFS expansion methods. Pick the one that fits your hardware, your risk tolerance, and how much downtime you can afford.
- Add new vdev (
zpool add): near-instant, very safe, works on any ZFS version, requires free disk slots, does not rebalance existing data. - Replace disks (
zpool replace+autoexpand): takes hours per disk, low risk, works on any ZFS version, requires no slots, keeps vdev uniform. - RAID-Z expansion (
zpool attach, OpenZFS 2.3+): takes days for large pools, higher risk during reshape, requires no slots, grows an existing RAID-Z vdev.
If you have free slots, always add a new vdev first. Replace disks if you are out of slots but want a uniform vdev. Reserve RAID-Z expansion for when you specifically need to grow an existing RAID-Z without adding slots.
Frequently Asked Questions
Can I expand my ZFS pool?
Yes. You can expand a ZFS pool online without losing data by adding a new vdev with `zpool add`, replacing disks with larger drives using `zpool replace` and `autoexpand=on`, or attaching a disk to an existing RAID-Z vdev using `zpool attach` on OpenZFS 2.3 or newer. Always take a full backup before any of these operations.
How do I expand a vdev on TrueNAS?
In TrueNAS Scale or TrueNAS Core go to Storage, select your pool, and click the option to extend the pool. Pick the new disks and the vdev type (mirror, RAIDZ1, RAIDZ2, or RAIDZ3). TrueNAS runs the `zpool add` command behind the scenes. Confirm with `zpool status` from the Shell after.
Does ZFS stripe across vdevs?
Yes. ZFS stripes data across every top-level vdev in the pool to maximize throughput and capacity. New writes spread across all vdevs automatically. The pool fails if any single top-level vdev fails, which is why matching vdev redundancy levels is important for fault tolerance.
Is 32GB RAM enough for ZFS?
For most home and small business pools, 32 GB of RAM is plenty. ZFS uses RAM as an adaptive replacement cache (ARC), and more RAM helps read-heavy workloads. A common rule is 1 GB of RAM per TB of storage plus 8 GB for the operating system, but ZFS also works well with less in low-cache scenarios.
Can I remove a vdev from a ZFS pool?
No. Once a vdev is added to a ZFS pool it cannot be removed. This is a deliberate design choice and a major reason to plan vdev layouts carefully. The only way to undo a vdev is to back up the pool, destroy it, recreate it with the desired vdev layout, and restore the data.
How long does a ZFS pool expansion take?
Adding a new vdev takes a few seconds. Replacing disks with larger drives takes hours per disk because of the resilver process. A RAID-Z reshape can take days depending on pool size, vdev width, and disk speed. Plan for at least one full day for any reshape on a multi-TB pool.
What happens to data when I add a vdev to ZFS?
Existing data stays on its original vdev. ZFS does not rebalance or migrate old files. New data and rewritten files stripe across all vdevs in the pool. To redistribute existing data you would have to copy it off the pool and back, which is effectively a full rebuild.
Conclusion
You can expand a ZFS pool by adding a vdev without losing data, and the operation is online and safe as long as you take a backup, confirm the pool is healthy, and pick the right method for your hardware. For most users the right answer is zpool add with a fresh mirror or RAIDZ2 vdev. If you are out of slots, replace each disk with a larger one and let autoexpand do the work. If you are on OpenZFS 2.3 or newer and specifically need to grow a RAID-Z, use zpool attach and plan for a multi-day reshape on a UPS.
Pick the method that matches your chassis and your risk tolerance, scrub before and after, and you will come out the other side with a bigger pool and the same data you started with. The full plan is in the step-by-step sections above, and the platform notes cover TrueNAS, Proxmox, Ubuntu, and FreeBSD if you need OS-specific guidance.