When shopping for a RAID solution, I noticed that there are a lot of companies that sell solutions with non-standard proprietary RAID controller cards. What that means to me is that if I am using Mirrored RAID 1, and I have a total catastrophe (where the card dies and I cannot get it replaced for whatever reason), I cannot just take one of the drives in the mirrored set and hook it up to any computer and be able to retrieve all of the data off of it. If it is a standard RAID implementation then I CAN do this.

My question is what are the advantages of having a proprietary RAID implementation?? Isn't it always better to find cards that are standard RAID? Also when shopping, what do you look for to know what sort of RAID implementation it is, because it's not like they mark this information clearly on the box.

Any thoughts guys?

EDIT: OOps .. typo... I meant RAID 1 not RAID 0 ....


When you have a RAID device, even a simple mirrored one, there needs to some metadata about the array stored. At a minimum you need a way to identify the list of devices involved in the array, and in more complicated setups there might be information about stripe size and other tunable parameters.

So where do you store the metadata? There are two choices. The first possibility is to store the disk configuration in memory associated with the card, perhaps with the BIOS configuration or on non-volatile storage on the card itself. The other is to store it on the disk themselves, normally at either at the beginning or the end. The beginning is more robust because then you can still find it trivially even in cases where the disks aren't all the same size, which is normally a supported option (the array just becomes the size of the smallest one). This lets you do a disk-to-disk clone onto a larger unit with a tool like dd when you've got a failing disk, or want to play other tricks to upsize the array; if you know what you're doing it's more flexible. To keep the OS from overwriting this metadata, typically the card will remap the drive so that the first cylinder (or last) is reserved for the card's use rather than being shown to the BIOS.

An advantage of storing the metadata on the disks is that you don't lose any configuration information if there's a power outage long enough for the card's associated battery to run down. It also means that you can put the disks into another system, and as long as you've got the same controller there it can always figure out how the array is configured now matter how you connect the drives. These are important requirements for some applications, particularly when you get into more complicated striping configurations where you have little hope of guessing the right order to reassemble things if you lose that information.

The downside to storing the configuration on disk is that the obvious place to put it, the beginning, is where the operating system has its partition table, boot record, and other important stuff. So if you take a disk with RAID metadata stored there and put that into another system that doesn't have that controller, you won't be able to read it, barring some hairy tricks to skip past the metadata.

Since both use cases, memory vs. disk metadata, have their trade-offs, you can't satisfy everyone with either approach. Your thinking that one or the other is "standard RAID" isn't really accurate, there is no strong standard for RAID metadata. The only one I'm aware of is SNIA RAID Disk Data Format (DDF), which I haven't seen get enough traction among commercial RAID vendors yet to really be considered anything besides a reference standard. That puts the metadata at the physical end of the disk and just deals with the added complexity that adds, so a SNIA DDF compliant RAID1 should work fine standalone. Not all vendors are so capable, and some are using ancient designs that didn't consider this issue and that nobody wants to reengineer now. Now you know the right question ask though: "where's the device metadata stored?", and if it's on disk, "which part of the disk is it physical stored at?".

| improve this answer | |
  • 1
    So what you are saying is: Depending on what part of the disk the meta-data is stored on, it affects the ability to take a RAID 1 disk and being able to attach it to another PC in order to read information off of it? – 7wp Sep 1 '09 at 22:54

I prefer standard options for exactly the reason that you specified. If the thing (in this case RAID controller) dies how to I recover my data if that card isn't available, or takes weeks to get back to me.

| improve this answer | |
  • 1
    +1; also worth considering is what do you do if the company making the proprietary component goes out of business? – Maximus Minimus Sep 1 '09 at 9:15
  • Another excellent point – mrdenny Sep 1 '09 at 23:00

All hardware RAID cards are proprietary in some fashion. If you decide to swap RAID controllers (to a different brand), you're generally not going to have a pleasant experience trying to get the array working again. Generally, you will also not be able to just plug the drives into a machine and pull data off them without the RAID card (this will depend on the controller and the type of array obviously).

