A RAID 1 pair pulled from a dead PC and connected to a new machine, with no access to any of the files. Both disks were physically healthy. The array configuration had been reset and no rebuild had ever taken place.
← All case files · from £500 + VAT
The client's old PC failed, so they did the sensible thing: removed the two RAID 1 members and connected them to a replacement machine, expecting to read the data straight off. Neither disk presented anything usable.
A mirror member normally does mount on other hardware, because each disk holds a complete copy of the file system with a little array metadata attached. When it does not, the question is what happened to that metadata rather than what happened to the disks.
The software RAID configuration had been reset. Critically, no rebuild had taken place afterwards — which is the detail that made this recoverable rather than damaging.
A reset configuration followed by a rebuild would have written across one member using the other as a source, and if the wrong direction had been chosen the good copy would have been overwritten. Here the reset happened and nothing followed it, leaving both disks holding their original content untouched.
The data was recovered in full from the imaged members and delivered on a new external drive.
This job is a useful illustration of why the instruction after an array failure is always to stop rather than to attempt a fix. The client did exactly the right thing without knowing it — they moved the disks and, when it did not work, stopped instead of trying a rebuild on the new machine.
Losing an array configuration is recoverable. Rebuilding after losing it may not be, because a rebuild in the wrong direction overwrites the surviving copy.
Each RAID 1 member usually holds a complete file system. If one mounts on another machine, copy the data off before doing anything else at all.
Connecting array members to another machine to look does no harm. Accepting any offer to initialise, import or rebuild is where the risk begins.