RAID 10 Rebuild Started, Then Crashed: Preserve Both Array States

A RAID 10 rebuild that crashes can leave the original members and the rebuild target representing different points in the array’s history. The next step is not another rebuild. It is to preserve both states and determine which member of each mirror pair is readable and current.

What this condition means

RAID 10 stripes data across mirror pairs. A rebuild normally copies from the surviving member of the affected pair, but a crash may expose read errors, a weak source, a path or controller problem, or disagreement about which member is current.

If the target was partly written before the crash, it is not an empty replacement anymore. It may contain useful reconstructed regions alongside incomplete ones.

What to record

• Controller, server, RAID 10 member count, and stripe size if known
• Slot, serial number, and displayed status of every original and replacement drive
• Which member was replaced and its original mirror partner
• Rebuild start time, stopping percentage, and controller errors
• Power, controller, cable, enclosure, or firmware events before the crash

What not to do

• Restart the rebuild as a diagnostic test
• Discard or reuse the original failed member
• Erase or repurpose the partial rebuild target
• Force different members online by trial and error
• Run filesystem repair on an unvalidated reconstruction

How ADR evaluates it

ADR identifies mirror-pair membership, member generation, readable coverage, and the changes introduced by the interrupted rebuild.

The original and partial-rebuild states are compared away from the failed controller. Reconstruction proceeds from protected sources and is validated before data is written to separate destination storage.

What happens next

A crashed RAID 10 rebuild can remain recoverable when every original and replacement member is preserved. The result depends on readable coverage and whether a current member remains available for each required stripe.