RAID Rebuild Failed and the Array Is Unavailable

The rebuild has stopped, failed, dropped another member, or left the required volume unavailable. Do not restart it to see whether the controller can finish.

Keep the original failed member, the rebuild target, and every other member exactly identified. The original set and the partial target may now contain different portions of the most recoverable array state.

The failed server does not need to boot, the volume does not need to mount, and the rebuild does not need to resume before recovery can begin.

A slow rebuild and a failed rebuild are not the same

A rebuild can take a long time, especially with large drives and an active workload. A percentage that changes slowly, by itself, does not prove that recovery intervention is required.

The danger boundary is different: progress has stopped, the controller reports read or write errors, another member has dropped, the virtual disk has gone offline, or the required volume can no longer be accessed. Those conditions mean the rebuild is no longer providing a safe administrative path.

Why the original member and partial target both matter

A rebuild reads the surviving members and writes reconstructed stripes to the target. If it stops partway through, the target may contain valid reconstructed regions followed by incomplete or unwritten regions. The original failed member may retain older but still readable data that the target never received.

Neither drive should be treated as disposable. ADR can compare their readable coverage and array generation while determining which combination best represents the data the business needs.

What ADR needs from you

• The server, enclosure, RAID level, and controller brand and model.
• The number and capacity of the drives.
• The bay, serial number, and displayed status of every original and replacement member, if known.
• Which member was replaced and when the rebuild began.
• The percentage and elapsed time where progress stopped.
• The controller errors, medium errors, timeouts, power events, or member changes that followed.
• Whether the array is online, degraded, offline, or missing—and which data must be recovered first.

If the sequence is incomplete, start with what the controller shows now and what you remember changing. Do not delay contact while trying to reconstruct a perfect history.

How ADR evaluates a failed rebuild

ADR begins by establishing what the rebuild read and wrote before it stopped. Each original and replacement member is accessed independently, and unstable sources are protected through imaging when required.

The original and partial-rebuild states are compared outside the failed controller. ADR determines member identity and generation, readable coverage, drive order, data offset, stripe geometry, parity rotation, and the most defensible reconstruction for the required volume.

The resulting filesystem, database, virtual machine, or priority files are validated before recovered data is written to separate destination storage.

Is the data still recoverable?

It may be. A failed rebuild does not prove that all required stripes are unreadable. The result depends on the surviving members, what the rebuild changed, the readable regions available across the original and replacement drives, and whether a consistent array state can be reconstructed.

Another uncontrolled rebuild can reduce those options. Preserving both states keeps them available for comparison.