“Our server runs RAID, so our data is safe.” It is a common sentence, and it rests on a mix-up: RAID and backup answer two different questions. RAID answers “will my service keep running if a disk fails?”. A backup answers “can I get my files back exactly as they were yesterday, or last month, whatever happens?”. Treating them as the same thing is like assuming a spare tyre protects you from a car accident.
Availability and recoverability are different goals
Availability is the ability of a system to stay reachable despite a hardware fault. Recoverability is the ability to return to an earlier, healthy state of the data after an incident, whatever its cause. A system can be highly available and still impossible to restore, which is exactly the situation of a RAID array with no independent copy.
RAID works on the first question. It keeps the service standing when a mechanical component gives way. It keeps no history, no earlier version and no copy located elsewhere. Everything written to the volume, mistakes included, is written to every disk with the same fidelity.
What RAID actually does
The acronym dates back to 1987, in a technical report from the University of California, Berkeley, by David Patterson, Garth Gibson and Randy Katz. The “I” originally stood for inexpensive and was later redefined as independent. The starting idea was to combine several small disks to gain performance and fault tolerance compared with one large disk.
Depending on the level, RAID combines three mechanisms: spreading data in stripes, keeping identical copies (mirroring) and computing parity. RAID 1 and RAID 10 rely on copies, RAID 5 and 6 on parity, and RAID 0 offers no redundancy at all. For a level-by-level comparison, see our article on RAID configurations. What matters here is that all these mechanisms protect against the failure of a disk, not against what happens to the data itself.
Five situations where RAID changes nothing
1. Deletion and human error
A folder deleted by mistake, a badly targeted clean-up script, a file overwritten by an older version: the operation is applied to every disk within milliseconds. A mirror has no memory, it reproduces the current state. Only a dated backup lets you go back.
2. Logical corruption
A failed update, a file system damaged after a sudden shutdown, a half-written database: the controller sees consistency because every block is identical from one disk to the next. Hardware consistency does not mean data integrity. Corruption can also stay silent for weeks and end up copied into every recent backup if those backups do not keep enough history.
3. Ransomware
Ransomware does not care about disks. It encrypts files using the rights of an account or a service. For the RAID array, those writes are perfectly legitimate: it protects and replicates them. Internet-exposed NAS devices showed this in January 2022 with the DeadBolt campaign, which encrypted more than 3,600 QNAP devices according to the first published counts. Another point of caution: a backup share permanently mounted on the network is exposed to the same encryption as everything else. We cover this scenario in our article on backups destroyed by ransomware.
4. The controller, the power supply and the firmware
RAID moves the point of failure without removing it: the controller card (or the NAS software layer) becomes a critical component on which reading the whole array depends. It stores metadata describing the volume geometry, and its failure, or a faulty firmware update, can make the volume unreadable while the disks themselves are intact.
Power plays a part too. An outage in the middle of a write can leave a stripe of data and its parity inconsistent, what technical literature calls the RAID 5 “write hole”. Controllers with battery-protected cache, UPS units and journaling mechanisms reduce this risk without eliminating it, and a dead cache battery on a write-back setup is a weak spot worth monitoring.
5. Disaster and theft
Fire, water damage, power surge, theft of the equipment: all the disks sit in the same chassis, in the same room, on the same power feed. Whatever destroys one disk destroys the others. A copy that must survive these events has to be somewhere else.
What RAID covers and what an isolated backup covers
| Incident | RAID | Isolated, versioned backup |
|---|---|---|
| Single disk failure | Covered (depending on level) | Useful, but slower to restore |
| Accidental deletion | Not covered | Covered |
| Logical or silent corruption | Not covered | Covered if history is long enough |
| Ransomware | Not covered | Covered if the copy is out of the network’s reach |
| Controller failure | Not covered | Covered |
| Fire, water, theft | Not covered | Covered if the copy is off site |
Rebuilds add a further risk
When a disk in a RAID 5 or RAID 6 array is replaced, the system reads all the other disks to recompute its content. On large capacities this takes from several hours to several days, and puts heavy stress on disks of the same age and often the same batch, which have lived through the same conditions. A second failure or a read error during this phase can make the rebuild fail. Without a backup, nothing is left to restore. The precautions to take are in our guide to RAID rebuilds without data loss.
From RAID to the 3-2-1 rule
The 3-2-1 rule, popularised in the mid-2000s by photographer Peter Krogh, fits in three numbers: three copies of the data, on two different media, with one copy kept off site. Our article on the 3-2-1 backup rule explains how to apply it. RAID has a precise place in it: it is part of the first copy, the production one. Multiple disks do not make two copies, because they share the same chassis, controller, file system and access rights.
Some more recent variants add a requirement: at least one offline or immutable copy that cannot be changed or erased from the production network, and restores that are tested without errors. These two safeguards prevent ransomware from taking the backup down together with production.
A word on snapshots, offered by many NAS units: they give a valuable history against deletion and corruption, but they live on the same volume. They complement a backup, they do not replace it.
Checks to run now
- Know where each copy of your data is and on which medium, counting the RAID server as a single copy.
- Keep at least one copy off site, or disconnected from the network between backups.
- Keep enough history to go back before a slow corruption, not just the latest backup.
- Restrict the rights of the account that writes backups: it should not be able to delete or modify them.
- Test a real restore, end to end, at regular intervals, and note how long it takes.
- Monitor disk health (SMART), the UPS and, where relevant, the controller battery.
If the failure has already happened
If a RAID volume is down and no usable backup exists, the first actions matter. Avoid starting a rebuild, a resynchronisation or a volume initialisation, resetting the controller or reordering the disks. Each of these writes to the disks and can erase the configuration information the analysis depends on. Power the equipment off, note the order of the disks and keep them as they are. A laboratory can then work on images of the disks without stressing the originals further. For the servers concerned, see our page on data recovery from RAID servers.
RAID remains an excellent availability tool. Combined with an independent, versioned and tested backup, it becomes one link in a complete protection. On its own, it covers just one type of incident among all those that threaten your data.