Why a RAID Rebuild Restarts After a Disk Disconnects

A rebuild can restart after another disk disconnects because the array’s trusted member set changed again. The controller may discard partial progress and regenerate redundancy from a new consistency point.

A brief disconnect is not harmless during degraded operation. The correct response is to identify which serial-numbered member dropped, preserve logs, confirm the array still has enough valid copies, and stop experimenting with cables or bays until the current recovery state is understood.

The Second Disconnect Creates a New Recovery Event

A rebuild is based on a specific set of source members and a target disk. If another source disappears, even briefly, the array can no longer assume that every block already written to the target matches the current live set. Writes may also have continued while that member was absent.

Controllers handle this differently. Some resume from a bitmap or checkpoint; others restart a full reconstruction. The rebuild after reconnecting a disk discussion shows why removing a member changes fault-tolerance state even when the disk still contains most of the old data.

Dirty Metadata Can Make an Old Member Look Stale

RAID members normally store array metadata that identifies their role and event history. When a disk vanishes while writes continue, its contents become older than the active array. Reconnecting it does not make those missed writes disappear, so the controller must reconcile or overwrite stale regions.

A temporarily removed RAID member may be recognized from its metadata, but the implementation still decides whether it can rejoin directly or needs synchronization. Do not assume that returning to the same bay preserves trust.

Why Progress May Return to Zero

The percentage often describes the current recovery pass, not a permanent ledger of all blocks ever copied. If a source member changes state, the target is reassigned, or the controller reassembles the array, the displayed operation can restart from zero even if some target blocks already match.

On software RAID, a new degraded event can require a complete resync. A documented second full RAID1 rebuild demonstrates that once an md array enters degraded state, it may synchronize the entire member rather than trust an earlier partial state.

Do Not Pull Another Disk to Test the Theory

During a rebuild, every remaining source is part of the only path to reconstruct missing data. Pulling another member for identification can exceed the RAID level’s fault tolerance or create competing versions of data. Locate disks by serial number and enclosure indicators, not by trial removal.

Stop hot-swap experiments until the array is either healthy or copied to safe storage. If a cable or bay is suspected, collect the event log first and plan a single controlled change with the system quiesced when the hardware does not explicitly support online service.

Check Whether the Rebuild Truly Restarted

Compare more than the percentage. Record the operation name, target serial, source-member count, event or generation number, processed blocks, current speed, and estimated finish time. A controller may switch from rebuild to parity initialization, verification, or background consistency check.

If the member set changed, treat the new percentage as a fresh event. If only the interface reset while counters continue, it may be a display issue rather than lost progress.

When a Reboot Is Less Important Than a Disk Drop

A planned reboot does not necessarily invalidate a controller-managed rebuild. Many controllers persist enough state to resume safely. The more serious event is losing another source disk or introducing a foreign configuration during or after the reboot.

A reboot during a rebuild can be recoverable, but the safe conclusion depends on the controller status after startup. Never initialize or import a foreign configuration merely because the percentage reset.

What to Do Immediately

1. Pause nonessential writes and capture the array, enclosure, and operating-system logs.
2. Map every active, missing, rebuilding, and spare member to a physical serial number.
3. Confirm the RAID level still has enough valid source members to reconstruct data.
4. Check SMART and link-error counters on the disk that disconnected and its connection path.
5. Let one stable rebuild run without additional cable, bay, reboot, or workload experiments.

If another source reports unreadable sectors or repeated disconnects, prioritize copying irreplaceable data or imaging members rather than repeatedly forcing a rebuild.

FAQ

Will reconnecting the same disk always restart the rebuild?

No. Some controllers can rejoin it or resume from a bitmap. Others regard the member as stale and start synchronization again. The event log and member generation data decide which case occurred.

Does a reset percentage mean the new disk was erased again?

Not necessarily. It can mean the controller started a new pass or changed operation type. Do not infer data loss from the percentage alone; inspect the target identity and event messages.

Can I keep using apps during the restarted rebuild?

Light use may be supported, but reduce avoidable writes and latency-sensitive jobs. The array has already shown a second connectivity event, so stability and data protection take priority over normal throughput.

The Practical Answer

A rebuild restarts because the consistency assumptions changed when another member disconnected. Stabilize the hardware path, verify the source set, and allow one uninterrupted recovery instead of testing the array while degraded.