Advantages of RAID6 over RAID5 For Video SurveillanceBy: Carl Lindgren, Published on Apr 15, 2009
For large scale video surveillance deployments, like casinos, the enhanced redundancy provided in RAID6 over RAID5 is critical to minimizing video loss and ensuring system performance. [Note: If you are not familiar with RAID, view a RAID tutorial and a general comparison between RAID5 and RAID6 [link no longer available]]
We have been recording all of our cameras using an NVR system since late 2003. Our original system consisted of 28 servers, each recording up to 32 cameras. The servers originally used 16-bay RAIDs with 250GB drives in a RAID 5 configuration. The majority of the RAIDs were SCSI/PATA, which means they used standard IDE desktop drives in the RAID enclosure. These drives were not designed to handle continuous video recording and began to fail at an alarming rate within a year. Our drive vendor replaced these with RAID Edition drives in early 2005, which resolved some of the issues. At the time, we had a bit over 830 drives in use.
Even after replacing all 830 drives, we still experienced drive failures. This is normal for any large system. It has been estimated that approximately 1% of installed hard drives will fail in the first year of operation; with that rate climbing as the drives age. There are many possible ways for hard drives to fail and RAID systems can recover from most failures by rebuilding the RAID system using the parity information that is striped across the drives.
RAID 5 uses one parity stripe to store data that can be used to reconstruct the contents of a failed drive onto a replacement drive. That is the reason why most RAID manufacturers recommend installing at least one global hot spare in each RAID chassis. When a RAID encounters an error with a hard drive, it “rebuilds” the data that was on the failed drive onto the spare using the parity data. The failed drive can then be replaced with a new drive; which is designated as the new hot spare. This process can be done over and over as drives fail and theoretically will keep the RAID storage operating continuously with no data lost.
Unfortunately, there are drive failure scenarios that can not be accommodated by most RAID storage systems that are used for recording video. This issue is unique to video recording and seldom surfaces in RAID systems used by other applications. The key is that for most applications, written data is “verified” during the write process. This means that after a piece of data is written, it is read and compared to the original data before the next piece is written. If the compare process fails, the area of the disk that failed is marked bad by the drive and the data is re-written to another area of the disk reserved for that purpose.
This process works well when the system has the time to verify the write and repair any errors encountered. For most applications, there is no requirement to write data continuously and the computer’s operating system can wait the relatively short period required to verify each write and relocate data if an error is encountered.
Video recording is a completely different animal. It has been estimated that CCTV video recording is 90% write versus 10% read. I am of the opinion that is a conservative estimate. An analysis of our system leads me to estimate that the percentages are somewhere between 99% to 1% and 99.9% to 0.01%. RAID systems set up for video recording seldom, if ever, are set up to verify the data as it is written.
This sets up a possibly fatal scenario. One of the failure modes of computer hard drives is something called “Read Element Failure”. The best definition I can find of that is the drive is unable to read all or part of the data written to it. This could be the result of a complete failure of one of the read heads, or just a bad area of a disk that has not been relocated by the drive’s automatic systems.
Since the drives in a video recording system don’t normally automatically read the data after it is written and the system operators only play back a very small fraction of the video being recorded, a drive could happily chug along writing data that is unreadable for a long time. Neither the system nor the operators would ever know that there is a problem. That is, until a drive fails with a problem that is recognized by the RAID system.
When the RAID system encounters a drive failure that it recognizes, it will attempt to rebuild the RAID set using the parity data recorded across all of the drives. That is where the problem becomes acute. If the RAID system also contains a drive that has a Read Element Failure, it is very possible that bad area contains parity data. If it does, the rebuild will fail.
On a RAID 5 system, if a rebuild fails because the parity data is corrupt or unreadable, the system now has two bad drives and the RAID set is lost. This happened to us at least six times during the three years that we used our original RAID 5 systems.
RAID 6 works a bit differently than RAID 5. Although it can encounter the same drive failure scenarios as RAID 5, its ability to recover from them is greatly enhanced by the method RAID 6 records the parity data. Instead of writing one parity stripe across all drives in a RAID set, RAID 6 writes two completely independent parity stripes. There are two advantages to this: RAID 6 is able to recover from the simultaneous failure of two drives in the enclosure and its two parity stripes are in different areas, allowing the system to read parity even through multiple failures.;
This has been proven by us in our recording environment. In 2006, we replaced all of our servers and RAIDs. Our new RAIDs were set up, at our insistence, as RAID 6. Although we have experienced at least three instances where two drives failed in an enclosure, including at least two instances where the second drive failed during the rebuild process, we have never lost any data. The systems rebuilt both failed drives and continued to run flawlessly.
For these reasons, I would never recommend using RAID 5 in a critical video recording environment. The risks of data loss are too great.