RAID Is Uptime, Not History
Redundancy keeps your array online through a drive failure. It has never been a substitute for backup.
01What RAID Actually Buys You
When a drive in a mirrored or parity array fails, the system keeps running. That is genuinely useful — in a server environment, unplanned downtime costs money, and a RAID 1 mirror or a RAID 5 or 6 parity set can absorb a single failed member without dropping off the network. You swap the dead drive, the array rebuilds, and users never notice. For availability, that is exactly what RAID promises to deliver, and it delivers it well.
The confusion starts when people mistake availability for safety. The two are related but they are not the same thing. A RAID array is one logical volume. It lives in one place, usually in one box, powered by one controller. What it protects against is narrow: the mechanical or electronic failure of an individual member drive. Nothing else.
02The Four Things RAID Does Not Survive
Deletion and overwrite. Every member drive in your array reflects every write the operating system makes — instantly, completely, in both directions. Delete a folder on a RAID 6 volume and that deletion is faithfully written to every parity stripe within milliseconds. There is no version stored elsewhere, no shadow copy held on a different member. The redundancy that kept you online during a drive failure actively helps propagate the destruction of your data. Sync is exactly the same problem: a mirror that moves every change is not a second copy in any meaningful sense.
Controller and firmware failure. The drives survive, but a failed RAID controller — or a firmware update that corrupts its configuration — can leave a healthy array completely unreadable. Proprietary controllers are particularly risky here: the stripe width, block size and member order are recorded in controller NVRAM or on drive headers in a vendor-specific format. Without a matching controller, or without documentation of the exact configuration, forensic reconstruction is slow and expensive. Identical drives, zero accessible data.
Ransomware and logical corruption. Ransomware does not care how many drive spindles your volume spans. It encrypts files through the file system, and the array dutifully writes every encrypted byte to every parity stripe. By the time the ransom note appears, the damage is complete and mirrored. The same applies to a runaway process, a botched migration script, or a file system that quietly develops corruption the RAID layer never sees — because RAID operates below the file system and has no visibility into what the data means.
Physical co-location disasters. Fire, flood, power surge, or theft takes the whole box. A RAID 10 array with four drives in one chassis gives you exactly zero protection against any event that affects the chassis. Off-site backup is the only answer to this failure class, and an array — however large — cannot be its own off-site copy.
| Event | Does the array help? |
|---|---|
| A single disk fails | Yes. That is precisely its job, and it does it without downtime. |
| A second disk fails during the rebuild | Only with double parity or a three-way mirror. |
| You delete the wrong folder | No. It is deleted on every member at once. |
| A file is overwritten with garbage | No. Both halves receive the garbage faithfully. |
| Ransomware encrypts the share | No. It writes through the filesystem like any other client. |
| The controller or firmware misbehaves | No — and it can corrupt every member together. |
| Fire, flood, theft of the box | No. Redundancy is not distance. |
Ransomware and logical corruption. Ransomware does not care how many drive spindles your volume spans.
03What to Do Instead
Use RAID for what it is good at: keeping a service online while you replace a failed drive. Run your rebuilds promptly, because a degraded array is genuinely vulnerable — during a rebuild, the remaining drives work harder and a second failure in a RAID 5 is unrecoverable. Watch your array's health through whatever monitoring interface your controller or OS exposes.
Then treat backup as an entirely separate problem. Real backup means at least one copy that is not attached to the same machine, not writable by the same processes, and carries enough version history that you can recover from a bad Tuesday as well as a dead drive. The array is the floor beneath your service. Backup is the net below that.
RAID is uptime. History is backup. You need both.
Notes from the bench
- [1]
The riskiest hours in an array’s life are the rebuild, when every remaining disk is read end to end at once. ↩