Hard Disk Recovery

A few weeks back I got a call from a woman who had lost the partition on her hard drive; she had all of the photos of her kids on that drive and was slightly hysterical about it. I had her download DART XP and run it on the drive; it found the partition and then showed her a full directory structure. This was great now she can get the pictures of her children back. I tell her just click the purchase button and put in your credit card information and you can then copy your files off. She asks me how much is the software and I tell her $99.00, she starts to cry. She explains that she doesn’t have the funds to justify spending a hundred dollars to save her personal photos. I was moved by that, because she was completely honest, so I asked if fifty bucks would be more attainable, she agreed that although it would still make her in a pinch that she could swing it. So I charged her card 50 dollars and then sent her a code for the software. It occurred to me though, that many of our customers may be suffering from this same problem and that during these times we might want to help out with a price reduction on our data recovery software. I spoke with my boss and he agreed that a drop in price for the time being would a huge help to our customers, so that they will be able to still retrieve their personal data. We hope this helps in some small way and if you need help using the data recovery software as always you can reach me at 727-345-9665 ext 236.

  Last time I discussed how to find the RAID data offset for a SNAP OS 4.x RAID handler.  To put it briefly it was just a simple matter of finding Cylinder Group zero on the first drive in the array and back tracking 48 sectors.  Once the RAID data offset is established we can plug those numbers into our RAID Diagnostic Toolkit and begin analyzing the parity. 

  The main objective of the parity check is to make sure that:

  1. We do not have a stale drive in the array

  2. We do not have a drive in the array that does not belong

  3. All RAID data offsets are correct.

  Lets take each item from one to three and explore their impact.  Item one basically means that there is a drive in the array that has not been functioning for a certain period of time.  Normally an alarm goes off, an email may be sent, there is some sort of notification that a drive has dropped out of the array and now the RAID is running in a degraded state.  When the technician who is administering the array does not get a warning it is usually because there has been some type of hardware malfunction that, although the drive is out of the array, the RAID BIOS does not sound the alarm.  A second reason is that the alarm stops working.  The little speaker on the RAID card that sends this terrible shrill through the server room is malfunctioning and nobody hears it.  Another reason might be that the original RAID administrator may have shut off all alarm notification flags during configuration and never turned them back on.  There are a lot of other reasons but the fact of the matter is that a RAID administrator may have a RAID that has been degraded for a year and not even be aware of it.

  Item two is rare, however, it happens enough to where you need to be concerned if you are trying to recover your RAID.  This item also is not very common in the SNAP line of servers as it is in DELL.  There are times when a RAID is configured as ‘X’ drives, and one hot swap.  The RAID admin who is now working for the company you are trying to recover the data for sends the RAID he tells you it has four drives when it is really three drives and one hot swap.  He may not know the original configuration.  He may not know how to get into the RAID BIOS to look to see how it was configured.  There could be a hundred and one reasons as to why you get a hot swap drive sent to you along with the rest of the array.  The point is, be aware that it can happen.

  As a side note, DELL has configure many of their RAID models to have two mirrored drives for the OS, and 3 to X drives as a RAID 5.  I have received all the drives from a client with them ’swearing’ that all of these drives are in the array.  Once I have analyzed the parity, and look at the drives through a hex editor I come to the realization that I have two RAIDS on my hands, not one.  Once again, be aware that the client may not know their exact configuration.

  Finally item three.  Sometimes, not often, actually this was the first time with a SNAP server, the RAID data offsets are staggered.  In my next installment I will explain what happened with this particular job, and why it happened.  Until next time.

Click here to Download the RAID Diagnostic Toolkit. Be sure to read the instructions on the page as well as follow the links to the instructions with screenshots. You may also visit our page: RAID Configuration and Parity Check for more information.

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