I have to ask though, why would you have a machine in production that you don't have a spare for?

| improve this answer | |
  • I'm not a systems administrator by trade, I'm a developer. I'm mostly asking from my experience working with RAID here and there. – 7wp Sep 1 '09 at 4:30
  • By the way I do have a couple of raid cards here at home that I can set up RAID 1 on it, and then turn around and plug one of those drives in to any other machine and it will work. I have done this several times during the life of the card... (don't ask why i did that :-)) – 7wp Sep 1 '09 at 4:35
  • 3
    "why would you have a machine in production that you don't have a spare for?" You've obviously never worked for a small or medium sized company, where there is no justification for having an expensive piece of equipment on hand just for spare parts. We solve this little issues by having good backups and the knowledge that everything can readily be migrated to another machine, even if it's only a PC. – John Gardeniers Sep 1 '09 at 4:45
  • Actually, I've only worked in small and medium sized companies. Regardless, I still would not put a machine into production without the appropriate spares (unless the company could stand multiple days of downtime). If I don't have the spare part available, it would be put in the purchase order. Doing anything else is just irresponsible on the part of the sysadmin. – rodjek Sep 1 '09 at 6:57
  • If your beancounters are really so stingy that they wont allow you to have a spare RAID card, use software RAID. Sure it's lacking some of the feature of hardware RAID, but it still works. – rodjek Sep 1 '09 at 7:04

There ARE software solutions that will recover the data on your drive, IF you know what the block and stripe size are on the disks, so in the worst case scenario you can just let it do its thing and it will copy all of the data back for you.

You have a very valid reason to be concerned though, so if you do end up with one of these off-market cards, try to buy an extra one, just in case - and then you can swap it in if need be.

That said, if you were to just use RAID 1 (mirroring) without the striping, if the controller dies you can just plug them straight back into a non-raid interface and they should work out of the box.

Update: Just saw your edit to change from RAID10 to RAID1, if this is the case, unplugging the disks from the RAID controller and plugging them straight back into the motherboard should work just fine in this case.

| improve this answer | |

There's no simple answer, as it's going to depend on just what controller is fitted as standard. Some standard cards will be harder to replace than some non-standard. Either way, the most important thing is to ensure the controller is good quality and readily available.

| improve this answer | |

The possibility of reading back your data (assuming a RAID1 array) depends on where the RAID controller puts its metadata. For example, years and versions ago 3Ware controllers used to put it at the beginning of the disk, so you saw nothing when you hooked the disk up on a motherboard controller. However, with some tricks and the usage of the loopback driver in Linux kernel (specifying block offset) it could be read just like a normal disk and partitions.

If you want to stick to hardware RAID, then do your research about this issue. The easier but more expensive solution is to buy 2 cards of the same type, so you have a coldspare in your drawer when things go south.

| improve this answer | |

If you're looking for host-based RAID, there are a fairly small number of outfits that still manufacture RAID controller cards. Within a given manufacturer, the format of the RAID metadata tends not to vary. In some cases this even applies between SAN and host-based RAID solutions sold by the same manufacturer. A couple of examples of this are:

  • Mylex used to make SAN controllers (DAC-FFX) and host-based F/C RAID controllers (ExtremeRAID 3000) that used the same RAID metadata. You could take disks from a DAC-FFX based SAN and put them on an ExtremeRAID 3000 and expect it to work.

  • HP SmartArray and MSA1000/1500 (FC-SCSI) SAN systems used the same format and could interchange arrays in the same manner.

However, I've never found an instance where I could get documentation about the RAID metadata format from the manufacturer.

The best outcome you are likely to get is to get the manufacturer to tell you which cards support compatible RAID metadata formats and get something secondhand of ebay as a backup to read the arrays if your primary card goes phut.

This might be an area where you are better off sticking to 'reputable' manufacturers or getting your vendor to specify a disaster recovery strategy in their RFP submission.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.