I’ve lost track of how many times I’ve heard some version of the same sentence: “We’re okay. The server has RAID.” Usually I hear it after something has already gone wrong.
A user deleted the wrong folder. Ransomware encrypted the file server overnight. The RAID controller failed and took the array with it. Once, a cleaning contractor unplugged the wrong rack while moving equipment and damaged the storage chassis on the way down.
Every one of those systems had RAID. None of them had a usable backup.
RAID is an excellent technology. It’s just solving a different problem than most people think it is.
What RAID actually protects
RAID exists to keep a system running when a drive fails. That’s it.
If a disk dies in a RAID 1 mirror or a RAID 5 array, the server usually keeps working while you replace the failed drive. Users might not even notice anything happened. That’s exactly what RAID was designed to do, and it does the job well.
The mistake is assuming that because your data exists on multiple drives, it’s somehow backed up. It isn’t. Those drives are all part of the same storage system. If something bad happens to that system, every copy can disappear at once.
The failures RAID can’t save you from
Hard drives are only one way to lose data. In practice, I see these problems far more often:
- Someone deletes the wrong folder
- A user overwrites an important file
- Ransomware encrypts every shared drive
- A software update corrupts a database
- A RAID controller fails and corrupts the array metadata
- The server is stolen
- The building floods
- The office catches fire
None of those situations care how many disks are in your RAID array. If bad data is written to one drive, RAID faithfully writes that same bad data to every other drive in the array. It’s doing exactly what it was designed to do. That’s not a fault. It’s simply not backup.
The most expensive drive failure is often the second one
There’s another misconception I run into regularly.
A drive fails in a RAID 5 array. Everyone breathes a sigh of relief because the server is still online. They order a replacement drive, swap it in, and rebuild the array. Usually that’s the end of the story. Sometimes it isn’t.
Large drives take hours — or even days — to rebuild. During that time every remaining disk is under heavy load. If another drive fails before the rebuild completes, recovery becomes much more complicated, and in some RAID levels, impossible.
RAID reduces downtime. It doesn’t eliminate risk.
RAID gives you availability. Backup gives you recovery.
Those are different goals. Availability means people can keep working when hardware fails. Recovery means you can get your data back after something goes wrong. Good infrastructure needs both.
I’ve had clients invest thousands of dollars in enterprise servers with redundant power supplies, ECC memory, hardware RAID, and hot-spare disks — then discover their only backup was a USB drive someone remembered to plug in “most Fridays.” That’s not a backup strategy. That’s optimism.
The 3-2-1 rule is still the standard
People sometimes assume backup planning has become more complicated over the years. It really hasn’t. The 3-2-1 rule is still one of the simplest and most effective approaches.
Keep three copies of your data, on two different types of storage, with one copy stored off-site. That’s it.
Your primary server is one copy. A local backup appliance or NAS might be the second. Cloud storage or another physical location becomes the third. There are plenty of ways to implement it. The important part is that one problem can’t destroy every copy at the same time.
Test the backups you already have
This is the part people skip.
Backup software reports that every job completed successfully. Everyone assumes everything is fine. Six months later they need to restore a critical folder and discover permissions weren’t being preserved. Or the backup destination filled up weeks ago. Or nobody remembers the encryption password.
A backup you haven’t restored is an assumption. I like to schedule occasional test restores for exactly this reason. It doesn’t have to be an entire server. Restore a folder. Recover a virtual machine. Verify the process actually works while nobody is under pressure. You’ll learn far more from a successful test restore than from months of green check marks.
Storage planning matters too
One reason backup projects get delayed is because nobody knows how much storage they’ll actually need. That estimate is usually done on a whiteboard or in a spreadsheet, and it’s often wrong.
The free RAID Storage Planner in the MB Networks SysAdmin Toolbelt makes it easier to compare common RAID levels and understand how much usable capacity you’ll have before you start buying disks. It’s a planning tool — not a substitute for a backup plan.
Build for the day something goes wrong
Most storage systems spend years doing absolutely nothing interesting. That’s exactly what you want. The real test comes on the one day a drive fails, someone deletes the wrong folder, ransomware gets in, or the building loses power at the worst possible moment.
If the only thing standing between your business and permanent data loss is RAID, you’re depending on a technology that was never designed for that job.
Keep RAID. It’s worth having. Then build a backup strategy that assumes, sooner or later, something else will fail too.
Questions or corrections? info@mb-networks.ca