How to Migrate to a Bigger NAS Without Losing Data
There are four ways to move to a bigger NAS. Copying across the network with both units running is the safest, because the old array stays intact, and it takes about 59 hours for 24 TB over gigabit or 24 hours over 2.5GbE. Replacing drives one at a time in place needs no second unit but triggers one full rebuild per drive, and at 80 to 150 MB per second a 20 TB member takes 37 to 69 hours each time. Before starting anything, verify a backup, run a clean scrub and check SMART on every drive.
Four paths exist and they trade the same three things against each other: downtime, risk and money. Copying across the network with both units running is the safest, because the old array stays complete and readable the entire time. Replacing drives one at a time in place is the cheapest and the most exposed, since each swap triggers a full rebuild and a 20 TB member takes 37 h to 69 h (2.9 days) to resilver. Moving the drive set into a new chassis is instant and only works inside one vendor, or with any ZFS pool. Restoring from backup is the slowest and the only one that also proves your backup works.
What are the four ways to migrate to a bigger NAS?
A migration is any operation that moves your data onto more capacity without losing it. Pick the path from the shape of your upgrade, not from what sounds easiest.
| Path | Downtime | Risk | Elapsed time | What it needs | What it keeps | Choose it when |
|---|---|---|---|---|---|---|
| Drive by drive, in place | None | High, one rebuild per drive | Days to weeks | New drives only | Everything, including settings | Same chassis, bigger drives, and you can wait. |
| Copy across the network | None until cutover | Lowest, the old array stays intact | Hours to days | Both units running at once | Files, and settings on some platforms | New unit, different brand, or a bigger bay count. |
| Move the drives to a new chassis | Under an hour | Low within a brand, total across brands | Minutes | A compatible chassis | The array intact | Same vendor upgrade, or any ZFS pool import. |
| Clean rebuild from backup | The whole restore | Low, and it tests the backup | Days | A verified backup | Whatever the backup holds | Changing layout or filesystem, or starting fresh. |
"Risk" here means the chance that something goes wrong during the migration and costs you data, not the chance the migration fails and you try again. The two lowest-risk rows both keep a complete second copy of the data alive throughout.
One decision comes before all four: do you need more capacity or more bays? They are different problems with different answers. Four 8 TB drives give 24 TB usable under SHR or RAID 5. Replacing all four with 16 TB drives gives 48 TB in the same chassis for about $2,320 in drives, with no new enclosure, no extra power draw and no extra failure surface. Buy more bays only when the largest sensible drive in every bay still does not reach the capacity you need.
How does drive-by-drive replacement work, and what does it cost you?
Drive-by-drive replacement means pulling one member, inserting a larger drive, letting the array rebuild onto it, and repeating. The array stays online throughout, no second unit is required, and the only purchase is drives. It is the path most people take and the one whose cost is least understood.
The cost is exposure. Under single parity the array has zero redundancy from the moment you pull the first drive until the rebuild completes, and during that window it is reading every sector of every surviving member: 24 TB on a four-bay array of 8 TB drives, more as the drives get larger. Do that four times to swap a whole set and you have stacked four of those windows back to back, on drives that are all the same age.
Never run a drive-by-drive upgrade on an array you have not just scrubbed clean and backed up. The rebuild is the heaviest sustained read those drives will ever see, and it finds every latent bad sector that has been sitting quietly unread for two years. Under double parity you keep one drive of protection through each swap, which is the single strongest argument for RAID 6, RAIDZ2 or SHR-2 on any array you intend to grow this way. See RAID 5 against RAID 6.
The other surprise is when the space appears. It is not after the first drive. Under single parity you need two drives at the new size before capacity increases, because the new upper band has to sit on at least two members to be protected. Under double parity you need three. On our four-drive example, swapping two 8 TB drives for 16 TB drives takes SHR from 24 TB to 32 TB usable, and classic RAID 5 on the same drives stays at 24 TB because it truncates every member to the smallest. That gap is the entire practical case for SHR, and it is set out in SHR against RAID 5.
How long does each rebuild take?
Rebuild time is roughly the capacity of the replacement drive divided by the rebuild rate, and 80 to 150 MB per second is the realistic band on a NAS that is also still serving files. The array reads from the survivors and writes the whole surface of the new drive, so it is the new drive's size that sets the clock.
| Drive size | Rebuild at 150 MB/s | Rebuild at 80 MB/s | Reads from survivors, 4 bays single parity | Swapping all 4 bays, best case | Swapping all 4 bays, worst case |
|---|---|---|---|---|---|
| 4 TB | 7 h | 14 h | 12 TB | 30 h | 56 h (2.3 days) |
| 6 TB | 11 h | 21 h | 18 TB | 44 h | 83 h (3.5 days) |
| 8 TB | 15 h | 28 h | 24 TB | 59 h (2.5 days) | 111 h (4.6 days) |
| 12 TB | 22 h | 42 h | 36 TB | 89 h (3.7 days) | 167 h (6.9 days) |
| 16 TB | 30 h | 56 h (2.3 days) | 48 TB | 119 h (4.9 days) | 222 h (9.3 days) |
| 20 TB | 37 h | 69 h (2.9 days) | 60 TB | 148 h (6.2 days) | 278 h (11.6 days) |
| 24 TB | 44 h | 83 h (3.5 days) | 72 TB | 178 h (7.4 days) | 333 h (13.9 days) |
The last two columns are four consecutive rebuilds, which is what a full set swap actually costs in elapsed time. Precalculated figures at every bay count are in the RAID rebuild time chart. ZFS is the exception to this arithmetic: a resilver copies only the blocks in use, so a pool that is half full finishes in roughly half the time, while mdadm and hardware RAID rebuild every sector whether it holds anything or not.
Read the 20 TB row. Swapping a four-bay set of 20 TB drives is 148 h (6.2 days) at best and 278 h (11.6 days) at worst, and on single parity essentially all of that is time with no redundancy. That is the number that should decide whether you swap in place or buy a second unit and copy.
Three things genuinely speed a rebuild up: stop serving files from the array while it runs, pause scheduled indexing and scrubs, and use drives that are not shingled. An SMR drive can drop to a small fraction of these rates under sustained write and turn a two day rebuild into a week. Our guide to choosing NAS drives covers how to tell before you buy.
How long does copying across the network take?
Running both units at once and copying is the lowest-risk migration available, because nothing is ever removed from the old array. If the copy fails, you repeat the copy. The cost is that you need both machines powered simultaneously and enough hours.
| Link | Real throughput | 24 TB | 48 TB | 96 TB | Note |
|---|---|---|---|---|---|
| Gigabit Ethernet | 113 MB/s | 59 h (2.5 days) | 118 h (4.9 days) | 236 h (9.8 days) | One drive alone already saturates this |
| 2.5GbE | 280 MB/s | 24 h | 48 h | 95 h (4.0 days) | The cheap upgrade, about $35 for a switch |
| 5GbE | 560 MB/s | 12 h | 24 h | 48 h | Uncommon, usually via a USB or PCIe adapter |
| 10GbE | 1100 MB/s | 6 h | 12 h | 24 h | Needs NAS, switch and client to all change |
| Direct USB dock, drive limited | 200 MB/s | 33 h | 67 h (2.8 days) | 133 h (5.6 days) | Bypasses the network entirely |
Throughput figures are realistic ceilings after protocol overhead, not line rates. Actual speed is also capped by what the source array sustains, and a four-drive array will not fill a 10GbE link on a folder of small files however fast the network is. Work out your own case in the network throughput calculator.
A gigabit copy of 24 TB is 59 h (2.5 days), which is why this is the one migration where upgrading the network genuinely pays for itself in a single job. A five-port 2.5G switch at around $35 and a USB 2.5GbE adapter at around $26 cuts that to 24 h, and both remain useful afterwards. Compare the tiers in 2.5GbE against 10GbE.
Practical notes for the copy itself:
- Use a tool that can resume and verify, meaning rsync, robocopy or the vendor's own migration assistant, rather than dragging folders in a file manager. A copy that dies at 80 percent should restart at 80 percent.
- Copy in passes. Run the bulk copy while you carry on using the old unit, then run a second pass at cutover that only moves what changed. The second pass takes minutes.
- Verify before you wipe. Compare file counts and total bytes, and spot-check a few large files. Do not reformat the old array until the new one has been in daily use for a week.
- Keep the old drives intact for a while after cutover. They are the cheapest extra copy you will ever have, and they are already paid for.
Can I move my drives into a new chassis?
Sometimes, and the answer is entirely about the on-disk format.
- Within one vendor, usually yes. Synology publishes a migration procedure that moves a drive set into a compatible newer model with the volume intact, subject to a supported model pairing and a DSM version check. QNAP and others have equivalents. Read the vendor's own compatibility list for your exact pair of models before you pull anything, because the supported combinations are specific.
- Any ZFS pool, yes, anywhere. Export the pool on the old host if you can, move the drives, import on the new host. Order does not matter, the controller does not matter, and the hardware does not have to resemble the original at all. This is the strongest practical argument for ZFS.
- Unraid, yes, with the configuration. Each data drive holds whole files in a normal filesystem, so the drives are readable individually, and the array reassembles when the configuration is restored alongside them.
- Across vendors, no. A Synology drive set does not import into a QNAP, a UGREEN or a TerraMaster unit. Even where two vendors both use mdadm underneath, the metadata layout, the partition scheme and the configuration database differ. Plan a network copy instead.
- Off a proprietary hardware RAID card, no. The card writes array metadata in its own format, so the drives generally need the same model of controller, sometimes the same firmware, to be readable at all. That is a failure mode parity does not cover, and it is covered in NAS or DIY home server.
Even where the move is supported, take the backup first and photograph the bay order before you pull the drives. Reinserting a set in a different order is fine on ZFS and on Synology, and the photograph costs nothing on the day it turns out not to be fine.
How does SHR expansion work?
SHR grows in two ways: add a drive to an empty bay, or replace existing drives with larger ones. Both happen online. The rules that catch people are about when the extra space actually appears.
- Adding a drive to an empty bay extends the array and the new capacity becomes available after the expansion completes. This is the simple case.
- Replacing drives with larger ones needs two of them at the new size under SHR, and three under SHR-2, before any additional capacity appears. The band above the old drive size has to sit on enough members to carry its parity, so one large drive on its own contributes nothing but a spare tyre.
- Replace one at a time and let each rebuild finish. Pulling two drives at once on single parity destroys the array.
- SHR does not shrink. You cannot remove a drive or move to smaller drives without rebuilding the volume from scratch, which means copying everything off and back on.
- Treat the parity level as fixed at creation. Whether your specific model and DSM version offers an in-place conversion from SHR to SHR-2 varies, so check it against your model rather than assuming, and choose double parity at creation if the array will ever hold drives of 12 TB or more.
Worked through with real drives: a four-bay unit holding four Seagate IronWolf 8TB drives has 24 TB usable. Swap two of them for IronWolf Pro 16TB drives and SHR reports 32 TB. Swap the remaining two and it reports 48 TB, for about $2,320 in drives spread over as long as you like. Check any combination in the RAID capacity calculator, which is the only cross-vendor one and handles mixed drive sizes directly.
Can I expand a ZFS pool?
Yes, in three specific ways, and there is one thing you still cannot do.
- Replace every drive in a vdev with a larger one, one at a time. The vdev grows to the new size once the last replacement finishes, with the autoexpand property set. This is the direct equivalent of the SHR drive-by-drive upgrade, and unlike SHR you get nothing until the last drive is done, because a RAIDZ vdev truncates every member to the smallest.
- Add a whole new vdev to the pool. The traditional answer. The pool's capacity is the sum of its vdevs, so a second four-drive RAIDZ2 vdev alongside the first doubles the pool. Match the geometry, because a pool is only as resilient as its weakest vdev.
- RAIDZ expansion adds a single drive to an existing vdev. This is a recent addition to OpenZFS rather than long-standing behaviour, so check that the version you actually run supports it. Note the caveat that matters: existing data keeps the parity-to-data ratio it was written with until it is rewritten, so the reported free space after an expansion can be lower than the naive arithmetic suggests.
What you cannot do is remove a RAIDZ vdev from a pool. Once it is in, it is in for the life of the pool, and shrinking is not an operation ZFS offers for RAIDZ. That is why pool geometry is a decision to make before buying drives rather than after: choosing a four-drive RAIDZ1 vdev today constrains every expansion you will make for years. The layout formulas are in RAID levels explained.
When should I just rebuild from backup?
When you are changing something the array cannot change in place. Specifically: moving from single parity to double parity, changing filesystem, moving from a vendor appliance to TrueNAS or the reverse, or restructuring a ZFS pool. None of those are in-place operations, so a clean rebuild is not the fallback, it is the procedure.
It also has a benefit the other three paths lack: it proves your backup works. A full restore is the ultimate test of the zero in 3-2-1-1-0, and doing it deliberately, on a day you chose, with the old array still sitting intact next to you, is the safest possible way to find out that a job stopped running eight months ago. The method is in the 3-2-1 backup rule guide.
Two ways to make it faster. Restore from the local copy rather than the offsite one, since a 20 TB external drive over USB moves data at drive speed rather than internet speed. And restore in priority order: the irreplaceable files first, so that within a couple of hours the important half is back and the media library can trickle in overnight. If you keep your backups as bare drives, a dual bay dock lets you read two at once.
What should I check before I start?
Work down this list before the first drive comes out. Every item exists because skipping it has cost somebody an array.
| Before you start | Why it is on the list |
|---|---|
| Verify the backup and restore one real file from it | A migration is the moment a missing backup becomes expensive. Do this first, not last. |
| Run a full scrub or parity check and let it finish clean | A latent bad sector on a surviving drive is what turns a routine rebuild into a data loss event. |
| Read SMART on every drive | Reallocated or pending sectors on any member means fix that drive before you start stressing the array. |
| Record serial numbers against bay positions | You will be pulling drives. Knowing which physical tray holds which serial prevents pulling the wrong one. |
| Burn in each new drive before it joins the array | Infant mortality is real, and a drive that fails during its own rebuild is the worst possible timing. |
| Check the UPS and its battery | A rebuild is the longest window in which a power cut can do real damage, and lead acid packs fade silently. |
| Pause scheduled jobs that compete for the drives | Indexing, thumbnail generation, scheduled scrubs and backup jobs all slow a rebuild and lengthen the exposure. |
| Update the OS first, then let it settle for a few days | You want a known-good current version going in, not a firmware change landing in the middle of a resilver. |
| Write down the plan and the expected duration | Knowing a rebuild should take 40 hours is how you tell normal from stuck at hour 30. |
The first two rows carry most of the weight. A verified backup makes every other item on this list a matter of inconvenience rather than loss, and a clean scrub is what tells you the surviving members can actually survive a rebuild.
A few practical items worth having on hand before the day: a pack of SATA cables if the new chassis is a tower, a small screwdriver set and a parts tray for drive trays that take screws, and an external drive holding at minimum the files you genuinely cannot lose, unplugged and sitting on a shelf while the migration runs.
Finally, plan the timing. Start a rebuild when you can leave the array alone: the rate figures on this page assume the machine is not simultaneously transcoding video and running a backup job. And know the expected duration before you begin, because the only way to tell a rebuild that is slow from a rebuild that is stuck is to have had a number in mind at the start.
Related reading
- RAID rebuild time chart for precalculated figures at every drive size and bay count
- How to choose NAS drives for what to buy when you swap the set
- SHR against RAID 5 for why drive-by-drive upgrades favour SHR
- Drive failure probability calculator for the odds during the exposure window
- Best 4-bay NAS and best 8-bay NAS if the migration is to a bigger chassis
Frequently asked questions
Can I replace NAS drives one at a time with bigger ones?
Yes on Synology SHR, on classic RAID levels and on ZFS, but capacity does not increase until enough drives have been replaced. Under single parity you need two drives at the new size before any extra space appears, because the new upper band needs at least two members to be protected. Under double parity you need three. Each replacement triggers a full rebuild that leaves the array exposed for hours or days.
How long does a NAS rebuild take?
Roughly the drive capacity divided by 80 to 150 MB per second. A 12 TB member takes about 22 to 42 hours, a 20 TB member about 37 to 69 hours, and a 24 TB member about 44 to 83 hours. Add time if the array is still serving files during the rebuild, and subtract some on ZFS, which resilvers only the blocks actually in use rather than every sector.
Can I move my drives into a new NAS?
Within a vendor, usually yes: Synology publishes a migration path that lets you move a drive set into a compatible newer model with the volume intact, and a ZFS pool imports on any host running ZFS. Across vendors, no. A Synology drive set will not import into a QNAP or a UGREEN unit, and the answer there is to copy across the network with both units running.
Can you shrink or remove a ZFS vdev?
Not for RAIDZ. A pool containing a RAIDZ vdev cannot have that vdev removed, which is why pool geometry is a decision you make before buying drives. Growing has traditionally meant adding a whole new vdev or replacing every drive in an existing one. RAIDZ expansion, which adds a single drive to an existing vdev, is a recent OpenZFS addition rather than long-standing behaviour.
What is the safest way to migrate to a bigger NAS?
Run both units side by side and copy across the network. The old array stays complete and readable the entire time, so a failure during the copy costs you the copy rather than the data, and you can verify the new unit before decommissioning anything. It needs both machines powered at once and enough time, roughly 59 hours for 24 TB over gigabit and 24 hours over 2.5GbE.
Should I upgrade drives or buy a bigger NAS?
Upgrade the drives first, in almost every case. Four 8 TB drives replaced by four 16 TB drives takes a four-bay array from 24 TB usable to 48 TB for about $2,320 in drives, with no new chassis, no new power supply and no new failure surface. Buy more bays when the largest sensible drive in every bay still does not give you the capacity you need.
How we choose: we compare published manufacturer specifications, drive datasheets, published reliability statistics and verified owner reviews. We do not test hardware in person, and we are not tied to any NAS vendor. Capacity and power figures here are researched guidance, not a warranty. RAID protects against drive failure, not against deletion, ransomware, fire or theft, so keep verified backups regardless of what any calculator tells you.
Working out your own cost per usable terabyte? The Home Server Build Planner is the paid version of these pages: 8 printable worksheets you fill in with your own numbers, plus the full PDF, $29.