You already know that you shouldn't be treating your RAID array as a backup, but in case the point hasn't settled in, I'm here to remind you once again. Your RAID array, regardless of how it's configured, is not a backup.

If you want to operate a RAID array without any additional backup in place, go nuts. I won't tell you what to do. My goal here is to dispel the illusion that redundancy is synonymous with a backup, and hopefully paint a clear picture as to why even RAID arrays with redundancy carry big risks of data loss.

RAID is a backup, until it's not

Once that data goes missing, it's gone forever

Getting into the semantics of a "backup," by definition, RAID is a backup. A backup is just storing a second copy of your data. The problem isn't that certain RAID arrays meet the definitional bar for a backup. It's that if you lean on a RAID array as a true backup, you're exposing your data to unnecessary risk.

There are two main RAID levels that store a copy of your data. There's RAID 1, which mirrors your data across two, or more, drives. If one drive falls, you can toss in another and copy your data over once again. Then, there are the parity levels, the most prominent of which is RAID 5. It stripes parity blocks across the array, meaning that any single drive in the array can fail, and you'll still be able to access your data and rebuild the array without any downtime. RAID 6 takes the idea even further with double parity, giving you a total of two drive failures to rebuild the array.

Do you see the problem with treating RAID as a backup? You are offered, at most, two drive failures, and that's with a fairly exotic (and expensive) RAID 6 array. Even in that setup, if a single drive fails beyond the tolerance, all of your data is lost. That's the problem with treating RAID as a backup. If you go over the fault tolerance, you lose all your data. That risk only increases if you build a RAID array with a bunch of identical drives purchased at the same time. If one fails, there's a good chance another drive isn't far behind.

The function of redundancy in a RAID array is to make sure you aren't interrupted. The function is not to restore your data. RAID is a warranty; a backup is insurance. Restoring lost data from a backup isn't exactly an easy process, and you'll likely have downtime in your storage if you actually lose data. A RAID array allows you to keep using your storage even when a drive fails, but it's not meant to serve as a way to protect your data from being lost permanently.

OK, so what does a backup look like?

The classic 3-2-1 rule

Although RAID is a backup by definition, practically, a backup doesn't look anything like a RAID array. That's because an ideal backup is offsite. It's not on your computer, and ideally, it's not even in the same physical location. Remember, RAID is a warranty, and a backup is insurance. RAID protects you from inevitable failure, while a backup protects you from unforeseen failure.

Eventually, your drives will fail, and you'll need to replace disks in your RAID array. This is part of routine maintenance, and if you're operating an array for long enough, you should probably have drive swaps on a schedule of several years to keep everything operating smoothly. A backup will protect you from everything else. Maybe you have multiple drives fail at once. A backup will protect you. Lord forbid you fall victim to a fire, flood, or other natural disaster and your RAID array is lost or damaged in the process. A backup still protects you.

It doesn't need to be a fire or flood for you to get use out of a backup. There are small issues that could put your data at risk, such as your PC being infected with malware, or trying to write (and replicate) corrupted data. You can dream up just about any situation where data loss is a risk, and a backup will be able to get your data back in situations where RAID can't. Ultimately, every good backup plan should follow the tried and true 3-2-1 rule — three copies of your data on two separate disks with at least one copy offsite.

Two options for a true backup

One is better than the other

So, you want to stop relying on RAID as a backup. You have two main options. You can back up your data locally, or you can back it up to the cloud. Locally, you have a lot of options. You could treat a RAID array as a backup, even, but only if that array is backing up data from somewhere else, like your PC. If you want a cheap, easy backup solution, you could even just copy data to external hard drives — though, for reasons that should be obvious, that's not the most sound backup plan.

Regardless of how you go about a local backup, there are certain situations where it won't save you; i.e. a flood, fire, or other natural disaster. You could do something like store a drive with your data backed up inside a fire-retardant safe, but that creates a whole host of other issues, including the need to constantly pull the drive out to back up new data.

You might not want to back your data up to the cloud, but really, it's the best option if keeping your data secure is your top priority. There are a ton of options out there for online backup, but Backblaze is my favorite, not only due to its relatively low price, but also the fact that it's super easy to use and comes with unlimited storage.

If you don't mind getting your hands dirty, there are more direct cloud backup options available through Microsoft's Azure Archive and Amazon's AWS S3 Glacier. Both use a pay-as-you-go structure, where you'll have to pay per gigabyte of data per month (on the scale of fractions of a cent). You also won't be able to easily access your data, and you'll need to pay a fee to retrieve your data from the cloud. For a long-term backup solution, though, neither of those should be a problem. And, if paying for software as a subscription rubs you the wrong way, let me reiterate once again — a backup is insurance.