I’ve often heard it said, “the RAID has been rebuilt – the data cannot be recovered” and often this is the case. With RAID5, if the configuration is changed, and new parity is calculated, then there will be a significant loss of any data that was previously stored on the RAID.
As Hamlet so eloquently put it “There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy.”, just because something is outside of our normal experience does not mean that it is not possible.
One such case landed at our offices recently, 4 disks in a RAID 5 with apparently corrupted data files. Once the drives had been imaged and the data secured we set about examining the RAID and it all looked pretty good. The RAID scheme was a standard last to first data striping with parity shifting first to last every 256KB, and the file system appeared to be perfect.
Then we looked at the MS-Exchange EDB files. The PRIV.EDB started fine then after a while the EDB page checksums were all wrong. The PUB.EDB file did not even start with the correct header pages, though the data did have the appearance of Exchange Information Store data. Examining the data in free space for Exchange EDB headers we did find one for an EDB from the required date.
So, the file system was perfect but the data was not quite right, maybe not corrupted as such, but shifted.
At this point we had not looked further down the disk, but now we started to examine the data in more depth. A second data partition existed on the volume, but on the current RAID configuration the file system was not correct. We could find our way from the boot sector to the MFT, but then after a few sectors the entry numbering went awry. The RAID configuration was different for the second partition.
It is not usual for a RAID to be in this state, so it appeared to us that perhaps the RAID had somehow been re-configured, and that this explained the data issues on the first partition. Sure enough checking the allocation information for PRIV.EDB it was apparent that the data was correct if it was from a low numbered set of file system clusters, but incorrect if it was from high numbered ones, so perhaps the re-configuration had stopped after the bulk of the file system information for partition 1, but not before the end of the data.
Not finding the notion of playing spot the configuration change somewhere in the midst of a large volume of RAID data we set about a new approach.
We had 2 RAID orgnisations, one that worked for partition 1 up to a point and one that probably worked from somewhere in the middle of partition 1 though partition 2. The customer had a set of EDB files that they rather needed back and straddled the point where the RAID configuration changed.
We created 2 versions of the RAID data using each configuration and then extracted the required files. EDB files have page checksums. And it is possible to work out the page number, so processing an EDB file you can tell if the data is almost certainly correct. So the next stage was to process each EDB, check each page, and for any that failed check the equivalent page for the alternate file.
The result was stunning, EDB files that not only could be processed using the checking options of eseutil (the Exchange utility program) with minimal errors, and that could then be accessed via Exchange and all mail items examined.
Looking at this as a standard RAID data recovery the answer would have been “your data has gone forever”. Utilities such as R-Studio and Winhex could be used to access the data from the file system, but not to recover the files as the customer needed them, so anyone just playing point and shoot with a recovery utility would be on to a loser.
The answer for this recovery was to examine the data, to really check what was there and to not let preconceptions prejudice the outcome. By finding the facts, and letting them determine the course of the recovery and not letting the demons of “that cannot be possible” cause a distraction, the data was saved.