Just to follow-up.
I had 4 PERC RAID drives from a failed Dell PowerEdge. I had thought that the disks were healthy since the server left us after some kind of mother board failure. There was information stored there that would be nice to have and that was not backed up. No matter what kind of backup that you have in place there is always some way that it will fail you. While that information was not "critical", we had wanted to retrieve it.
Anyway I bought 4 powered SATA to USB adapters making the drives each accessible from a Windows 7 machine. They obviously were not recognizable by the system. I resisted all requests by Windows to format or initialize the foreign drives. Boy MS is persistent.
I tried a couple of software packages purporting to recover RAID drives. Both would analyze for some 24 hours and end up reporting failure. Even after manually configuring the possible RAID parameters they failed. It would seem to me that they would be able to tell just after a few minutes that things were not going to work out but... If asked I can discuss those. (Stellar data Recovery & ZAR X)
So I dropped down a level and grabbed a couple of hex editors that are able to open drives (Active Disk Editor & WinHex). Both editors seemed to be useful but one (WinHex) was much much faster in searching drives for specific data. I knew of a large text file (actually C source) that was stored on the server. So when I found that, I could look for the parts and reconstruct what the RAID configuration had to be for the file to be whole.
That server was installed a dozen years ago and even thought I did it, I could not remember how the RAID was configured. The documentation from then was not where it should have been. If you had asked me I would have thought it was RAID 5 even though today that's not the best choice.
With the hex editor I noted that 2 of the 4 disks contained a valid Master Boot Record (MBR). I then noticed that those 2 disks were copies of each other (mirrors). I confirmed that the other pair were mirrors. Okay, so RAID 10 which was a better choice.
I set a pair aside and continued to look at the presumed RAID 0 pair. The disk with the MBR would be Disk 1 and the other, Disk 2. The default block size for PERC is 64KB (128 sectors on these old drives). Since I had the hex editor I searched to find that large text file. Sure enough it was broken on 64KB boundaries and properly divvied up between the two drives.
At this point I could unravel the 2 drives into a single disk image with one of the packages I had acquired but the attempt didn't end up with the result I had wanted. I picked up another program (Runtime.org RAID Recovery) that would construct a virtual image file (VIM) with the parameters that I felt were needed. I then used their Captain Nemo program to open the RAID 0 drive pair.
So now I can browse the NTFS partitions and copy off the data. Yay! If I had good recommendations for the software to use the recovery would have been a bit more cost-effective. But it still didn't cost nearly what it would if we sent the drives out for recovery or otherwise acquire another Dell system. And in trying to mount the drives on another system you run the risk of those being reinitialized and old data destroyed.
A nice educational adventure. But now nothing has been lost whether or not any of it was absolutely needed. And... I have some good (and not so good) software tools should I ever need to do this again.
I had 4 PERC RAID drives from a failed Dell PowerEdge. I had thought that the disks were healthy since the server left us after some kind of mother board failure. There was information stored there that would be nice to have and that was not backed up. No matter what kind of backup that you have in place there is always some way that it will fail you. While that information was not "critical", we had wanted to retrieve it.
Anyway I bought 4 powered SATA to USB adapters making the drives each accessible from a Windows 7 machine. They obviously were not recognizable by the system. I resisted all requests by Windows to format or initialize the foreign drives. Boy MS is persistent.
I tried a couple of software packages purporting to recover RAID drives. Both would analyze for some 24 hours and end up reporting failure. Even after manually configuring the possible RAID parameters they failed. It would seem to me that they would be able to tell just after a few minutes that things were not going to work out but... If asked I can discuss those. (Stellar data Recovery & ZAR X)
So I dropped down a level and grabbed a couple of hex editors that are able to open drives (Active Disk Editor & WinHex). Both editors seemed to be useful but one (WinHex) was much much faster in searching drives for specific data. I knew of a large text file (actually C source) that was stored on the server. So when I found that, I could look for the parts and reconstruct what the RAID configuration had to be for the file to be whole.
That server was installed a dozen years ago and even thought I did it, I could not remember how the RAID was configured. The documentation from then was not where it should have been. If you had asked me I would have thought it was RAID 5 even though today that's not the best choice.
With the hex editor I noted that 2 of the 4 disks contained a valid Master Boot Record (MBR). I then noticed that those 2 disks were copies of each other (mirrors). I confirmed that the other pair were mirrors. Okay, so RAID 10 which was a better choice.
I set a pair aside and continued to look at the presumed RAID 0 pair. The disk with the MBR would be Disk 1 and the other, Disk 2. The default block size for PERC is 64KB (128 sectors on these old drives). Since I had the hex editor I searched to find that large text file. Sure enough it was broken on 64KB boundaries and properly divvied up between the two drives.
At this point I could unravel the 2 drives into a single disk image with one of the packages I had acquired but the attempt didn't end up with the result I had wanted. I picked up another program (Runtime.org RAID Recovery) that would construct a virtual image file (VIM) with the parameters that I felt were needed. I then used their Captain Nemo program to open the RAID 0 drive pair.
So now I can browse the NTFS partitions and copy off the data. Yay! If I had good recommendations for the software to use the recovery would have been a bit more cost-effective. But it still didn't cost nearly what it would if we sent the drives out for recovery or otherwise acquire another Dell system. And in trying to mount the drives on another system you run the risk of those being reinitialized and old data destroyed.
A nice educational adventure. But now nothing has been lost whether or not any of it was absolutely needed. And... I have some good (and not so good) software tools should I ever need to do this again.
Comment