An array that loses a disk is not necessarily a lost volume. What can be recovered from the surviving member depends on the RAID level and on how many disks are still present: a mirror member holds a complete copy, a stripe member holds only every other block, and a parity member can rebuild the others only when its partners are available.
A RAID 1 mirror writes identical data to every member, so a single surviving disk is a complete copy and can be read like an ordinary disk once it is detached from the controller.
A RAID 0 stripe alternates blocks across the members. One disk therefore holds only part of every file, and files smaller than the stripe size may be missing entirely while larger ones are recoverable in fragments.
A RAID 5 set mixes data and parity. With all but one disk present, the missing blocks can be calculated; with only one disk left, that disk still holds its own share of the data, and files that happened to land whole on it can be recovered.
Record the controller model, the RAID level, the stripe size, the member order, and the data offset. Those values are what lets a tool put the pieces back in the right sequence, and they are easier to find while the controller still lists the array.
Do not let the controller initialise the array. An initialise on a degraded set writes fresh parity and destroys the remaining usable blocks, and it is offered by some controllers as the automatic response to a disk that reappears.
Label each disk with its slot number before you remove it. Once two drives of the same model sit on a desk, the order is the only thing that cannot be guessed later.
For a mirror, connect the disk to a normal SATA port and read it directly. The volume is intact, and only the file system needs checking.
For a stripe, connect the single disk and scan it for file signatures. Expect a lower recovery rate and fragmented results, because the file system metadata is spread across the missing members.
For RAID 5, the best route is to recover the other members first and rebuild the array in software. If only one disk survived, scan it and accept that the result is partial.
Qiling Deep Data Recovery can scan a member disk as a standalone device. On a mirror that scan is a normal recovery; on a stripe it is a signature based search that finds whatever complete files remain on that disk.
Use Fast Scan when the member disk carries a readable partition from a mirror. Use Format Scan for a stripe member whose partition table lives on another disk.
Select the disk by capacity and serial number. Never include a disk that is still part of a live array, because the controller may write to it during the scan.
Preview files before selecting them and expect gaps. Files that preview correctly were stored whole on this disk; those that fail likely span a missing member.
Write the results to a disk that is not part of the failed set. Keep that copy until the array has been rebuilt or the data has been migrated elsewhere.
No. Half the blocks, or more, live on the other members. Recovery from a single stripe member is always partial.
Not until the data is copied. A rebuild writes across every member, including the one that still holds usable blocks.
It decides which files were stored whole on a single member. A larger stripe size makes more small files recoverable from one disk.
The data can be read, but the layout has to be described to the tool. That is why the stripe size and member order should be recorded while the controller is still working.
For the related case of a pool rather than an array, see recovering files from a Storage Spaces volume.