Jason Cahill

In my last couple of posts, I’ve been spending some time talking about how to set up your front-end physical disks so that you can maintain high availability. In one of my diagrams, I mentioned RAID 1 (mirroring) for the physical disks. I wanted to spend a few minutes on this topic and hopefully help dispel the myth that RAID is backup, just in case you didn’t know that.

RAID = Redundant Arrays of Independent Disks. The keyword here is Redundant. RAID helps you solve two important problems: (1) you get faster read performance because you have multiple physical disks serving your requests, and (2) depending on your configuration, you can survive a hard disk failure with no downtime.

There are tons of RAID standards and the goal of this post is not to cover the info that you can read elsewhere on RAID 0, 1, 5, or 10. Instead, the goal is to talk about the myth that RAID = Backup. For some folks, the appeal of RAID 1, 5, and 10, all of which offer some form of redundant data copies, is that they “don’t need to backup their data anymore because you can lose a physical hard drive.” While that’s true, redundancy only solves one aspect of backup: you still have your data in the light of a physical hard drive loss. But, here’s some of the ways you can suffer data loss for which RAID will not help you:

• Multiple hard disk failures. With the exception of RAID 6, which is pretty uncommon in practice, most forms of RAID can only suffer a single hard drive failure before you incur data loss. Because heat is the most common cause of hard disk failure, you want to insure that your disks are adequately cooled. Another important consideration: if at all possible, buy drives from multiple manufacturers or in separate production lots. It is more common for drives produced in the same lot, by the same manufacturer, to fail at or very close to the same time when running in similar conditions.
• Oops… deletion. Unless you have a backup strategy, you cannot recover from mistakes where the wrong files are deleted.
• Data corruption. The worst cause of failure without backup is data corruption. As far as any user or admin can tell, all of their data is present and available. Only when you try to access the content do you realize that it is ruined. Again, without backup, you are lost.
• Physical theft, fire, or damage. Finally, most RAID arrays are physically located together. Any situation that wrecks the physical location of your drives also wrecks your data. Offsite backup is a must if you care about your data.

So, why use RAID at all then!? Because it still has value from redundancy (which is what it was meant for). But, this is what always causes me to chuckle when people say “Never use RAID 0… you can lose everything!” Well, yeah… and you can too with 1, 5, and 10, under the right conditions.

Bottom line: backup is a necessary evil if the data you are storing is meaningful. This last part is important, though, too: the data must be meaningful! For example, it’s quite alright to have no backup of your System drive and Program files, so long as you have a way to rebuild the same setup in a reasonable period of time. Similarly, as we will talk about later with respect to database backups, if you can afford to lose “short term data” – like a backup you just started a few minutes ago, and your primary copy is safe, then you may want to opt for RAID 0 configurations that will suffer total data loss during failure, but won’t result in a perceivable outage to a customer, or a risk to your service’s SLA. When the system is working properly though, you will get the fastest read/write performance possible. More on that later…