Someone has brought me the 4-SAS-disk Hewlett Packard server for data recovery. All the disks have a label saying HP and only a thorough examination shows that these are Seagate disks. A Raid5 array was assembled out of four winchesters. For some time, the device has operated quite well but then two disks fried and the array collapsed.

The HP Server’s Raid5 Array SAS Disks
By the by, the construction of the disk box is extremely lame. The winchesters have no supply of extra cooling so that they get as hot as blazes. No wonder that they have broken down so soon. The only right way of dealing with raid array errors is work with disk images (to be more precise – with copies of the images, not the originals), i.e. logical assembly of the raid. Such an approach will save the data in case of various types of faults. There is always an opportunity to copy the data and try out a different solution.
It goes without saying that before you acquire sector copies of defective HDDs comprising the raid array, you should first get access to the user zone of the winchesters. In this situation, there have been no serious problems with cloning of subquality hard disks. The SMART attributes of both of them possessed exceeded threshold values, which impeded standard disk launch. However, with the winchesters being connected to a special expansion card making it possible to flexibly customize the disk launch settings and startup the SAS storages with no raid arrays required, I have easily managed to get full disk image dumps, passing unreadable sectors. After that, the most interesting part has begun – it is visual analysis of the acquired dumps. On the face of it, the whole process has turned out to be very simple: already after a 15-minute study and some calculations, I have understood where the first and the next blocks are and what sizes they have. According to the results of the troubleshooting, it was not Raid5 but a variety of Raid4 for it looked like three disks alternated as stripe blocks and a parity block on the 5th disk.
However, assembly of the array with the stated parameters has shown that the raid was compiled incorrectly. It is possible to discern two sections and a correct beginning of MFT notes in both of them but most folders are described erroneously in the directory tree or are empty and most files possess an irregular sig.
Further examination was not successful until it dawned upon me that it was an HP server and these servers had a significant feature – it is the so called raid array build delay. What is raid build delay? It is simply a certain shift which results in classic alternation of parity blocks in all the array’s disks in the 5th raid. The next step is to calculate the shift generating Raid5 and when assembling take into account the fact that up to a certain moment this is stripe on 3 disks, parity blocks on the 4th disk, and then a usual backward parity Raid5.















Recent Comments