Comments on: Recovering from a RAID Controller Failure http://www.dtidata.com/resourcecenter/2009/12/18/recovering-from-a-raid-controller-failure/ Hard drive recovery data recovery resource center with how to guides for windows RAID Snap server file system repair NTFS partition recovery tools tips and tricks to recover data Fri, 10 Feb 2012 20:43:29 -0500 hourly 1 http://wordpress.org/?v=3.1.2 By: Jason http://www.dtidata.com/resourcecenter/2009/12/18/recovering-from-a-raid-controller-failure/comment-page-1/#comment-8046 Jason Fri, 05 Nov 2010 23:09:15 +0000 http://www.dtidata.com/resourcecenter/?p=1213#comment-8046 Hi Dick, thanks for the info. I found that each of the drives contained the information in the *last* 1024 bytes of the drive, so a `dd` with additional parameter "seek=###" where ### was the offset ( 2 TB - 1024 Bytes), worked like a charm. After clearing the drives, put them back in, and it rebuilt the array like it was new. (their email support was not helpful unfortunately). -Jason Hi Dick, thanks for the info. I found that each of the drives contained the information in the *last* 1024 bytes of the drive, so a `dd` with additional parameter “seek=###” where ### was the offset ( 2 TB – 1024 Bytes), worked like a charm. After clearing the drives, put them back in, and it rebuilt the array like it was new. (their email support was not helpful unfortunately).

-Jason

]]> By: Dick Correa http://www.dtidata.com/resourcecenter/2009/12/18/recovering-from-a-raid-controller-failure/comment-page-1/#comment-8045 Dick Correa Fri, 05 Nov 2010 18:28:26 +0000 http://www.dtidata.com/resourcecenter/?p=1213#comment-8045 Greetings Jason, The sad reality is that there is no standard for the storage of meta-data that will identify the drives. There are some series of RAID cards that store it in the first 64k of the drive. There are others that store it at the end of the drive. There are other cards that store it on the card with read/write PROMs. What is becoming most prevalent is the use of an LVM header that defines the drive order and characteristics since the firmware uses a Linux RAID handler. As for circumventing a rebuild, that is also on a card by card basis. Some manufacturers force a rebuild because it is a prudent thing to do when the drive has been degraded. The assumption is that you pulled the drive for a reason so the new one must be integrated back into the array by performing a rebuild. There are cards that will allow you to configure the rebuild out. There are cards that you have to tell them to do a rebuild. The rebuild is performed to protect the remaining data. There is no had and fast rule for RAID rebuilding, configuring, etc. I have seen the exact same RAID come into the shop where one will have meta-data at the front of the drive and the other won't have any meta-data at all. Ultimately there is no way to be sure how to handle your particular situation. I am sorry to be so vague, however, the card firmware programmers are very flighty. Dick Correa Greetings Jason,

The sad reality is that there is no standard for the storage of meta-data that will identify the drives. There are some series of RAID cards that store it in the first 64k of the drive. There are others that store it at the end of the drive. There are other cards that store it on the card with read/write PROMs. What is becoming most prevalent is the use of an LVM header that defines the drive order and characteristics since the firmware uses a Linux RAID handler.

As for circumventing a rebuild, that is also on a card by card basis. Some manufacturers force a rebuild because it is a prudent thing to do when the drive has been degraded. The assumption is that you pulled the drive for a reason so the new one must be integrated back into the array by performing a rebuild. There are cards that will allow you to configure the rebuild out. There are cards that you have to tell them to do a rebuild. The rebuild is performed to protect the remaining data.

There is no had and fast rule for RAID rebuilding, configuring, etc. I have seen the exact same RAID come into the shop where one will have meta-data at the front of the drive and the other won’t have any meta-data at all. Ultimately there is no way to be sure how to handle your particular situation.

I am sorry to be so vague, however, the card firmware programmers are very flighty.

Dick Correa

]]> By: Jason http://www.dtidata.com/resourcecenter/2009/12/18/recovering-from-a-raid-controller-failure/comment-page-1/#comment-8036 Jason Thu, 04 Nov 2010 00:06:00 +0000 http://www.dtidata.com/resourcecenter/?p=1213#comment-8036 Hello, I've been trying to find information online about where RAID "membership" or signature information is stored on the drives? This isn't related to data recovery, but since you've written many low-level utilities I thought you'd be the person to ask. We have an external RAID5 enclosure (usb+firewire, internally the drives are sata), and to verify that it worked, I pulled a drive to see how the unit behaves. It behaved as expected, all the dummy data was fine, and the OS didn't notice. I put the drive back in, and it's rebuilding, but the problem is it takes forever and I'd rather just reinitialize and reformat, since there's no real data on the drives. After connecting each individual drive through SATA->USB adapter, I tried to use linux "dd" command to overwrite first several MB of each of the drives with 0's (this works for wiping MBR), but the external raid device still thinks the drives are all members of a degraded array, and insists on rebuilding it, instead of recreating a new array. I suspect that it is storing drive serial numbers somewhere, but that would be bad if the whole unit fails, and I wanted to put the drives in another same-model enclosure; and other raid controllers I've seen can be replaced, so the Array information must be on the drives somewhere, but the question is where? (I tried DBAN, but even on single pass "quick" it estimates 48 hours to wipe a 2TB drive) thanks in advance, any reply is appreciated! Hello, I’ve been trying to find information online about where RAID “membership” or signature information is stored on the drives? This isn’t related to data recovery, but since you’ve written many low-level utilities I thought you’d be the person to ask.
We have an external RAID5 enclosure (usb+firewire, internally the drives are sata), and to verify that it worked, I pulled a drive to see how the unit behaves. It behaved as expected, all the dummy data was fine, and the OS didn’t notice. I put the drive back in, and it’s rebuilding, but the problem is it takes forever and I’d rather just reinitialize and reformat, since there’s no real data on the drives.
After connecting each individual drive through SATA->USB adapter, I tried to use linux “dd” command to overwrite first several MB of each of the drives with 0′s (this works for wiping MBR), but the external raid device still thinks the drives are all members of a degraded array, and insists on rebuilding it, instead of recreating a new array. I suspect that it is storing drive serial numbers somewhere, but that would be bad if the whole unit fails, and I wanted to put the drives in another same-model enclosure; and other raid controllers I’ve seen can be replaced, so the Array information must be on the drives somewhere, but the question is where?
(I tried DBAN, but even on single pass “quick” it estimates 48 hours to wipe a 2TB drive)

thanks in advance, any reply is appreciated!

]]>