RAID 5 Has Two Failed Drives and the Data Is Inaccessible

A second unavailable member puts a RAID 5 beyond its normal fault tolerance. The volume may be offline, but that does not prove that two drives are physically unreadable or that the data is gone.

Do not use another rebuild, force-online command, initialization, or configuration import to find out. Preserve the array as it is and let ADR evaluate what remains.

The failed server does not need to boot, the volume does not need to mount, and the array does not need to be brought online before recovery can begin.

What “two drives failed” can actually mean

Controllers use the word failed for several different conditions. A member may be physically 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. One member may have been stale or partially unreadable before the second member was dropped. A rebuild may have exposed a weak sector on a surviving drive. In other cases, both members remain readable and the failure is primarily a configuration or array-state problem.

That is why the next step is to determine what each member can still provide—not to ask the controller to make another write-based decision.

What ADR needs from you

• The server, enclosure, and RAID controller brand and model.
• The number and capacity of the drives.
• Every drive’s original bay, serial number, and current controller status, if known.
• Which member was reported first and what happened immediately afterward.
• The exact virtual-disk, foreign-configuration, and physical-disk messages shown by the controller.
• Any replacement, rebuild, import, force-online command, firmware update, power cycle, or repair already attempted.
• The data or systems that must be recovered first.

If some of that information is unknown, do not delay contacting ADR. Start with what you can see and what you remember.

How ADR begins the recovery

ADR begins with the state that exists now. We review the controller information, failure sequence, member identities, drive order, and anything already attempted.

The original controller is removed from the recovery path. Each member is accessed independently through a controlled recovery environment. When a member is unstable, it is protected through imaging before logical reconstruction begins.

The reconstruction is performed away from the original array. ADR determines the most defensible member order, data offset, stripe size, parity rotation, and usable point in the array’s history, then validates the resulting volume and the files the business needs.

Do all of the drives have to be shipped?

Not automatically.

When the members can be accessed safely onsite, they can be connected independently to a suitable bootable computer or another case-appropriate recovery environment while the drives remain at your location. ADR can then assess the members, protect readable data, and perform the logical reconstruction through that controlled environment.

If one member requires firmware, electronics, mechanical, cleanroom, or other specialist work before a trustworthy image can be produced, ADR will identify that need before recommending shipment. When the case permits, the escalation may be limited to the affected member.

Is the data still recoverable?

It may be. The answer depends on what can still be read from each member, what the controller or earlier attempts wrote, and whether enough consistent stripe data remains to reconstruct the required volume.

A controller’s failed label cannot answer those questions. A member-level assessment can.

If the array contains business-critical data, preserve the current state and speak with a technician before another controller operation.