Data Recovery service from failure storages in Finland
This May I received the invitation to work for Finnish company IT Tohtorit, dealing with recovery of faulty data carriers. The invitation is conditional on the fact that, broading the field, the company has started receiving heavily damaged or insufficiently explored hard disks that needed the users' data recovery. A lot of discs with scratches on the surface, SSD-discs, flash cards, RAID arrays and many other cases. In one month more than 30 carriers were successfully recovered by me. I'd like to tell more about some interesting cases. The Mc-book HDD Fujitsu MHV2060BH 60Gb. Moreover, the HDD knocks at power on, moreover, the file system is MAC OS, and when opening we see posh scratches on the upper platter.
Faulty Fujitsu MHV-series
Scratches on the surface
To imagine the approximate state of unseen platters first of all I had to take away the magnetic head assembly and inspect the heads surface through the microscope. Presence of breaks on any heads stands for scratches under corresponding surfaces.
Heads through the microscope
After having understood the character and size of physical damage we could plan further steps.
In that case the data recovery process was to be done step by step. At first the platter with scratched surface was taken away, then the serviceable magnetic head assembly from the spare disc was installed to read the HDD overhead information. Then the heads map and a table of logic blocks with heads compliance was to be developed. After that all the LBA of undamaged surfaces were read out and we tried to read out all possible data from the scratched surface.
Taking into account location of scratches and being aware of tracks location in the logical ascending order we are able to foresee at some probability rate the areas of LBA under heads being scratched.
Finally I managed to restore the user's data. First of all, continuous data arrays under the heads were rather large, so it was in my favor, fragmentation on Macintosh was very low and the user needed photos, files with them are not very large in size (comparatively).
Data recovery from memory flash card Kingston SD 512Mb.
The flash cards I receive for recovery are few among all these hard discs. A customer from Spain. He has sent the flash card be the UPS mail service, on which there were some valuable photos from the kite festival on the sea coast. Of course, he can't make new ones - there will be no such festival again, and the photos are really interesting. I remembered the best the air rodeo with a kite in the form of a black bull.
The memory card is based on memory chip Samsung K9G4G08U0A and microcontroller Phison UT0645.
Flash card Kingston SD has been broken
For those who has this flask card along with this controller I have the solution for
1) Invert
2) Block_pair 0x42000/0x840
3) Block_rotate
Block_size = 0x84000
marker 512/513
mask 0x0ff0
marker inverted subblock_size =0x2100
Data recovery from Maxtor HDD
Long ago, a lot of Maxtor disks were being received for recovery. People liked to buy them, and the disks returned breakdowns for it. Users who have got them recovered can' complain: everything was being recovered easily.
But since then a lot of time passed. Maxtor HDDs are seldom brought for information recovery, those that I ever had for repair are already broken and lost forever. The Maxtor company as manufacturer HDD does not exist any more. Those HDDs labeled as Maxtor are Seagate HDDs as the Seagate company bought an old hard discs producer Maxtor and continued its nice tradition on making low quality devices (see Seagate 7200.11)
But sometimes an old kind well-known HDD is brought for data recovery to my shop. Only there is no " easy way for data recovery " any more. The situation is approximately the same as with my favourite Seagate 11 range row. Those have recently started to get " the second life" and failing reason is not microprogram failure but HDD low-standard accessories. The user information recovery with Seagate 7200.11 becomes harder from day to day. The situation with the old Maxtor is even more complicated.
Look at this old kind N40P. The motor accelerated, HDD did not answer in the safe mode. The problem analysis showed that SA was almost unreadable. I tried to record the same sector in SA self test logs and preliminary initialized the record since a disk would copy nothing in " the protected mode " even after overlays loading to memory (see loading). No use. Nothing was recorded, i.e. UNC in the service area could not be eliminated at the given stage, even if its reason was CS sector failure.
I installed the heads assembly taken from the donor disc. To be more exact, considering the design peculiarity, I transferred a platter into the hermetical area of the donor disc with the subsequent centering. The result was the same. I tried one more donor but in vain. The difference was at the moment that the record test was carried on successfully, but it did not help to recover earlier failed sectors.
I read all the service information area as the uniform block. The successfully read through part made approximately 20 %. Neither a factory defect register nor the area distributions table were not within the part read. I had a luck to get user area adaptives read through.
Attempts to work with alternative SA did not bring successful result either. Having no other way out, I prepared the board hot swap donor. I took a fitting volume and model donor and recorded adaptives, then cleared the defect registers and started.
Information had to be recovered with the help of hot swap
The user data can be read only by physical tracks reading command, sector by sector, making a virtual translator on-the-fly. The data was read, but since the defect-list had been cleaned, I got over 2000 shifts in translation. It meant that the MFT script sent you to one sector but at that address you could find only thrash (another file body) instead of the file signature you needed, and the necessary file is located at another place. The agent Malder might say it was next to it.
The next laborious task is toread out the MFT, build the shift map, I mean the table of logical translator shifts. There's no other way to get the valid user's data.
SAS cases from raid-5 server HewlettPackard
The Hewlett Packard server on 4 SAS-disks has been got for recovery. Each disk has the HP label and only an intent examination shows they are made by Seagate. The fifth level Raid array was made of four HDDs. For some tome it was working quite well but after two HDDs failed the array fell into pieces.
SAS disks raid-5 of the HP server
By the way, the compartment's construction is very poor. There's no cooling for the disks, they get so hot, that you can't even touch their surface. It's not surprising that they haven't worked for a long time. The only way is work with the disc images at the raid array failure is logical raid array making. Not even with the original images, but with their copies. This method will save the information is case of different errors or failures. You can always make another copy and try to make something in other way.
Of course, before getting sector-wise copies from defective HDDs, which are included in the raid array, one should get access to the user zone of these hard disks. In this particular case there were no problems with defective hard disks. Threshold values of SMART attributes in both of them were exceeded, which fact prevented the normal disk startup. However, being connected to a special expansion board, which allows to flexibly set parameters and start SAS drives without creating the Raid array, we easily obtained complete disk image dumps, skipping unreadable sectors. Then was the most interesting part - visual analysis of obtained dumps. At first sight everything was easy - after a ten-minute analysis and calculations it became clear, where the first block was, where the second was, and what their sizes were. According to test results, it proved to be not the fifth Raid, but just the variety of Raid 4, because it looked like three disks alternated as a stripe, and at the fifth there were parity blocks.
However, the raid array assembly with the indicated settings showed that the raid array is assembled incorrectly. The two sections can be seen, there's a correct MFT-recording start on both of them, but many folders are described incorrectly, many of them are empty and most of files have a wrong signature. Further sorting out also wasn't successful, until it dawned upon me that this is the HP server! And these servers have a peculiarity, which is usually called the raid array build delay. What's this? It's simply a kind of a displacement, after which in the Raid 5 the usual parity blocks alternation on all the disks of this raid array begins. What should you do next? Find the displacement after which the Raid 5 begins, and remember while assembling that before some certain moment it's a stripe on 3 discs and parity blocks on the fourth, and after this moment it's a usual backward parity Raid5.
How you can self-recovery data from broken Raid-0 (Raid stripe). The way of solution.
At the data recovery there is an outer information carrier which has two IDe storage discs inside. A real raid controller is unrealized but there is a certain control chip which is responsible for the data on the stripe. There devices refuse to work very often due to the malfunction of the administrative plata of the electronics or the plug in while the disks are physically in good condition. All that is necessary to do to restore the data in such a case is to rebuild the raid array by programming using the method of emulating the device raid.
The outer information carrier of two HDD united into the raid array
Actually, in the course of logical data analysis the order of blocks and their size were easily detected. I would like to tell briefly to those who tries to build a stripe raid array manually how to act in general. Suppose you have the so-called high-speed raid, or stripe, consisting of two hard disks. First, you should save image files to independent media. It will secure you or rather your data against accidental corruption or loss. Then run any disk hex-editor, for example, Acronis DiskEditor or WinHEX, open the files and look at the image beginning in hex-mode.
In one of the disks you will see easily recognizable Master Boot Record (MBR), and in the second disk you will also find something. It is some sector of yet unknown logical drive of Raid stripe. Let's look at the partition table template to estimate the number, size and position of logical drives.
In my case there was one partition, the file system was NTFS, beginning - with the standard biasing of the 63rd sector. I opened sector 63 and looked at its content. The most interesting is the description of tables MFT, MFT mirror and cluster size. The standard value at full volume disk formatting using regular Windows tools - is 8 sectors in a cluster and MFT starts with the 786 432 cluster. I.e. 786 432*8+63=6 291 519 LBA. The first record of the MFT table should be exactly at this address. Of course, there will be nothing at the required address in a half of the stripe. We need to find the actual position of the sector with the characteristic signature "FILE0", which defines the file allocation table. Then we need to find out from which sector starts the MFT on the second disk. The thing is that it is very easy to analyze the size of the stripe raid alternation block on MFT records.
After the analysis is complete and the block size is found out, we need to specify the disks order and the alternation block size in the core software. Having finished building the virtual raid, we need to make sure that the array was gathered correctly, file signatures conform to the expected ones. This is it now - we may save the data from the virtual, manually gathered raid.
Taking this job's specificity into account, I mean the fact that I was invited to work with those devices which the company specialists tried to sort out but didn't manage to, I can say the following: despite the difficult cases of which the work consisted, it was really interesting.
At the workplace
With a programmer and a remote thermometer
Ready for work!
Working
We saw a great deal of disks with scratched surfaces, little-studied (like laptops drive Seagate 5400.5), destroyed raid arrays, burnt flash cards and other pain in the ass. If we had to replace the head assembly to restore the data and after that the disk easily gave the information out, this was considered a great luck. We had such luck just with two HDDs. And I never had cases when I just had to replace the board or there was a damaged partition.
Besides cases, which were described in the previous news, I remembered a "Hitachi" disk with serious scratches, restoring which I spent the whole day and to disks for parts. After examining heads through a microscope, I decided to clean the plates from metal dust in the ultrasonic bath with special solution.
Washing the platter
Heads through the optic microscope
And through the electronic one
The laptop Seagate HDD with a scratch under the zero head over all the control footing that makes reading of the rest of data practically impossible.
Here is an interesting disc, its data can't be recovered in any way. Until the user suddenly remembered, the laptop was on for several hours. A hard disk being out of order can destroy the entire magnetic layer in half an hour. That's why your attempts to define the problem and recover the information are not recommended. You risk to leave nothing to recover after them.
Platters scratched to being transparent
There were some amusing incidents, too. For example, a student from Laplandia (a district in Finland, over the Polar circle) called the company, fixed the details and went to the post office to send the disc. In the field "Receiver" he indicated his own address. Two days later, he looked into the post box and found the return receipt. He went to the post office, happy about the fact that he had his disc as quickly repaired, took the disc, went home, connected the device - it didn't work. He called to complain.