There seems to be as many RAID 5 configurations as there are technicians in the world. Each one seems to have its own brand of drive order, stripe size and parity. In addition, the Dell Corporation added a wrinkle to configuring multiple RAIDs within a set of drives. The name for this technology was ‘container’ RAID configuration and this is how it worked.
As an example let us say there are three drives in the array and each drive is 500 gigabytes in size. Through DELLs ‘container’ configuration option a technician could take the first thirty gigabytes from each drive and build a RAID 5 from that drive set. In other words, it is as if there were three thirty gigabyte drives in the array not three 500 gigabyte drives. The remaining 470 gigabytes per drive could then be allocated as another RAID 5 that would yield a 940 gigabyte storage area for a RAID 5 configuration. For many years that was the configuration the DELL recommended for each of their servers. The first smaller RAID 5 would maintain the operating system and any user related files. The software installs would also be on this RAID 5. The second RAID would house the actual data such as spreadsheets and .doc files if this were a pure file server. This configuration was normally used for Exchange servers where the software handler and all of its configuration data was stored on the first RAID, and the second RAID would maintain all of the ‘edb’ and log files.
This particular setup was excellent; when the DELL servers did fail, the damage was usually to the front part of the drives. Since the data portion, the important portion, of the drive was farther down the drive it was usually safe and could be recovered. In addition, even if the technician swapped drives, changed configurations, or reinstalled the operating system the data portion of the RAID was always safe since all of those things happened on the front RAID.
This particular RAID setup is not used that much anymore. Mores the pity. The difficulty in recovering a RAID 5 like this was finding the break point between the first RAID and the second. They were never on even boundaries and there was no real way to calculate the actual location. I developed several tools to help me find the RAID and determine the break point in order to recover the data.
