If you are in this business long enough you will see everything, or will you?  Two weeks ago I received a SNAP RAID OS 4.x for recovery.  I have done a lot of these and I am pretty familiar with the data offsets, how the drives are setup, and where to begin the virtual RAID for my software.  Having said that, these are the steps I normally take, and the results from those steps.

First thing I do is to make images of all four drives.  These were four identical Seagate Barracuda ST380011A hard drives, so I made sure I had at least 320GB of space on one of my partitions on my server and, using WinHex dumped the images.  Once I had done this I put the clients original drives in their bin hopefully not to use them again.

Next step is to use WinHex and eyeball the beginning of the RAID data.  With SNAP OS this is a simple matter of looking for the first cylinder group on the first drive then subtracting forty eight sectors from that.  The assumption is that the block size is 8192 bytes, or sixteen sectors.  If we were to look sixteen sectors before the first cylinder group you would see the file system superblock.  If we skip back another 16 sectors you see another super block.  Finally, another sixteen sectors and there should be a null sector.  Sometimes I see data in there but that is usually because the drive has somehow been corrupted.

So, once again, to find the beginning of the RAID data segment you find the first cylinder group and subtract forty eight sectors from that.  The sector offset derived from that formula is the beginning of the RAID data segment of each drive.  They will be the same on all four drives or at least I thought that until this particular recovery.

Next step will be to check the drive parity which, in this case, was unusual. This step will be in the next blog titled “Analyzing RAID parity“.

For more info on RAID Data Recovery or SNAP Data Recovery

Tags: RAID Recovery Explained SNAP Recovery