RAID 5 with Two Failed Drives: What to Do Next
A RAID 5 array normally survives one missing member. When a second member drops, the controller can no longer assemble every stripe from the remaining data and parity. That makes the volume unavailable, but it does not automatically mean that two drives are physically dead or that every file is lost.
Do not initialize it, recreate it, clear foreign metadata, force a member online, or start another rebuild. Record the slot order and controller messages, then shut the system down if it can be done safely.
Tell an ADR technician what the controller reports and what has already been attempted. The failed array does not have to be brought online first.
What “two drives failed” can actually mean
Controllers use the word failed for several different conditions. A drive may be unreadable, intermittently timing out, missing after a power or cabling event, rejected because its metadata no longer matches, or excluded during an unsuccessful rebuild. Those conditions do not have the same recovery implications.
The sequence matters. One member may have accumulated unreadable sectors for weeks before the controller dropped it. A rebuild then places sustained load on the surviving members, exposing a weak sector or timeout on another drive. In other cases, both members are readable and the failure is primarily configuration-related.
What to record before the system is changed
- The server, enclosure, and RAID controller model.
- Every drive’s slot, serial number, and current controller status.
- Which member was reported first and what happened immediately afterward.
- Any replacement, rebuild, import, firmware update, power cycle, or repair already attempted.
- The exact virtual-disk, foreign-configuration, and physical-disk messages shown by the controller.
Photographs of the installed order and controller screens are useful. Do not remove labels or rearrange members while documenting the system.
Why another rebuild is not a diagnostic test
A hardware rebuild reads across the member set and writes reconstructed blocks to a target drive. It assumes that the selected source members, order, geometry, and parity state are trustworthy enough to support those writes. After a second member has dropped, that assumption needs to be tested rather than accepted.
If a surviving member is unstable, a rebuild can increase read stress and stop partway through. If the wrong member is forced online or the wrong configuration is imported, the controller may present a plausible but incorrect array. Filesystem repair performed on that state can then change structures that would otherwise help identify the correct reconstruction.
How ADR evaluates the recovery path
The first objective is to understand the state that exists now. ADR reviews the failure sequence, controller information, member identity, and signs of physical instability. Members that need protection are imaged to separate destination storage before logical reconstruction.
Reconstruction is performed away from the original array. The work may include determining member order, data offsets, stripe size, parity rotation, and the most defensible point in the array’s history. The resulting volume is then checked at the filesystem and file level, with priority given to the business data the client actually needs.
Is recovery still possible?
Often, yes. The answer depends on how much of each member can still be read, what the controller or previous recovery attempts have written, and whether enough consistent stripe data remains. A failed status by itself is not enough to make that determination.
If the array contains business-critical data, the safest next step is a technician review before another controller operation. ADR can determine whether the case is suitable for remote work, requires protected imaging, or needs physical escalation.