RAID Keeps Your Server Running.
It Is Not a Backup.

What RAID actually does well

RAID, which stands for Redundant Array of Independent Disks, was designed to solve a specific problem: keeping a system available when a disk fails. On that narrow job, it is effective and worth using. It deserves an honest description before we discuss what it does not do.

Different RAID levels work in different ways. RAID 1 mirrors data across two or more disks, so if one disk dies, the others continue serving data without interruption. RAID 5 and RAID 6 distribute data and parity information across three or more disks, tolerating one failed disk (RAID 5) or two failed disks (RAID 6) without taking the array offline. RAID 10 combines mirroring and striping, offering both redundancy and performance. In all cases, the core purpose is the same: keep the server up and keep reads and writes available even when hardware fails.

This is a real benefit. For a business that cannot afford unplanned downtime every time a hard drive dies, RAID reduces that risk meaningfully. If your NAS or server runs RAID, that is a sensible choice for availability. The problem arises when availability is confused with backup. They are different properties, and RAID only provides one of them.

This page is not an argument against RAID. It is an explanation of why RAID, on its own, does not protect you from the data-loss events that matter most, and what needs to sit alongside it.

Why RAID is not a backup

RAID protects against a specific hardware event: a disk failing. It does not protect against data loss. The distinction matters because most of the scenarios that actually cause small businesses to lose data are not single-disk hardware failures.

• RAID mirrors every change you make, including mistakes. This is the most important thing to understand about RAID. When you accidentally delete a folder, overwrite a file with the wrong version, or a software bug corrupts a database, RAID faithfully propagates that change across every disk in the array instantly. By design. The moment the deletion or overwrite happens on the live volume, it is mirrored everywhere. There is no concept of "the copy before the mistake." RAID gives you redundant disks, not a second chance.
• Ransomware encrypts the array along with everything else. Ransomware runs as a process on the operating system and encrypts every file it can reach through normal file-system access. Because the RAID array is a mounted volume that the OS writes to, ransomware can reach it the same as any other attached storage. CISA's #StopRansomware guidance specifically recommends keeping at least one backup copy offline or air-gapped, meaning not accessible from the running operating system, precisely because online storage, including RAID, is reachable and can be encrypted. A RAID array that is fully encrypted by ransomware is a RAID array you cannot read.
• RAID controller failures and rebuild risks are real. RAID protects against a disk failing inside the array, but it does not protect against the controller itself failing. A failed RAID controller can make the entire array unreadable until you replace the controller and hope the configuration is recoverable. There is also a well-documented risk during RAID 5 and RAID 6 rebuild operations: when a disk fails and the array is rebuilding parity across the remaining disks under high I/O load, the stress increases the chance that a second disk fails before the rebuild completes. A second disk failure during a RAID 5 rebuild takes the array down entirely. These are not exotic failure modes; they are common enough that the storage industry has a name for the phenomenon.
• There is no off-site copy. Every disk in a RAID array sits in the same enclosure, in the same room, in the same building. A fire, a flood, a theft, or a power surge that damages the hardware can take every disk simultaneously. CISA's 3-2-1 backup rule, which is the most widely cited standard for resilient backup, calls for at least one copy stored off-site and separated from the physical location of the primary data. A RAID array, no matter how many disks it contains, is still one location. It satisfies none of the off-site requirement.
• RAID has no version history or point-in-time recovery. A backup solution retains copies of your data at multiple points in time, so that if a problem is discovered days or weeks after it occurred, you can recover from before the problem happened. RAID has no such concept. What is on the array right now is what you get. If ransomware encrypted your files three days ago and you are only discovering it today, the array reflects the encrypted state. There is no way to ask RAID for yesterday's version.
• RAID is at best one copy in one place. CISA's 3-2-1 rule requires three copies of data, on at least two different types of media, with at least one copy off-site. RAID, regardless of the level you are running, represents one copy on one machine. It does not give you the second media type, and it does not give you the off-site copy. Mapping RAID onto the 3-2-1 framework: it contributes to copy count only insofar as you count each disk individually, which is not the intent of the rule. You still need two additional independent copies, at least one of which is off-site, to satisfy the 3-2-1 standard.

The pattern across all of these gaps is the same: RAID is online, writable, co-located storage. Any threat that can reach your operating system, or any physical event that can affect your server room, can reach the RAID array. That is exactly the threat profile a backup is designed to protect against.

What a complete plan looks like

The good news is that adding proper backup alongside RAID is not complicated. RAID continues doing what it does well (keeping the server available through a disk failure) while backup fills the gaps that RAID cannot address. The following criteria are grounded in CISA's 3-2-1 guidance and #StopRansomware recommendations.

• Apply the 3-2-1 rule. Keep at least three copies of your data on at least two different types of media, with at least one copy held off-site. CISA recommends this as a baseline against both ransomware and physical disasters. Your RAID array can serve as one of your local copies, but you still need a second independent copy and a separate off-site copy.
• Maintain at least one offline or air-gapped copy. CISA's #StopRansomware guidance calls for at least one backup that is not connected to your system during normal operation. An off-site cloud backup stored in an environment separate from your network satisfies this requirement in a way that RAID cannot.
• Retain 30 or more days of version history. Ransomware and accidental deletions are frequently discovered long after they occur. A backup solution that retains multiple versions over time gives you the ability to recover from before the damage happened, not just from the current state of the array.
• Schedule backups automatically. A backup that runs on a defined schedule, without manual initiation, removes the dependency on habit and memory. Configure it once and let it continue running in the background.
• Enable failure alerts. You should not have to log in and check whether a backup completed. A backup solution should notify you if a scheduled backup fails or if a defined interval passes without a successful backup, so a gap does not go undetected.
• Test a restore on a regular basis. A backup that has never been successfully restored is an assumption. Restore at least one folder or dataset from your backup periodically to confirm the data is intact and you understand the recovery process before you are under pressure. Annual testing is a minimum; quarterly is better.

If you are evaluating ransomware readiness specifically, the ransomware restore readiness guide walks through the questions worth asking before an incident occurs. For a full checklist covering backup requirements for small businesses with servers and multiple machines, see the small-business backup checklist. If you are also relying on a cloud sync tool like Dropbox or OneDrive for your server files, the cloud sync vs. backup page explains why sync is not a substitute for backup either.