Recovering data from a BIOS Fake RAID
 

I have an old system that has experienced hardware failure. I was storing my data on what I thought was hardware RAID 1, but I have now discovered is a BIOS "fake RAID" 1.

The hardware failure is motherboard related, so both of the HDDs seem fully functional.

I read on the Linux RAID wiki, however, that for fake raids, "if drives move to other machines the data can't easily be read".

The old machine is broken, so I cannot read the data there. I was assuming I'd be able to plug in the old HDD to the new machine and copy the data across. Is this not the case?

The fake RAID was using a ASUS K8V-SE Deluxe motherboard, which uses a Promise PDC20378 RAID controller. The RAID array used LVM, if that makes any difference.

The prognosis isn't good. I suggest reading the Linux man page for dmraid(8) and then see if that will mount the array (read only). fakeRAID, like softRAID, uses metadata which is recognised by the BIOS/driver. This means that you don't mount the block device, but a virtual device representing the array.

I don't know enough about LVM to known whether that would complicate matters or not. I assume you set that up because you wanted root on RAID1? (it may be possible without it for all I know).

If I was in your shoes and I really wanted that data, I would probably scour ebay and just buy the same motherboard again, recover my data, wipe both disks, disable fakeRAID in the BIOS and then reinstall the OS and use softRAID instead.

(I would also learn the hard and valuable lesson that RAID, of any kind, is not a backup.)

Good luck, I hope you get your data back one way or the other.

Since you used a RAID1, which just mirrors the disks, you could probably take one of the disks and run photorec or similar on it. You'd get your files back, but without the directories and filenames. Of course, I'd only suggest that if you get really desperate.

I didn't really set up LVM intentionally. CentOS just automatically picked it during installation. I may have asked it to make the recommended setup, I don't recall exactly.

I don't know if this makes any difference, but I took one of the mirrored drives and plugged it into the motherboard through a different SATA port that is not part of the Promise RAID controller; the motherboard has two RAID controllers: one by Promise, one by VIA. I plugged a single drive into the VIA controller and the OS was able to boot from that. Do you think that might improve the prognosis?

If it was able to boot, then it was able to mount the filesystems, correct? If so, then go buy a lottery ticket; today's your lucky day!

I would copy everything to an external drive (or two...). From what I understand, even a fake RAID still messes with some form of non-standard metadata on the drive. My suggestion is to get the data off the drive, then make a software RAID, then copy the data back.

Sadly, the nature of the hardware failure is that it freezes after a minute or two. Booting is not a problem. Copying the files after boot is a non starter.

So the whole motherboard is going bad, not just the fake RAID card? Bummer. Hold off on that lottery ticket. :D
Do you have any idea which part of the motherboard it is? I'm wondering if it might be something that you can temporarily work around, like one of the RAM slots. Of course, every second that you have it powered on probably increases the chances that it's going to completely fail. Maybe. I'm not a hardware expert, I'm just typing my thoughts down as I think them... :rolleyes:

On a more serious note, unless someone has a better suggestion, I don't see any harm in trying to throw one of the HDDs in a separate computer and seeing if it boots. The worst case scenario that I see is that it doesn't boot, and there's not really much that can happen after that.

I do agree with cynwulf that if you really need that data back, you probably want to try to get another motherboard of the same model.

I appreciate you sharing your thoughts.

I have ruled out everything except for motherboard, PSU and the graphics card as the source of the problem. I have tried all RAM combinations and it can't be the RAM. I have replaced the CPU and run it on LiveCD without hard drives.

The system freezes sometimes after a while, and some things always make it freeze. Booting into the GUI always makes it freeze. I boot to run level 1 now. I can use the command line at run level 1 fairly freely, until I run rsync to copy the files out. It freezes after a minute or two when I do that. I ran rsync with throttling to 128kb/s, and it lasted for nine whole minutes. That's about 9 times longer than without throttling.

When swapping the RAM, I also noticed that it got a lot further in the boot process when it had a gig of RAM than when it only had half a gig. So I am getting the feeling that the error (which is a kernel panic) is related to putting load on the system, or something similar.

Try a number of distro's. Some read the data differently for some reason.

Best case would be to duplicate this raid card. The rest of system doesn't matter but the fake raid does.

Stupid fake raid cards!

Trying another PSU is a good idea, methinks.

What does it say when it panics? Sometimes that can be helpful. If you can get a picture of the screen, that might help someone identify your issue.

If starting X makes it panic, I would suspect the graphics card. Though the difference between using 1GB versus 512MB makes me re-think it. But would RAM errors cause it to crash at different times based on hard drive I/O? Hardware problems never seem to make sense...

Are you familiar with Memtest86? https://en.wikipedia.org/wiki/Memtest86 If the RAM's bad, this should tell you. Do you have another system that will accept the same type of RAM? I'd suggest moving the RAM over and testing it there, to avoid stressing the motherboard if the RAM isn't the problem.

How much data do you have? If you're comfortable with it, you might want to try your luck with rsyncing at the slower speed.

I have attached some photos of the screen when it crashes. The one with the most text, that is quite tricky to read, is from GParted. The rest are from CentOS 5.

I have indeed run memtest86 for 8 hours or so. It was happy. Also, note that I have run the computer with each stick of RAM removed, and using different slots. Unless both RAM sticks are damaged, I don't see that it can be the RAM.

It would take about 5 days to migrate all the data at 128kb/s. I can pinpoint the best bits and get them off this way, though. I will try to boot another machine with this drive and see what happens.

This is a shot in the dark, but what all extra peripherals do you have attached? I'm looking at the second image, particularly at the line "drivers/input/serio/i8042.c" I'm by no means experienced in dealing with kernel panics, but some Googling led me to believe that it has something to do with a keyboard driver. (See this page: http://lxr.free-electrons.com/source...042.c?v=2.6.32) When the panic occurred that time, did you happen to notice if the keyboard LEDS were flashing?

Again, I'm just throwing thoughts down as I think them, but would you happen to have a different keyboard? If you're using a PS/2 keyboard, do you have a USB one you could try (or vice versa)? I fail to see how a bad keyboard could cause a kernel panic, but it couldn't hurt to try, right?

Here's hoping that this is remotely helpful... :D

Thank you for those suggestions. I can imagine a keyboard being the problem, and most of the time I do have a fairly elaborate keyboard attached, but some of the crashes were with a very basic Dell keyboard. Similarly, I have a fancy mouse a lot of the time, but it has crashed with a very basic mouse attached too.

It has crashed, reliably, at the same points as usual, with different and very basic mouse and keyboard attached. Also, they are not always attached to the same ports. So I come back to the motherboard or GPU.