Slashdot Mirror
How Are RAID Arrays Identified By Hardware?
Coward Anonymously Before Me asks: "This is more of a tech/hack question, but recently my highpoint controller forgot my disks were in a raid array. All the Disks still function, and have ZERO problems, aside from being not identified as still in RAID-0. All the data should still be there, but remains unaccessible to me, thus the question how and where would this kind of information be stored? On chip? MBR? and can the data be recovered without 3rd party interaction via free/open source toolkits? or even purchased software?"
...you ought to be able to just dd the data from the drive, and if the chip doesn't use a non-standard data layout, write a program or script to put it back together and back it up, then you recreate the array, and put your data back on it.
A solution to the problem with music today
Typically, there's a utility in the RAID configuration that stamps the drive as part of a set, marks the state (good, bad, rebuilding or hot-spare are most common) and some kind of versionig information.
I've ripped a few disks out of the array, mounted them as standard, reformatted and replaced the MBR, threw them back in the array, and still had them recognized as part of the RAID volume. The RAID card didn't like this much, however. :)
I think your best bet is to talk to one of the people who actually wrote the drivers for the card (you've got the Linux source, right :) or possibly see if you can get ahold of an engineer at the manufacturer and discuss ways of getting the information back.
Good luck!
There's so little difference between politics and jihad lately...
Logical volume managers (AIX and Veritas anyway) store a unique ID on the disk, and then keeps track of what volumes are there, how they are configured, etc.
Hardware controllers generally reserve a small slice of disk to store configuration data. Sometimes this slice is marked unusable and can only be accessed by low-level hardware.
One of the big, unadvertised problems with RAID, particularly with new/buggy controllers, is that a controller failure can trash your data.
Unless you have the time & knowledge to reconstruct the data structures, a controller failure that screws up the configuration data on disk effectively destroys your data.
Conformity is the jailer of freedom and enemy of growth. -JFK
people get annoyed with me that I ask questions on IRC or message boards which are covered thoroughly in manuals. They respond with, of course, "RTFM"
Am I the only one who thinks that a Manual is a pretty lame source of information to reach for first-thing?
I have a few sources I go through, usually the manual is one of them, but I _Always_ first ask a person who might have the answer on hand. Manuals are not often things which lend themselves to answering typical questions such as "Can I blah?". The problem with "Can I blah" being looked up in a manual, among other things, is that often there are numerous synonyms for 'blah', and only one of them is ever used in the book, especially the index.
Perhaps they mean "Read the entire manual before even using the product". The obvious problem here is that manuals are getting longer every day. I've heard that some Linux Distro comes with a 2000 page manual just for getting it installed. Obviously, to read an entire manual before using a product would leave little time for using any products, and leave you more or less unknowledgeable about the product.
Then there's the problem of phrasing. Manuals may answer your question, but only burried in a lot of other information which isnt related to what you're actually working on. A person who knows already, however, can simply answer your question.
Slashdot, however, is far too public and non-specific. There's no reason to ask this kind of question on slashdot, get some friends or something.
-- 'The' Lord and Master Bitman On High, Master Of All
If your controller just spontaneously lost it's configuration, it's a problem with the card. Call the manufacturer and get a replacement. If they will configure it for you before they send it (which shouldn't be difficult for them), you should be able to just swap it in and go.
You'll need to do something like this, since you won't be able to get at the data on the drives unless you can hook them up to a RAID controller that will recognize the particular flare code etc of your setup.
If you can stomach losing the data (you backed up the important stuff, right?) then you could try starting over from scratch, but I would not trust your RAID controller if I were you. Replace it or don't use it.
Under capitalism man exploits man. Under communism it's the other way around.
I've worked quite a bit with AMI controllers and Adaptec. At work we looked at using an Adaptec ZCR card but chose not to for the following reason.
AMI Megaraid(and now LSI) write a bit of config info to each disk and to the controller. On these cards, you need to know the drive designations (which is drive1, which is drive 2, etc and the stripe size (how much data to write to the first disk before moving on to the second). On these controllers, if your card goes belly up you can usually put in a new card which will detect that your drives still have a configuration and use it. Otherwise, you can create a new configuration of the drives (same raid level, same stripe size, each drive with same designation) and it will access the data just fine on a reboot. (probably 75-85% of the time. The rest of the time you are just SOL and need to get out tape.)
Adaptec's ZCR card we were testing and going to ship had the unfortunate effect that when an array was created, it immediately initialized (format) all the data.
This is something you should check into. Perhaps the highpoint card will let you make a new array and reboot. Or it might automatically initialize and wipe out all your data before letting you use it.
Hope this helps
--