Can I add a drive to an existing RAID 5 array?

Often yes, depending on the platform. Linux mdadm can grow a RAID 5 by adding a disk and reshaping, Synology SHR and Unraid support adding drives natively, and since OpenZFS 2.3 even RAIDZ pools can be expanded one disk at a time. The reshape can take a day or more, the array is under full load the whole time, and a current backup beforehand is non-negotiable.

Can I expand a ZFS RAIDZ pool by adding one disk?

Yes, since OpenZFS 2.3 (released January 2025) — the long-awaited RAIDZ expansion feature. It attaches a new disk to an existing RAIDZ vdev and redistributes the data. Two caveats: existing blocks keep their old data-to-parity ratio until rewritten, so reclaimed capacity is initially smaller than expected, and the pool must run OpenZFS 2.3 or newer with the feature enabled.

Is it safer to replace drives with bigger ones instead of adding drives?

It's the standard path when your enclosure has no free bay: replace one drive with a larger one, wait for the full rebuild, repeat for every drive, and the extra capacity unlocks after the last one. It works on mdadm, ZFS, SHR and most systems, but each swap is a full rebuild with degraded redundancy, so a 4-drive array means four rebuild windows where a second failure can kill the pool. Backup first, and prefer RAID 6/RAIDZ2 when using this path with large drives.

Do I have to back up before expanding a RAID array?

Yes. A reshape or expansion rewrites data and parity across all drives for hours or days, which is exactly the sustained stress that surfaces marginal drives. If a drive fails mid-reshape on a single-parity array, you're one unreadable sector away from losing the pool. Expansion is a planned operation — schedule it after a verified backup, ideally following the 3-2-1 rule.

Expanding a RAID Array: Add Drives Without Losing Data

Updated: 2026-07-05· Last verified July 2026

Planning the expansion? Compare your current array against the grown one — same pool, more drives — before you commit.

Open RAID Calculator →

Sooner or later every NAS hits the same wall: the pool that felt enormous two years ago is now at 90 percent, and the question becomes whether you can simply slot in another drive or whether you're facing a full backup-wipe-restore cycle. The honest answer used to be "it depends, and often no" — traditional RAID was famously rigid about this, and ZFS in particular spent two decades refusing to grow a RAIDZ vdev. In 2026 the picture is far friendlier: almost every platform now has a supported way to expand, but each one comes with its own mechanics, waiting times, and fine print. This guide walks through the options platform by platform, then covers the drive-replacement path that works everywhere, and finally the risk management that turns an expansion from a gamble into a routine maintenance task.

Adding a drive: what each platform actually supports

The ability to bolt a new drive onto a live array is called reshaping or expansion, and support has quietly become mainstream. What differs is how much of the work happens online, how long it takes, and what state your data is in along the way.

mdadm (Linux): mdadm --grow adds a disk to a RAID 5 or 6 and reshapes the array in place while it stays mounted; the Linux RAID wiki's Growing guide documents the procedure, including the critical backup-file option that protects the reshape's own metadata against a power cut.
ZFS RAIDZ: the headline change — OpenZFS 2.3 shipped RAIDZ expansion in January 2025, so a 4-disk RAIDZ1 can finally become a 5-disk RAIDZ1 with zpool attach. TrueNAS exposes it in the UI on current releases.
Synology SHR: add a drive through Storage Manager and DSM handles the rest; the Synology expansion KB lists which pool types can grow and which RAID-type migrations (Basic→RAID 1, RAID 1→RAID 5…) are supported.
Unraid: the easiest of all — because data disks are independent, you just add a formatted disk to the array and it contributes its full capacity immediately, as long as it's no larger than the parity drive, per the Unraid storage documentation.
Btrfs (DIY): btrfs device add followed by a rebalance spreads existing data across the new device; the Btrfs volume management docs cover both steps.

The concrete takeaway: before assuming anything, identify which layer actually manages your redundancy — the platforms differ so much that "can I add a drive?" has five different correct answers depending on the box you own.

ZFS RAIDZ expansion: what the fine print says

Because RAIDZ expansion is the newest and most-asked-about of these features, it deserves its own section. The feature attaches one new disk at a time to an existing RAIDZ1/2/3 vdev and then runs a background redistribution that shuffles existing blocks across the wider stripe, during which the pool stays online and usable. That alone ends the single most painful limitation ZFS had for home users, who previously had to either add a whole second vdev or destroy and rebuild the pool.

The fine print matters, though. Blocks that were written before the expansion keep their original data-to-parity ratio — a block written on a 4-disk RAIDZ1 still occupies stripe space as if the vdev had 4 disks, even after you've grown it to 5. Newly written data uses the wider, more efficient layout, and old data only converts if it gets rewritten (by normal churn, or by deliberately copying datasets). In practice that means the usable capacity right after an expansion is somewhat less than the theoretical number our calculator shows for a native 5-disk RAIDZ1, converging toward it as data turns over. The zpool-attach man page spells out this behavior.

