Why Is RAID Capacity Still Unchanged After Replacing Every Drive?

RAID capacity can remain unchanged even after every physical disk has been replaced with a larger one because the replacement process and the expansion process are separate. First confirm that all required members are larger and fully rebuilt. Then check whether the RAID device, virtual disk, partition, storage pool, and filesystem have each been expanded. If any layer still ends at the old boundary, the NAS will continue to report the old usable capacity.

Confirm That Every Required RAID Member Is Actually Larger

Start with the array member list rather than the drive labels on the trays. Record each disk model, serial number, reported size, bay, and RAID role. A classic mirror or parity group normally cannot expose more space than its smallest active member, so one old disk, one undersized replacement, or one member that was never accepted into the array can keep the entire group at its previous size. This is also why replacing only one disk in a mirror usually improves replacement readiness without increasing usable capacity.

Do not rely on a “healthy” dashboard badge alone. Verify that the replacement disk is an active member, not a hot spare, unused device, or failed candidate. Confirm that the rebuild or resilver reached 100 percent and that the array returned to a redundant state before the next replacement was started. The related ZimaSpace guide on expanding a mirror with larger drives one at a time explains why capacity normally remains fixed until the replacement sequence is complete.

If the NAS reports the replacement as the old size, inspect the partition table or controller view of that member. Some arrays use partitions rather than whole disks, and a copied partition layout may preserve the old endpoint. Some controllers can also expose a virtualized or truncated size instead of the drive's full native capacity. Fix the member-size mismatch before attempting to grow the array, because expanding above an inconsistent foundation can leave the storage stack harder to recover.

Check Whether the RAID Layer Has Been Expanded

A larger physical member does not automatically make the RAID device larger. Think of the storage path as separate layers: physical disks, RAID device or virtual disk, partition, storage pool or volume manager, and filesystem. The first layer can show the new size while every layer above it still ends at the old boundary. The correct diagnostic question is therefore not “Are the new disks visible?” but “At which layer does the reported size stop increasing?”

Software RAID often needs a separate grow operation after every required member has been replaced. One practical mdadm expansion walkthrough shows that the array can remain at its old size until an explicit grow step is performed. Appliance-managed NAS systems may present the same action as Expand, Grow, Maximize Capacity, or Resize RAID Group. Hardware RAID may require expansion of the virtual disk before the operating system can see additional sectors.

Only start the grow operation when the array is clean, redundant, and free of unresolved read, timeout, or reset errors. Save the current array status and confirm a separate backup of irreplaceable data. Expansion writes metadata and may run for hours; starting it while the array is degraded or while a drive is repeatedly disconnecting turns a capacity problem into a data-integrity risk.

Distinguish an Unfinished Rebuild From a Missing Expansion Step

An unfinished rebuild and a missing grow action can produce the same headline symptom, but the evidence differs. During an unfinished rebuild, the new disk may still be syncing, the array may be degraded, and the expected member count or redundancy level may not be restored. With a missing expansion step, every member is active and healthy, yet the RAID device still reports exactly the old size.

Compare the size at each layer before changing anything. If one physical member is smaller, solve the member mismatch. If all members are larger but the RAID device is old, use the RAID-level expansion control. If the RAID device is larger but the partition or filesystem is old, stop touching the member disks and work upward instead. Users commonly mistake a higher-layer resize problem for a failed disk replacement and unnecessarily repeat the riskiest part of the process.

A completed rebuild also does not prove that free space was committed to the array. A Super User discussion of larger replacement disks reinforces that larger replacements alone do not change the RAID group size. Treat that pattern as a diagnostic clue, not a universal command sequence: the exact operation depends on whether the NAS uses mdadm, ZFS, Btrfs, LVM, a hardware controller, or a proprietary storage manager.

Expand the Partition, Pool, and Filesystem in Order

Once the RAID device itself reports the larger size, inspect the next layer without skipping ahead. A partition can still end at the old sector even though the underlying array is larger. If the storage stack uses a partitioned RAID member, extend the correct partition while preserving its starting sector and type. If the RAID device feeds a volume manager or storage pool directly, rescan that layer so it can recognize the new extent.

Partition layout matters during disk replacement as well. A Server Fault discussion of replacing mdadm members highlights that replacement partitions must expose enough space before the array can use the larger capacity. Do not copy a destructive command from another system. Capture the current start and end sectors, filesystem type, mount points, and volume-manager relationships before resizing.

Grow the filesystem last. The filesystem can only use space that the RAID device, partition, and pool already expose. After the filesystem operation completes, compare the block-device size, filesystem size, mounted free space, and NAS dashboard. A consistent increase across all four confirms that the expansion reached the user-visible storage layer rather than stopping midway.

Know When the Existing RAID Layout Cannot Grow

Some RAID implementations cannot expand an existing virtual disk after member replacement, even when every disk is larger. Others support growth only for certain RAID levels, member counts, partition layouts, or firmware versions. A static volume may require migration to a new array, and a controller may expose the extra sectors only by creating an additional logical volume rather than enlarging the original one.

Stop when the system offers no documented or clearly verified growth path, when the array reports media or link errors, or when the only proposed action would recreate metadata without a tested backup. The safer alternative is often to create a new correctly sized array, copy and verify the data, switch services, and retain the old storage until restore checks pass. The ZimaSpace article on setting a home NAS backup schedule can help separate array availability from recoverable copies.

The expansion is complete only when the array is redundant, every required member is healthy, the RAID device exposes the expected larger block range, the upper storage layers match it, and real files can be written, read, and checked. If the physical disks are larger but the RAID implementation cannot grow, the unchanged capacity is a platform boundary rather than a failed replacement.

FAQ

Will one larger drive increase RAID 1 capacity?

Usually no. A traditional two-disk mirror normally remains limited by the smaller active member. Replace the other member, complete the rebuild, and then perform any required array, partition, pool, and filesystem expansion.

Should I reboot after replacing all RAID drives?

A reboot may refresh device detection on some systems, but it does not replace a required grow operation. Check the reported size at every layer before and after rebooting so you do not confuse rediscovery with expansion.

Can I keep using the NAS while the array grows?

Many systems allow access during online growth, but performance may drop and risk increases if another fault appears. Maintain a verified backup, reduce heavy writes, monitor errors, and follow the limits of the specific RAID implementation.