A volume that went read-only while the share still opens is the copy window. Several bays that emptied in the same minute are a controller, backplane, cable, or power path. A rebuild after one drive has already failed, with the others confirmed healthy, is rebuild versus recovery. A ZFS scrub that already found checksum errors is don't race the replace. A DSM update waiting on a degraded pool is that page. Two members already down is RAID 5 with two drives failed. This page is the upgrade you are about to start while the pool still says healthy.
The rebuild is the risk, and you scheduled it
A one-disk capacity upgrade reconstructs the replaced member from the members that remain, and writes that reconstruction to the new disk. It is not a file copy. On the pull-and-repair path — the old disk out before the new one is built — a layout with one disk of redundancy is already Degraded for the length of that job. SHR-1, RAID 5, RAID 1, a single Unraid parity disk, and raidz1 have nothing left to lose while that is true. A second drive that cannot be read is how that degraded pool becomes a dead one. Synology Replace Drive, when an unused bay is free, and a TrueNAS replace into an empty slot, keep the old disk until the new one is done. They still read the other members.
How much of each old drive that read covers depends on the system. It is a reconstruction of the missing member, and on a full volume it is a long one.
Synology. Repair reads the remaining members to rebuild the one you replaced. Fast Repair is on by default. Synology says it skips unused space so protection comes back sooner. The same article says that when pool usage exceeds 80%, the system switches to Regular Repair. People start a capacity upgrade because the volume is already full. That is the long read, on every drive that stayed in, while the pool is Degraded if you pulled the old disk first.
Unraid. The storage manual is blunt about a rebuild: Unraid must be able to reliably read every bit of parity plus every bit of all the other disks. The same page says a good rebuild depends on every other array disk being read without error, and that read errors on those disks during the rebuild leave the new disk corrupt, with data loss likely. Their current upgrade page says the same risk in fewer words: with single parity, another drive failing during the upgrade can lose data.
QNAP. Replace Disks One by One pulls a member, marks the RAID group Rebuilding, and tells you not to remove any other disk until that rebuild finishes. On the QuTS hero h5.3 article, doing so "may result in permanent data loss or corruption." The rebuild is the read. The warning is about interrupting it with a second pull, which is the same window a dying old disk interrupts on its own.
TrueNAS and OpenZFS. Replacing a disk resilvers the new one. OpenZFS describes a resilver as the scrub machinery limited to data ZFS knows is out of date: the allocated blocks, not a pass over unused space. On a pool that is nearly full, allocated data is most of the old disks. A scrub and a resilver do not run together. Sequential reconstruction (zpool replace -s) is not supported for raidz. TrueNAS's own replace steps say the replacement wipes the new disk and that the resilver can take a long time.
On October 6, 2026, AkitaOnRails published "Disaster on My NAS! How I Almost Lost 90 TB of Data." He describes a DS1821+ with all eight bays filled, SHR with one-disk redundancy, partway through swapping drives one at a time for larger ones. He pulled one drive. The rebuild started with the members looking healthy. The next morning the new drive and an old member were both critical. He quotes the pool: "Unrecoverable errors have occurred because drive errors occurred after storage pool degradation. Please back up your data immediately." He reports that Synology support, after he sent logs, said that old drive had been logging media errors for over a month, and that those errors are what took it down during the rebuild. He also reports he was not warned before the swap. An update dated October 11 says the copy finished and that no file was lost by accident. That is his account of his copy. It is not a procedure, and it is not a rate.
Two details in that write-up are the ones worth keeping. The sick drive was already failing before the swap, and the long read is when it showed up. Later he reports a different old member, with a zero reallocated-sector count, as the disk that limited the copy. A zero count did not describe how that disk behaved under the long read, and it had not been a scrub. His write-up goes on to delete that pool and create another one, after the files were on a different NAS. That step assumes the copy already exists somewhere else. Skip it until that copy does.
Check every drive that is staying
Do this while the pool is still Healthy, before any disk comes out. The new disk can fail too. In that write-up the replacement, with 13 hours on it, was critical the next morning along with the old member. The systematic risk is still the long read of the drives that already have the hours, the bad sectors, and the scrub history.
Synology. Storage Manager, HDD/SSD, every member of the pool. Run the extended S.M.A.R.T. test, not only the quick one. The S.M.A.R.T. FAQ, updated September 30, 2026, lists bad sector count among the common attributes, and it says an extended result of "Attention required" means scrub and back up. On DSM 6.2 through 7.1.1, Synology's status article defines Warning as issues or an increase in bad sectors, and Critical, Failing, and Access Error as the replace-the-drive statuses. Read the bad-sector count in Health Info. A count that is already above zero, or that has climbed since the last look, is a drive that has failed a read. If the pool supports data scrubbing — Btrfs, or SHR of three or more drives, RAID 5, RAID 6, or RAID F1 — run it now, while the pool is Healthy. A degraded pool is taken off the scrubbing schedule until it is repaired, so the scrub has to finish while the pool is still Healthy. Without data checksums on a shared folder, Synology says that scrub cannot check and repair the data in the folder. Run it before the swap anyway. The replace-to-expand article says to scrub first so the volume and the pool are Healthy.
Unraid. Their upgrade steps require a parity check with zero errors before you unassign anything. If parity is not valid, they say rebuilding the disk will corrupt its filesystem. If the check reports errors, the upgrade stops there. Do not unassign a data disk to "fix" them. The storage manual says SMART monitoring, for SATA, defaults to watching reallocated sectors (attribute 5), current pending sector (197), and uncorrectable sector count (198), among others, and that a status report can call the array healthy while SMART says a disk is not. Click the disk name on the Main tab and read the attributes. Pending sectors are sectors the drive could not read and has not remapped. The rebuild is the next time those sectors are asked for. An orange SMART icon you already acknowledged is still an icon. Acknowledging it does not remap the sector.
TrueNAS. zpool status -v before you touch Replace. READ, WRITE, and CKSUM should be zero on every disk, and the last scrub should have finished without errors. A non-zero CKSUM is the scrub page, and a replace is the wrong next click. A resilver reads the allocated data from the disks that remain. Those disks have to have survived a scrub first.
QNAP. Read each member in Storage & Snapshots before Replace Disks One by One. The h5.3 expand article's own precaution is a backup. A disk you would not trust to be read for the length of a rebuild is the disk that comes out first, alone, as a failed-drive replacement. The capacity set waits until that rebuild has finished.
Replace the sickest drive first. Synology's capacity math says to replace the smallest drive when you want the pool to grow. That rule and this one are different jobs. If the drive with the bad sectors, the Warning status, or the failed extended test is not the smallest, it still comes out first. You may not gain a byte of capacity on that swap. The pool has to be Healthy, with that drive gone, before a capacity swap of a different bay is a sane thing to start. A hot spare assigned to the pool will start a repair on its own when you pull a member. That repair does not expand the pool, and it is still the long read. Unassign the spare before you begin, or the rebuild starts when you pull the disk.
Have a verified backup before the first swap. Synology's replace article says the expansion will not delete existing data, and still says to back up before you proceed. QNAP's h5.3 article says to back up to prevent data loss. Unraid says to keep the original disk intact until the upgrade is confirmed. The copy that counts is on a different device, and you have opened files from it. A job that reported success is not that. AkitaOnRails later found a sync that had reported success while skipping a directory it could not read and files whose names it would not copy. An independent check is what showed the holes. Open the backup. Then start.
The old drives are the ones a capacity upgrade reads. If a member already shows bad sectors, a failed scrub, or pending sectors, have the set evaluated before the first swap. Free evaluation, no data, no fee.
One drive, then wait until the pool is healthy again
Synology, QNAP, Unraid, and TrueNAS all say the same thing in their own words: finish one replacement before you start the next. The capacity rules below are why an upgrade takes days. They are also why pulling the second disk "to save a cycle" is how the redundancy gets spent on purpose.
Synology, empty bay. Replace Drive is available when the NAS has an unused drive and the pool is SHR, SHR-2, RAID 1, RAID 5, RAID 6, RAID 10, or RAID F1, with at least two drives. Only one drive at a time. The new drive's data is erased. The pool status goes to Replacing, and Synology says redundancy still protects the pool through the process. When it finishes, the old drive is deactivated and the LED tells you which one to remove. Wait until the pool is back to Healthy before the next drive. This path still reads the other members. It does not degrade the pool first.
Synology, every bay full. The same article's other procedure is the one an eight-bay unit with eight drives has to use. Deactivate the drive you are replacing, power the NAS off if it does not support hot-swap, install the larger drive, and Repair the pool, which is now Degraded. Repair only appears when the pool is Degraded, and only for pools with data protection. All existing data on the replacement is erased. Repeat only after that repair has returned the pool to Healthy. The expand article, updated September 17, 2026, is the capacity math. SHR-1 with equal-sized drives: at least two larger drives, one by one. SHR-2 with equal-sized drives: at least four. Mixed sizes: the replacement has to be at least as large as the largest drive already in the pool, and you replace smaller drives first. RAID 1, RAID 5, RAID 6, RAID TP, RAID 10, and RAID F1: if they all match, replace all of them one by one; if they don't, replace the smallest first. A one-drive SHR-1 cannot grow by replacing that drive. RAID 0 and a stripe have nothing to rebuild from. Pulling a member there is the data.
Auto Repair is off by default, is not supported on SHR, and exists only on models that support a RAID Group. Leave it off for this project so a drive insertion does not start a repair you have not looked at. Do not install a DSM update while the pool is Degraded for this repair. That restart is the update page.
QNAP. On QTS 5.0, the path is Storage & Snapshots, the pool or static volume, Manage, a RAID 1, 5, 6, or 10 group, disable hot spares, then Replace Disks One by One. The new disk has to be larger than the one it replaces. The description changes to please-remove, you remove that disk, the NAS beeps twice, you insert the new disk in the same bay, and the group goes to Rebuilding. Wait until the disk is Good again. Their warning: do not remove any disk while the group is rebuilding. After every member you meant to replace has been rebuilt, Expand Capacity is a separate click, and the group then synchronizes. Do not power the NAS off during that synchronization. On QuTS hero h5.3 the shape is the same one-by-one rebuild, the RAID type cannot be RAID 0, hot spares come off first, and the article says the extra capacity is added when the last rebuild finishes. QuTS hero is ZFS. Moving those disks to TrueNAS to "just import them" is a different mistake.
Unraid. For a data disk no larger than the parity disk: parity check with zero errors, stop the array, unassign the disk, start once so Unraid emulates the missing disk, and confirm that emulated disk mounts and the files look right. Then stop, assign the new disk, start, and let the rebuild finish. If the emulated disk is unmountable, the rebuild copies that. Fixing it is the unmountable page, and it happens before the rebuild. Do not format the new disk if the WebGUI asks. Formatting writes an empty filesystem and then parity matches the empty disk. Keep the disk you removed, untouched, until you have confirmed the new one. If the new disk is larger than parity, the parity-swap procedure copies parity onto the new larger disk first — the array is unavailable for that copy — and then rebuilds the old parity disk into the data slot. That is two long reads. Check SMART on every array disk before either of them. With single parity, one disk at a time. Upgrading parity itself, with only one parity disk, leaves the array unprotected until the parity build finishes. Do not start that with a data disk already failed.
TrueNAS. Use the Storage screens. If you have an empty slot, TrueNAS's expand-by-replace steps say to insert the new disk and run Replace before you remove the old one, so the vdev does not lose a member for the length of the resilver. Same-slot replacement means offlining the old disk first, and that does reduce redundancy. The new disk has to be the same size or larger. Force, on the replace dialog, erases partitions on the replacement so the replace can proceed. Wait until the resilver finishes and the pool is Online before the next disk. TrueNAS does not grow the pool by itself when the last disk in the vdev has been replaced. Expand is a separate click after that last resilver, not a button to clear errors in the middle of one. Adding a disk to widen a raidz vdev is a different operation. OpenZFS says that expansion reads all allocated space and rewrites it, and that it pauses if a disk fails. It is not a quieter shortcut around a sick member. A scrub that already found checksum errors belongs on the scrub page before any of this starts.
If a second drive errors, stop
Read errors, pending sectors climbing, a disk that drops, or a rebuild that is still writing while another member is failing: the upgrade is over. Stop the rebuild if the screen lets you stop it without starting a repair. Do not force the bad drive online. Do not Deactivate another member. Do not click Repair again because the percentage froze. Do not Recover a QNAP group that has gone past what its RAID type tolerates. Do not zpool clear the counters and let the resilver continue. Do not Expand Capacity, and do not Expand the ZFS pool, to see if the new space appears. Do not keep swapping the remaining small drives. Do not delete the storage pool and create a new one.
On one disk of redundancy, a second member that cannot be read is the failure parity cannot cover. Unraid's manual says those read errors show up as corruption on the disk being rebuilt. On two disks of redundancy — SHR-2, RAID 6, Unraid dual parity, raidz2 — a second failure during a single-drive upgrade is the case Unraid's current page still calls protected, and it is the last disk of slack you had. It is not permission to continue the capacity project, and it is not permission to rebuild two disks at once because the first rebuild already went bad. Climbing read errors mean power the NAS down. A rebuild that keeps writing from a disk it cannot read stores the hole on the new member.
Synology's repair article says a pool that has gone Crashed can no longer be repaired by you. That screen is Volume Crashed, don't click Repair. A QNAP volume that is Not Active is don't click Recover. A share that is still open, with no second disk already failing a rebuild you started, is the read-only page. A second drive erroring in the middle of this upgrade is not that quiet window. Copying the whole volume through the member that is already returning errors is another full read of the same disk. If a disk is clicking, power it off. Several bays dropping in the same minute, during the rebuild or before it, are the path, not the disks.
Photograph the status if you can do it without accepting a repair: which bay, the RAID or SHR type, the exact wording, the percentage if one is on screen. Then leave it off. The disk you pulled, the new disk, and every disk still in the chassis all come. A drive goes back only to the slot it left, and only if you are not done with it. A PC that offers Initialize or Format is a wipe.
How a lab handles it
We do not finish the rebuild in the NAS. We do not force the second drive, recreate the pool, or swap the next member to see if the volume mounts. We do not run the resilver, the parity rebuild, or Repair on the original disks.
Each member is imaged write-blocked, as far as it will read. That includes the drive the UI called healthy, the drive that threw the read errors, the new disk the rebuild was writing, and the old disk you already pulled. The old one still has the member the new disk was only partly finished replacing. Work happens on the copies. A wrong guess about which disk failed costs a clone. The tools named on this site, including the ACE Lab PC-3000 and DeepSpar Disk Imager, image the drives. They are not a second NAS, and they do not make a marginal platter healthier by reading it harder.
The public case log does not have a job that arrived as a capacity upgrade. We will not invent one. The published Synology job is DDR-2026-0003: a four-drive RAID 5, already offline, two members failed, nothing rebuilt in the NAS, each member imaged and the array reconstructed from the images. Use it for what imaging looks like after a second drive is already down. Do not use it as a twin of a pool that is still Healthy tonight. We don't advertise a success rate.
If a disk has to be shipped, pack it like any other failed drive and keep the bay label on it. For the work itself, see RAID data recovery.
NAS capacity upgrade FAQ
Can I pull two drives at once if the pool is SHR-2, RAID 6, or dual parity?
The pool says Healthy and the last quick SMART test was Normal. Can I start?
zpool status for READ, WRITE, and CKSUM, and read the last scrub. A quick test that says Normal is the short one. Read the extended test, the bad-sector count, and the last scrub as well.I have an empty bay. Is Replace Drive different from pulling the old disk?
The volume is almost full. Does Fast Repair skip the empty space?
A second drive showed read errors during the rebuild. What do I do?
Is this the same screen as several drives dropping at once, or a volume that went read-only?
SHR will not grow until I replace two drives, or four. Do I have to finish the set?
Is there a capacity-upgrade case in the public log?
A capacity upgrade reads the old drives. If one of them is already sick, or a second drive errors during the rebuild, stop and find out what is left before anyone forces it. Start with a free evaluation.
Request free evaluation →Free evaluation · No data, no fee · Talk directly with a technician.