For the more technical crowd: expansion also doesn't change the vdev's parity level — a RAIDZ1 stays a RAIDZ1 no matter how many disks you attach. If your real motivation for expanding is that the pool has grown beyond what single parity comfortably protects, expansion is the wrong tool; that's a rebuild-as-RAIDZ2 conversation, and our RAID 5 vs RAID 6 comparison explains where that line sits.

The concrete takeaway: RAIDZ expansion is real, stable, and shipping — but budget for less immediate free space than the naive math suggests, and don't use it as a substitute for moving to double parity when drive counts and sizes demand it.

The universal path: replace drives with bigger ones

When there's no free bay left — the situation every 2-bay and 4-bay owner eventually faces — the classic expansion path is to swap each drive for a larger one, one at a time. The sequence is always the same: pull one drive, insert the bigger replacement, let the array fully rebuild onto it, then repeat for the next drive. The extra capacity stays locked until the last drive is swapped, at which point mdadm, ZFS (with autoexpand=on), SHR and DSM all let the pool grow into the new space. Synology documents this drive-by-drive procedure in the same expansion KB, and SHR has the extra trick of unlocking part of the capacity earlier when drive sizes are mixed — our mixed drive sizes guide shows how that math works.

The cost of this path is time and risk multiplied by drive count. Each swap is a full rebuild — hours to more than a day per drive for today's capacities, as our rebuild time guide quantifies — and during every one of those rebuilds a single-parity array is running with zero redundancy. Four drives means four separate windows where one additional failure or unreadable sector ends the pool. That's survivable odds for RAID 6 or RAIDZ2, and a genuinely uncomfortable bet for RAID 5 with large drives.

The concrete takeaway: the replace-and-rebuild path works on virtually every platform and needs no spare bay, but treat it as N consecutive degraded periods, not one operation — and if that thought makes you nervous with single parity, that nervousness is telling you something.

How long would your rebuild take — and how risky is it? The rebuild calculator estimates duration and URE failure odds for your exact drives.

Open Rebuild Calculator →

Risk management: expansions fail at the worst moment

Whichever path you take, an expansion is many hours of sustained, full-surface disk activity — precisely the workload that turns a marginal drive into a dead one. This isn't superstition; it's the same mechanism that makes rebuilds after a failure risky, as covered in what happens when RAID fails. A reshape adds an extra twist: the operation itself maintains critical in-flight state, which is why the mdadm documentation insists on the backup-file option and why a power cut mid-reshape without a UPS is one of the few ways to genuinely mangle an array beyond easy repair.

So the pre-flight checklist is short and non-negotiable. First, a verified, current backup — not because expansion usually fails, but because when it does, it fails completely; RAID is not a backup applies double during maintenance windows. Second, check SMART health on every drive before you start, since a drive already logging reallocated sectors will not enjoy a 20-hour reshape. Third, run the expansion on UPS power, and fourth, scrub the array first so the reshape doesn't trip over a latent unreadable sector halfway through. None of these steps costs money except the UPS, and all of them are cheaper than data recovery.

The concrete takeaway: schedule an expansion like a small maintenance project — backup verified, SMART clean, scrub done, UPS attached — and it becomes boring in the best possible way.

When expanding is the wrong answer

Sometimes the honest advice is not to grow the current array at all. If your NAS is a 2-bay, drive replacement is your only in-place option, and the economics often favor moving to a 4- or 6-bay chassis instead — larger arrays spread parity overhead across more drives and give you an expansion path for the next round too, which is exactly the trade our 2-bay to 4-bay to 6-bay upgrade guide walks through. Similarly, if the array is old enough that its drives are all approaching the same wear-out point, pouring a reshape's worth of stress onto five aging disks to add a sixth is backwards; a fresh pool on fresh drives with a copy migration is calmer and leaves you a complete fallback copy until the moment you decommission the old set.

And if the expansion is really a redundancy upgrade in disguise — you want to go from RAID 5 to RAID 6, or RAIDZ1 to RAIDZ2 — most platforms make that a rebuild, not a reshape (mdadm being the notable exception that can convert levels in place, slowly). In that case plan it as a migration from the start. The concrete takeaway: expansion is a tool for "same design, more space" — when what you actually want is a different design, migrate instead of stretching the old one.

Recommendation by platform

On Unraid, just add the disk — it's the platform's whole party trick, capacity is available immediately, and parity is untouched. On Synology, use Storage Manager's add-drive flow for SHR and let DSM run the resync overnight; it's the most polished implementation of the bunch. On TrueNAS or any OpenZFS 2.3+ system, RAIDZ expansion via zpool attach is now the sanctioned route for adding a single disk, with the capacity fine print above. On a DIY mdadm or Btrfs box, the tools work well but read the wiki procedure fully before starting, because the safety nets (backup file, balance filters) are manual. And whichever platform you run, model the before/after in the RAID calculator first so the usable-capacity gain is a number rather than a hope — then check the rebuild calculator to see what the maintenance window will really look like.