Recently, it was my task to take sixteen drives, spanned across three RAID fives, and recover a set of hundreds of AVI files. These files were used for research and although not time sensitive, were critical to the conclusions of the research.
We have been asked to do many similar jobs where the archive of a set of data has been compromised. Many lawyers have databases of all of their scanned briefs as well as all documentation pertaining to a particular case. If that information is lost and the case reopened for appeal it could be devastating to not be able to review the documentation in a timely manner. I mention this because it took me over a month to complete this task, and although interesting, was very tedious.
What made this recovery interesting was that the drives were in two physical devices. The first device was a four drive SNAP array that was used as the head. The other device was a twelve drive SNAP server that was broken up into two RAID fives. The challenge for this recovery was that no one knew which drives were in which array, no one knew the drive order of any array, the configuration given to me by the SNAP server was in error, no one knew the stripe size of the array, and finally, the data recovery company who had the array before me, marked the drives out of order. In other words, I was handed 16 drives and told to figure out a triple spanned RAID five.
So here are the steps I took to solve this data recovery problem for my client.
Step one, I had to find out which drives went with each other. I would have hoped that each RAID was equal in size. In other words, I hoped the RAIDs would all be four drives for the head in one array, and eight drives each for the other two RAIDS, but this was not the case. In order to find which drives went with which array I had to know several things.
First, I had to know the SNAP layout for arrays. Each drive in a SNAP array is basically broken up into two parts, the operating system, and the data area. In order to find the size of each you must look at the master boot record (MBR) of each of the drives. The MBR houses the partition table which is a listing of the active partitions.
SNAP partitions are divided into three basic areas, an operating system partition, a swap partition and a data partition. SNAP Appliance designed their device so that if one of the drives went down the firmware would roll to the next drive to load the operating system, network interface, and RAID handler. The important piece of information is what the standard offset to the data area is. The data area of each drive is used for the RAID 5. I have found the data area sector offset for the Guardian OS series to be LBA sector 2216970. This information may change from version to version, but all the Guardian operating systems I have worked with have been the same.
Now that we know the data area offset we can take the next step, which is to determine which drive sets comprise the three RAID sets.
To be continued……..