- if I start "playing" with the disks how can I make sure that I will not destroy any data that is still, if not accessible, on these disks? - The short answer is you can't be sure. There is a risk with every option.
If you have a controller failure you can get all sorts of reported errors. The controller may not hold onto the config and when it reads it off the disks may report it incorrectly.
If you replace the contoller it should pick up the config from the disks but put the new controller in, boot without the drives inserted. press ctrl-a when prompted and select SataSelectUtility, then Controller configuration. One the next screen, look for the entry Automatic failover. It should be set to enabled. Change this to disabled. The stops the automatic rebuild of failed drives. power down and insert the drives, power on, press ctrl-a again when prompted. You will get a message about accepting the config. accept it. Then in the bios, click on manage arrays, you can check on the status here.
Putting the disks into another 745 would be the same as trying a new card with the exception that a config will be stored on the raid card. It should pick up your disks but will ask you to accept the config.
thanks for your immediate valuable reply! I will get my hands on the machine within the next few days and report about any successful procedures.
Anyone else out there with additional hints/thougths/comments/links? You all know how much pressure a CEO can put on you ....We
must not loose any data.
If you put the disks into another box, things to do.
Disable the auto failover in the raid card bios before you put the disks in. This will stop the controller automatically rebuilding if it thinks there an error. This will leave your disks in their original condition. If there was an error it will report it and not try to fix it. Then backup/move your data to a safe location then breathe a sigh of releif.
On the failing 745: should be step 1.
Slide the disks out of the original 745 abount 2 inches. Mark each drive with a permanent pen IE 1, 2, 3, 4. Just to make sure you can put them into the same slots on the surrogate 745. Saves confusion and lengthy rebuilds as the controller sorts out the disk sigs.
Meanwhile - after a liong journey - we have restored the lost data. We could _not_ regain the Raid configuration from the disks by using a new SATA controller. This may have been due to the fact that HD 0 (of four) had been erroneously overwritten by a data recovery company. So I had only HD 1-3 with the RAID data.
Further analysis and trials with data recovery software showed that the system partition was well recoverable from the remaining 3 disks, but the most important data partition was somehow lost; the entry in the partition table was deleted.
_How_ this could happen is beyond my imagination, because we are sure that no human user interaction was responsible for it. I guess that a malfunctioning RAID controller or Dell OpenManage software piece running wild deleted the partition. Of course Dell support said that this was impossible.
We used 2 software utilities from runtime.org: RaidReconstructor and GetDataBack, to first write an image of the RAID to a separate disk and then restore the 110.000 files which were all in place.
The most challenging part was due to the fact that the 2nd partition did _not_ begin at a multiple of 64kB-blocks as most RAID controllers would do and most Raid Recovery Software assumes. So it took extensive testing and calculation to find the right start sector on the 3 remaining disks for the 2nd partition so that the RaidReconstructer utility was able to gather the data blocks (each 128 sectors of 512 bytes) and assemble them in the right sequence to an image file.
Our lesson learned: NEVER think that your data is safe on a Raid5-system!
Due to an different problem than the one mentioned in this thread, I am also attempting to rebuild the data from our 745N with Raid Reconstructor, and am having trouble finding the start sector and block sized. I realize that it has been well over a year since your post, but you don't by any chance recall what parameters you used to recover the data, do you? I've searched extensively, to no avail. Any help you might be able to provide would be greatly appreciated! Thanks.
I can't remember all details, but I recall it was a heck of a work.
I had SATA disks. To do my work I used a Dell Client PC with XP and SATA interface. I connected the failure RAID disks to SATA channels 1-3 of that client. The client was booting from its own disk 0. I installed the recovery tools on that client. The client was connected to the server farm since I needed a LOT of space to write disk images to.
I used HexEdit to look at the byte data on the disks. I had 3 of 4 250 GB disks of the RAID5-Array available. The data of the first disk was overwritten by a data restore company. So I had Disks 1,2,3 of the RAID disks 0-4. Raid block size is 128 sectors = 64 kB (standard). Parity sequence is 4-3-2-1.
I was glad I had the partition table of the Raid which was on disk3 at the beginning. From that I could calculate the offset of the 2nd partition which data had been lost (the c: partition still worked). To do that you need some insight in partition table structures but you will find information in the web. As a next step I scanned the sectors following the calculated starting sector (you have to divide that number by 3 since data is evenly distributed on 3 disks, the 4th being reserved for parity). I managed to find sectors that looked like MFT entries. So I had found 1 cluster of 64kB MFT table on one disk and on another, the third showing "scrambled" bytes at the same position. These were the parity information (remember I had only 3 of 4 disks).
Next step was to calculate a starting sector for RaidReconstructor (after configuring RR in that way that the array consisted of 4 disks but I had only disks 1-3 available, leaving entry for disk 0 blank). Then I let RR write some 10 GB as an image to another server. After that I let GetDataBackNT search that image piece for MFTs. The MFT of NTFS comes as 2 copies, one somewhere at the beginning of the partition and the other somewhere in the middle of the partition. I was interested in finding the first copy. Therefore writing 10 GB was sufficient.
GDBNT found MFT entries, but from the log files I could see that in between "readable" MFT entries with readable filenames other entries showed up with "garbage" filenames. So I knew the starting sector number I had entered in RR was still wrong.
I analysed the "garbage" pattern of the MFT entries found by GDBNT in an Excel sheet and calculated an offset to the wrong starting sector entry in RR. Then I corrected this number and let RR write the 10 GB again.
It took me 3 or 4 trials to find the right starting sector. Once found GDBNT showed ALL the MFT entries correctly. After that I let RR write an image of the whole partition (some 700 GB). The rest was easy: Using GDBNT on that image file and extracting all the files. Easy does NOT mean quickly: Since I had to move a lot of GBs the whole process of testing, trying, writing disk images etc took many days.
The mystic number of the starting sectors of the d: partition was 6989567 (in RR: "Start sector of the RAID on each individual drive" ). But your RAID config might be different from mine.
Good luck and regards,
Florian
Message Edited by stephensson on 08-25-200612:52 PM
Thanks for the quick reply! Using some of the text from the XOR test (and after some trial and error), I came up with 20482875, which seemed very high, especially considering the example and what little information I found online all suggested using 63. However, the fact that your number is only one order off gives me a lot more confidence in the number that I got. Raid Reconstructor is still running, and has another couple of hours yet to go; hopefully the parameters I gave it are accurate. I'll let you know how it turns out. Just out of curiosity (and in case my parameters end up not working), what values did you use for the block size and the Parity Rotation?
20482875 divided by 3 comes pretty close to the value I have found. In RR you have to enter a RAID starting sector which means the sector number of each individual disks. Since RAID5 spreads data on 3 disks the absolute sector number is triple that high.
Block size was 128 (times 512bytes equals to 64k Blocks), Rotation scheme was standard 4-3-2-1.
Thanks again for the timely response! Raid Reconstructor finished up on Friday, and I let GetDataBack run over the weekend. This morning, I successfully recovered all 6200+ files!
Thanks again for your help, and pointing me in the right direction! These two pieces of software are amazing (not to mention a fraction of the cost of having a company do the recovery for you). Of course, now I'm not going to be able to tell a user 'sorry about your luck' when their PC crashes and they haven't been doing their regularly scheduled backups...
tommo666
3 Apprentice
•
1.2K Posts
0
July 26th, 2005 14:00
- if I start "playing" with the disks how can I make sure that I will not destroy any data that is still, if not accessible, on these disks? - The short answer is you can't be sure. There is a risk with every option.
If you have a controller failure you can get all sorts of reported errors. The controller may not hold onto the config and when it reads it off the disks may report it incorrectly.
If you replace the contoller it should pick up the config from the disks but put the new controller in, boot without the drives inserted. press ctrl-a when prompted and select SataSelectUtility, then Controller configuration. One the next screen, look for the entry Automatic failover. It should be set to enabled. Change this to disabled. The stops the automatic rebuild of failed drives. power down and insert the drives, power on, press ctrl-a again when prompted. You will get a message about accepting the config. accept it. Then in the bios, click on manage arrays, you can check on the status here.
Putting the disks into another 745 would be the same as trying a new card with the exception that a config will be stored on the raid card. It should pick up your disks but will ask you to accept the config.
You could look at this: http://www.runtime.org/raid.htm
In all cases, there is no guarentee over losing data. As you say the data is there but the problem is trying to access it.
stephensson
5 Posts
0
July 27th, 2005 01:00
tommo666
3 Apprentice
•
1.2K Posts
0
July 27th, 2005 20:00
If you put the disks into another box, things to do.
Disable the auto failover in the raid card bios before you put the disks in. This will stop the controller automatically rebuilding if it thinks there an error. This will leave your disks in their original condition. If there was an error it will report it and not try to fix it. Then backup/move your data to a safe location then breathe a sigh of releif.
On the failing 745: should be step 1.
Slide the disks out of the original 745 abount 2 inches. Mark each drive with a permanent pen IE 1, 2, 3, 4. Just to make sure you can put them into the same slots on the surrogate 745. Saves confusion and lengthy rebuilds as the controller sorts out the disk sigs.
stephensson
5 Posts
0
September 14th, 2005 23:00
fitchn
3 Posts
0
August 25th, 2006 13:00
stephensson
5 Posts
0
August 25th, 2006 16:00
fitchn,
I can't remember all details, but I recall it was a heck of a work.
I had SATA disks. To do my work I used a Dell Client PC with XP and SATA interface. I connected the failure RAID disks to SATA channels 1-3 of that client. The client was booting from its own disk 0. I installed the recovery tools on that client. The client was connected to the server farm since I needed a LOT of space to write disk images to.
I used HexEdit to look at the byte data on the disks. I had 3 of 4 250 GB disks of the RAID5-Array available. The data of the first disk was overwritten by a data restore company. So I had Disks 1,2,3 of the RAID disks 0-4. Raid block size is 128 sectors = 64 kB (standard). Parity sequence is 4-3-2-1.
I was glad I had the partition table of the Raid which was on disk3 at the beginning. From that I could calculate the offset of the 2nd partition which data had been lost (the c: partition still worked). To do that you need some insight in partition table structures but you will find information in the web. As a next step I scanned the sectors following the calculated starting sector (you have to divide that number by 3 since data is evenly distributed on 3 disks, the 4th being reserved for parity). I managed to find sectors that looked like MFT entries. So I had found 1 cluster of 64kB MFT table on one disk and on another, the third showing "scrambled" bytes at the same position. These were the parity information (remember I had only 3 of 4 disks).
Next step was to calculate a starting sector for RaidReconstructor (after configuring RR in that way that the array consisted of 4 disks but I had only disks 1-3 available, leaving entry for disk 0 blank). Then I let RR write some 10 GB as an image to another server. After that I let GetDataBackNT search that image piece for MFTs. The MFT of NTFS comes as 2 copies, one somewhere at the beginning of the partition and the other somewhere in the middle of the partition. I was interested in finding the first copy. Therefore writing 10 GB was sufficient.
GDBNT found MFT entries, but from the log files I could see that in between "readable" MFT entries with readable filenames other entries showed up with "garbage" filenames. So I knew the starting sector number I had entered in RR was still wrong.
I analysed the "garbage" pattern of the MFT entries found by GDBNT in an Excel sheet and calculated an offset to the wrong starting sector entry in RR. Then I corrected this number and let RR write the 10 GB again.
It took me 3 or 4 trials to find the right starting sector. Once found GDBNT showed ALL the MFT entries correctly. After that I let RR write an image of the whole partition (some 700 GB). The rest was easy: Using GDBNT on that image file and extracting all the files. Easy does NOT mean quickly: Since I had to move a lot of GBs the whole process of testing, trying, writing disk images etc took many days.
The mystic number of the starting sectors of the d: partition was 6989567 (in RR: "Start sector of the RAID on each individual drive" ). But your RAID config might be different from mine.
Good luck and regards,
Florian
Message Edited by stephensson on 08-25-200612:52 PM
fitchn
3 Posts
0
August 25th, 2006 17:00
stephensson,
Thanks for the quick reply! Using some of the text from the XOR test (and after some trial and error), I came up with 20482875, which seemed very high, especially considering the example and what little information I found online all suggested using 63. However, the fact that your number is only one order off gives me a lot more confidence in the number that I got. Raid Reconstructor is still running, and has another couple of hours yet to go; hopefully the parameters I gave it are accurate. I'll let you know how it turns out. Just out of curiosity (and in case my parameters end up not working), what values did you use for the block size and the Parity Rotation?
Thanks again!
Message Edited by fitchn on 08-25-200601:49 PM
stephensson
5 Posts
0
August 25th, 2006 20:00
fitchn,
20482875 divided by 3 comes pretty close to the value I have found. In RR you have to enter a RAID starting sector which means the sector number of each individual disks. Since RAID5 spreads data on 3 disks the absolute sector number is triple that high.
Block size was 128 (times 512bytes equals to 64k Blocks), Rotation scheme was standard 4-3-2-1.
Florian
fitchn
3 Posts
0
August 28th, 2006 15:00
stephensson,
Thanks again for the timely response! Raid Reconstructor finished up on Friday, and I let GetDataBack run over the weekend. This morning, I successfully recovered all 6200+ files!
Thanks again for your help, and pointing me in the right direction! These two pieces of software are amazing (not to mention a fraction of the cost of having a company do the recovery for you). Of course, now I'm not going to be able to tell a user 'sorry about your luck' when their PC crashes and they haven't been doing their regularly scheduled backups...