Data recovery, existing raid 0 array on new motherboard
in [Hardware]
|
From: E on 17 May 2010 00:34 I'm working on a Dell XPS-600 with a failed motherboard. The PC had two 160GB drives that I assume were set up in a RAID 0 configuration since it was a gaming PC. I hooked them to a new motherboard and tried to boot from the drives but it halts in POST because it can't find anything to boot from. I have gone into the BIOS and RAID setup utility of the new board and tried to set up a RAID 0 array hoping it would at least boot part way into the OS which did not work. I have also booted a live Suse Linux CD to see if I could access them from there. Partitioning software in Suse says it can't read the partitioning information, but does show that there is a FAT partition labeled DellUtility. I have not tried to configure the two drive as RAID 1. I have no experience with RAID, but since the drives are the same size and this was intended by Dell to be a gaming PC I assume that they were originally set up as RAID 0. There is an option to set the stripe size in the RAID setup of the motherboard but I am afraid to change it because it warns that it will delete the MBR. The user probably has no back up of data. Thanks in advance Eddie
From: E on 17 May 2010 00:45 E wrote: > > > I'm working on a Dell XPS-600 with a failed motherboard. The PC had two > 160GB drives that I assume were set up in a RAID 0 configuration since > it was a gaming PC. I hooked them to a new motherboard and tried to boot > from the drives but it halts in POST because it can't find anything to > boot from. I should have included the fact that I am now using a non-Dell of the shelf motherboard. An Biostar A760G M2+ which is an AMD chipset motherboard.
From: Paul on 17 May 2010 01:11 E wrote: > > > I'm working on a Dell XPS-600 with a failed motherboard. The PC had two > 160GB drives that I assume were set up in a RAID 0 configuration since > it was a gaming PC. I hooked them to a new motherboard and tried to boot > from the drives but it halts in POST because it can't find anything to > boot from. > > I have gone into the BIOS and RAID setup utility of the new board and > tried to set up a RAID 0 array hoping it would at least boot part way > into the OS which did not work. I have also booted a live Suse Linux CD > to see if I could access them from there. Partitioning software in Suse > says it can't read the partitioning information, but does show that > there is a FAT partition labeled DellUtility. I have not tried to > configure the two drive as RAID 1. > > I have no experience with RAID, but since the drives are the same size > and this was intended by Dell to be a gaming PC I assume that they were > originally set up as RAID 0. There is an option to set the stripe size > in the RAID setup of the motherboard but I am afraid to change it > because it warns that it will delete the MBR. The user probably has no > back up of data. > > Thanks in advance > Eddie > If it was a RAID 0, then the data would be striped. Say, for example, drive 0 had the first 128KB stripe. Drive 1 had the second 128K stripe. Drive 0 had the third 128KB stripe. That would mean, that only one of the two drives would have an MBR, since the MBR (one sector long or 512 bytes) would be contained within the first stripe. If I use a Linux LiveCD here, I'd be using the "fdisk" utility to dump what the software thinks is an MBR. It will be searching for the signature byte in the last two bytes (AA55 hex) of the first sector. If the signature is missing, it will conclude there is no MBR present. fdisk /dev/hda The fun part, is figuring out where in /dev, the disk(s) are hiding. It won't be named hda, because that would be too easy. They aren't even named the same, between two different distros. Sometimes it'll be sda for example. Fdisk has a built in help menu, which will tell you how to "print" the partition table (assuming you figure out the /dev part). The utility must be run as root. If one disk has a valid partition table, and the other one appears not to, you could have RAID 0. If both had identical partition tables, it could be RAID 1. Finally, up near the end of each RAID disk, could be some meta-data, that indicates information about the RAID. But I'm not aware of any (free) utility to read that stuff. I've only experimented with that for fun, to see where the meta-data is hidden. I used a Promise RAID chip on my old computer, as a means to create a RAID. And then I looked for any non-zero data, which happened to be up near the end of the disk. And there was enough room in that structure, for 16 different RAID arrays. But I still couldn't read it as such. I could only tell what it was for, and where it came from (the data there, only showed up after I did a "Create Array" in the BIOS RAID interface). Does the product documentation tell you it uses RAID 0 ? Maybe the Dell forum has such info, and you could find it in a search. In Linux, I use this occasionally, to get info on storage devices. But I don't think this can probe a proprietary RAID, read the meta-data, and tell you what's going on. That might take some commercial RAID recovery software. http://disktype.sourceforge.net/ Paul
From: E on 17 May 2010 01:48 Paul wrote: <snip original post> > > If it was a RAID 0, then the data would be striped. Say, for example, > drive 0 had the first 128KB stripe. Drive 1 had the second 128K stripe. > Drive 0 had the third 128KB stripe. That would mean, that only one > of the two drives would have an MBR, since the MBR (one sector long or > 512 bytes) would be contained within the first stripe. Ok, I did glean something like that from message board searches. If the drives actually had 128kb stripes, and I set the stripe size in the RAID setup to 128kb, would this give access to the disks from this motherboard? > > If I use a Linux LiveCD here, I'd be using the "fdisk" utility to > dump what the software thinks is an MBR. It will be searching for > the signature byte in the last two bytes (AA55 hex) of the first > sector. If the signature is missing, it will conclude there is no > MBR present. > > fdisk /dev/hda The partitioning software on the live Suse CD is a GUI tool, but it does return the same information. And missed this before, the partitioning tool is actually telling me it can't read the partitioning information for ONE of the disks, it does read an MBR on the other, and that disk contains the 'DellUtility' partition which is only about ~45MB. > > The fun part, is figuring out where in /dev, the disk(s) are hiding. > It won't be named hda, because that would be too easy. They aren't > even named the same, between two different distros. Sometimes > it'll be sda for example. The Linux technicals are taken care of with this live disk. It lists the drives as /dev/sda and /dev/sdb. I think that means SATA disk a and b respectively. This partitioning tool may just be a GUI front end to fdisk but I'm not sure. Other system information tools on the live CD list the drives and the DellUtility partition, but I just can't access them. > > Fdisk has a built in help menu, which will tell you how to > "print" the partition table (assuming you figure out the /dev part). > The utility must be run as root. > > If one disk has a valid partition table, and the other one appears > not to, you could have RAID 0. If both had identical partition > tables, it could be RAID 1. It could be RAID 0 then, because one disk has a partition table according to the partitioning tool. > > Finally, up near the end of each RAID disk, could be some meta-data, that > indicates information about the RAID. But I'm not aware of any (free) > utility to read that stuff. I've only experimented with that for fun, > to see where the meta-data is hidden. I used a Promise RAID chip on > my old computer, as a means to create a RAID. And then I looked for any > non-zero data, which happened to be up near the end of the disk. And > there was enough room in that structure, for 16 different RAID arrays. > But I still couldn't read it as such. I could only tell what it was > for, and where it came from (the data there, only showed up after > I did a "Create Array" in the BIOS RAID interface). > > Does the product documentation tell you it uses RAID 0 ? > Maybe the Dell forum has such info, and you could find it > in a search. The service tag info for the original Dell machine mentions nothing about RAID, but searches reveal some users had RAID in there machines, one at least has the same problem. A failed motherboard and a way to get the data from a striped array. I think solutions revolved around commercial RAID recovery software. > > In Linux, I use this occasionally, to get info on storage > devices. But I don't think this can probe a proprietary RAID, > read the meta-data, and tell you what's going on. That might > take some commercial RAID recovery software > > http://disktype.sourceforge.net/ I'll check into that and maybe go to the Suse forum to see if there is a way to do this with whats on the Live CD. Thanks Eddie
From: Paul on 17 May 2010 10:48
E wrote: > > The partitioning software on the live Suse CD is a GUI tool, but it does > return the same information. And missed this before, the partitioning > tool is actually telling me it can't read the partitioning information > for ONE of the disks, it does read an MBR on the other, and that disk > contains the 'DellUtility' partition which is only about ~45MB. > If I was doing it manually, converting a RAID 0 to a single disk, the tricky part would be figuring out the stripe size. That could be contained in the metadata area, if you knew how to read it. The metadata indicates whether the disk is the odd disk or the even disk, so that even if the SATA or IDE ports are switched, the data is read out in the right order. The serial numbers of the disks used in the array, should be contained in the metadata area, so that the RAID firmware can piece it all together. The metadata is also used to record failures, so if a RAID 1 lost synchronization, a rebuild would be forced at the next opportunity. (If you had a RAID 0 with three or four disks, you'd need that metadata info, as guessing would take a while. RAID 0 can have more than two disks, but cheap controllers typically support two.) You already know which disk is odd and which is even, based on finding a good MBR on the disk that contains "sector 0". You would copy the stripe chunks, one after another, to your target (receiving) disk, until the job was done. The first stripe would be copied from the disk that has the MBR. You could code that up entirely, using "dd" in Linux. "dd" has offset capability, so you can tell it to seek to a particular sector, and copy exactly 128KB for example. So if you needed a means to do the copy, all it would take is a script in Linux. dd can copy from an arbitrary starting address on one disk, and be written to an arbitrary address on a second disk. So "dd" should be enough, if you have the time and patience to code it up. If you have no idea about the stripe size, you could attempt the transfer with different stripe sizes, and see if something makes sense. It's unlikely they're using tiny tiny stripes, so perhaps testing 64K and 128K as sizes would be enough. In terms of transitioning a ("hardware") RAID, from one computer to another, if you have the same manufacturer of disk controller, there is a possibility the metadata can be read, and the array picked up as is. For example, moving an array from one Promise controller to another Promise, is supposed to be possible. It's moving between different manufacturers that won't work, because there are no standards for metadata. Moving from Nvidia to Nvidia should work. But moving Nvidia RAID to ATI RAID probably wouldn't. According to this, there is an Nvidia CK804 Southbridge on the XPS600, so that could be the "brand" of RAID. If you could find another motherboard with Nvidia RAID support, the array might be picked up right away. http://www.extremetech.com/article2/0,1697,1845015,00.asp If I wanted to copy two 100GB disks connected in RAID 0, to a 200GB target disk, I'd try something like the Windows port of "dd". As long as the RAID shows up as a logical device in "dd --list", you may be able to copy it exactly. I like "dd" for this kind of thing, because it doesn't matter what file systems are involved. http://www.chrysocome.net/dd Once that is done, you'd have your data back. So either find a motherboard with an Nvidia chipset and RAID drivers in place, or "become good at coding dd into a script" :-) Good luck, Paul |