| Author | Message | ||
     Maurice Naftalin Username: mauricen Registered: N/A |
One of the drives in my RAID-0 array is failing. I used Clone Disk to make an image of the volume (succeeded with 2 bad sectors) on to a raw image file, then used Clone Disk again to copy the image on to a new identical volume. However the array, with the new disk substituted, is not now bootable. Any ideas for finding out what could have gone wrong? (BTW, I mounted the two drives in a USB enclosure. If that is the problem, would a SATA-IDE adapter be any better?) Thanks in advance Maurice | ||
| Maurice Naftalin Username: mauricen Registered: N/A |
I now suspect that the Intel Raid controller is one those too-smart things that recognise the individual identities of the drives in their arrays. If so, the idea of cloning the drives individually was always doomed  | ||
| Pánczél, Levente Username: panczel_levente Registered: N/A |
It's not doomed. The following always worked for me: 0) Make sure the steps below make sense to you, and only perform them if you are confident that you got the point! ;) 1) Backed up a few MB of the start and the end of each disk. 2) Copy all data to the new disks (i.e. to those that were new). 3) Now the array is not functioning, because the controller senses the disk-exchange. No problem, recreate the array with the same parameters (RAID level, stripe size, disk order). The controller will probably overwrite a few reserved sectors on front/end of every disk (if the controller uses such sectors); no problem, that's exactly what you wanted. 4) The controller will most probably overwrite at least the MBR, or even a few start sectors of the array. Well that would be BAD unless you have the copies of the disk-starts so you can re-copy the original start sectors of the RAID-volume. | ||
| Maurice Naftalin Username: mauricen Registered: N/A |
First, thanks very much for this idea! It does make sense overall, but could you give me a bit more detail on steps 2 and 4? Specifically: 1) What tool in WinHex (or elsewhere?) would be best to back up the few MB at the beginning and end? 2) How can I see exactly how far the controller has overwritten my disks (apart from eyeballing the data)? 3) In restoring the overwritten data, how can I be sure that I'm not overwriting something the controller needs? Again, thanks. I'm a programmer, not a systems person, so this is high-risk for me. But I have little left to lose, and if it works I will owe you many pints! | ||
| Pánczél, Levente Username: panczel_levente Registered: N/A |
1) You can of course use WinHex: CloneDisk function gives you the fields StartSector and NumberOfSectors regarding the source. I'd copy 128MB, that roughly 260.000 sectors. The number of the last sector of the disk is displayed when you go to the bottom of the disk editor window, so you can analogously save the end of the disks. 2) I never cared for that. I just determined how many sectors the controller reserves (you can see this from the sector number of the MBR on the first disk). Then I looked whether this many sectors were reserved on the other disks too. And then I restored the start sectors _EXCLUDING_ the reserved ones. I never used the backups of the end sectors. Be sure in this step to leave the new reserved sectors intact (maybe by also creating a backup of those). Also be very carful to write the originally backed pieces with 0 offset, i.e. the data that would go into the reserved sectors would need to be skipped. This is the most difficult part, but first have a look at the current state of your disks, because most RAID 0 array I've seen had no reserved sectors on the front, and simply restoring starts solved the problem. 3) I think you can rely on that the controller reserves data on front of disk(s) maybe at ends. Other scenarios would take up too much computation for no handy reason. Note that most probably only logical sector 0 (in the array) is wiped by the controller (and possibly the following few). This is to ensure that no partitions remain visible and "bootable" flags are reset. Since this initializes the whole disk from a logical point of view, the contollers should not care for overwriting anything else. But just because reserved sectors and array initialization is vendor-specific, this is why I do this manually (I'd bet there exist programs for this same purpose). YET another tip: WinHex CAN reconstruct and explore RAID arrays (if your license suffices). It can concatenate images/disks so that it sees the combined array and then open the partitions in it. You might want to try this first, at least to grab your most valued files. | ||
| Maurice Naftalin Username: mauricen Registered: N/A |
That worked perfectly - huge thanks, Levente! In case anyone reading this has the same problem (failing RAID 0 disk, specifically with an Intel ICH8M-E), this solution is much the easiest of the alternatives for recovery. Levente described it very well for the generic case, but it's much simpler for the (now common) ICH8M-E, because that makes only two kinds of changes in creating a RAID 0 volume: 1) on each disk, it writes one sector of volume configuration on the next-to-last sector of the disk; 2) on the first disk, it zeroises the first sector (containing the MBR). It may do more than that, as Levente suggests, but on my disks the next 63 sectors at least were all zero anyway. WinHex makes it very easy to compare the two versions to check this. So with the ICH8M-E the <em>only</em> thing you have to do after cloning the disks is to restore the MBR (first) sector on disk 0. Far better than any alternative route! Having said that, I still think that RAID 0, on laptops at least, is a <em>really</em> bad idea. Next time I buy a laptop with twin disks, it's going to be converted to RAID 1 before anything else happens. |