RAID 6 Rebuild Failed or Another Drive Is Failing
Two unavailable members do not automatically mean a RAID 6 has exceeded its protection. The crisis begins when a rebuild cannot complete, another member starts failing, or the required business data becomes inaccessible.
At that point, another rebuild or drive replacement is not a harmless test. Preserve every original and replacement member and stop before the controller writes another version of the array.
The failed server does not need to boot, the volume does not need to mount, and the RAID 6 does not need to be brought online before recovery can begin.
- Do not restart a stalled or failed rebuild.
- Do not replace another member to see whether the rebuild will continue.
- Do not force a failed, foreign, or uncertain member online.
- Do not initialize, recreate, or clear the virtual disk configuration.
- Do not run a consistency check or filesystem repair against the uncertain array.
- Do not discard the original failed member or a partial rebuild target.
If it can be done safely, capture the controller screens, rebuild percentage, error messages, and the location of every original and replacement drive.
Tell a technician which members were unavailable, where the rebuild stopped, what the controller reports now, and whether the volume is still accessible.
Why two failed drives are not the whole diagnosis
RAID 6 is designed to reconstruct with two unavailable members, provided the remaining members are readable and represent one consistent array state. A controller label does not establish either condition.
A rebuild may expose unreadable sectors or timeouts on a surviving member. A drive may be excluded because of metadata, path, power, or controller problems rather than complete physical failure. If the rebuild wrote part of the replacement before stopping, the original member and the partial target may now represent different points in the array’s history.
The question is no longer simply how many drives show failed. It is which members remain readable, what the rebuild changed, and whether a consistent volume can still be reconstructed.
What ADR needs from you
- The server, enclosure, and RAID controller brand and model.
- The total number and capacity of the drives.
- Each original and replacement drive’s bay, serial number, and displayed status, if known.
- Which member failed first and when the rebuild began.
- The rebuild percentage where it slowed, stalled, or stopped.
- Any medium errors, predictive failures, timeouts, foreign configurations, power events, or controller changes.
- Whether the volume is still accessible and which files, databases, or VMs are required first.
If some details are unavailable, start with the controller and server model, drive count, what happened in order, and what the system shows now.
How ADR evaluates the interrupted RAID 6 state
ADR reviews the failure and rebuild sequence before selecting members for reconstruction. Every original and replacement member is preserved because a partial target may contain useful rebuilt regions while an original member may retain data the target never received.
The controller is removed from the recovery path. Members are accessed independently, and unstable sources are protected through imaging before reconstruction. ADR then evaluates member generation, order, data offset, stripe size, dual-parity rotation, readable coverage, and the changes introduced by the interrupted rebuild.
The RAID 6 is reconstructed away from the original sources and validated against the required filesystem, database, virtual machine, or files before recovered data is written to separate storage.
Is the data still recoverable?
It may be. A failed rebuild or another member error does not by itself prove the data is gone. The result depends on readable coverage across the member set, what the rebuild wrote, and whether ADR can establish a consistent array state for the required data.
Preserving every member now gives the recovery the greatest range of possible source states to evaluate.
Call ADR or submit the member count, failure order, rebuild percentage, controller messages, and current access state.