RAID is not a backup. Here's what every SME should actually have.

The most expensive five words I hear in a room with a small or mid-sized business owner are: "We have RAID, we're fine."

It's the kind of sentence that sounds technical enough to be reassuring. The owner has a NAS or a server in the corner of the office, the IT contractor set it up with RAID 5 or RAID 6 a few years ago, and the assumption — repeated quietly across thousands of Indian SMEs — is that the data is safe. Two months later, when ransomware encrypts every file on the network, or when somebody at the front desk accidentally deletes a folder that contained six years of client invoices, the same business owner is on the phone asking how this could have happened. They had RAID. They were fine.

RAID is not a backup. It is, at best, a small and specific protection against one type of failure. Most of the things that actually destroy SME data — and we see them every month — RAID does nothing about. Understanding why that's true, and what to have instead, is one of the most valuable hours an SME owner can spend.

What RAID actually does

RAID stands for Redundant Array of Independent Disks. It's a way of organising several hard drives so that, if one of them fails, the data isn't lost. The remaining drives keep working, the failed drive can be replaced, and the array rebuilds itself. That's it. That's what RAID protects against — physical failure of a disk in the array.

This is genuinely useful. Hard drives do fail, mechanical drives more often than solid-state ones, and any reasonably-sized storage system will eventually have a drive die on it. RAID means that drive failure becomes a planned maintenance event rather than a data-loss event. For that specific scenario, RAID works exactly as advertised.

The problem is that drive failure is one of the smaller risks to your data. The other risks are larger, more frequent, and entirely outside RAID's scope.

What RAID does not protect against

Ransomware. If somebody on your network opens the wrong attachment and ransomware starts encrypting files, RAID will faithfully replicate the encryption across all the drives in the array. The redundancy makes the encrypted data more reliable, not more recoverable. We see this almost every month. By the time the business calls us, every accessible file has been encrypted, and the RAID is doing its job perfectly — preserving the encrypted state across multiple disks.

Accidental deletion. If the office manager deletes the wrong folder, RAID will delete it across all the drives in the array, instantly and identically. There is no "undo" button on RAID. The data is gone.

File corruption. If a database file becomes corrupted — software bug, sudden power loss mid-write, a disk controller getting confused — RAID writes the corruption faithfully to every disk in the array. The array reports as healthy. The file is unreadable.

Fire, flood, or theft. If the room containing the RAID array burns down, floods, or gets stolen, every disk in the array goes with it. The redundancy was within the box. The box is gone.

RAID controller failure. Less common, but when it happens, the data on the disks is technically intact but unreadable without an identical controller. Recovery is expensive and not always successful.

A disgruntled or compromised insider. RAID has no concept of "this person shouldn't have done that." Whatever destructive action gets executed, RAID will replicate it.

The pattern across all of these is the same: RAID protects the array from itself. It does not protect your data from the world.

What an actual backup looks like — the 3-2-1 rule

The simplest framework for thinking about real backup, and the one we recommend to every SME we work with, is the 3-2-1 rule. It's been the industry standard for over a decade for good reason: it survives almost every failure mode that actually destroys data.

The rule is: three copies of your data, on two different types of media, with at least one copy off-site.

Three copies means the original, plus two backups. Not the original plus one backup. Two backups, because if your primary backup is corrupted or compromised, you still have a fallback.

Two different media types means not all on the same kind of storage. The classic version was disk and tape; the modern equivalent is local NAS and cloud storage, or local disk and a USB drive that gets rotated off-site. The point is that the failure modes of one media type — controller bugs, firmware issues, supply-chain attacks — don't take all your copies down at once.

One off-site copy means at least one backup is somewhere geographically separate from the primary. If your office burns down, gets flooded, or has its IT room broken into, the off-site copy survives. "Off-site" today usually means cloud — AWS, Azure, Backblaze, an encrypted off-site server — but it can also mean a USB drive that someone takes home each Friday, as long as someone is actually doing it.

That's the entire framework. It is not difficult to implement. It is not expensive — for a typical SME, the additional cost over a "RAID is fine" setup is in the range of a few thousand rupees per month for cloud storage and a one-time setup for the automation. The reason it doesn't get done is not cost. The reason it doesn't get done is that nobody told the SME owner that RAID alone wasn't enough.

What this looks like in practice

Last year we worked with a Canadian printing studio called Team Printing Inc. that had been hit with a cyber incident and lost most of their working files. They had local storage. They thought they were covered. The recovery process took weeks, and the rebuild was a complete redesign of their storage architecture from first principles — Synology NAS with RAID for the local copy, encrypted off-site backup to a second location, automated nightly snapshots, and a recovery test that actually got run quarterly. The full case study is here if you want the technical detail.

The pattern we saw with Team Printing is the pattern we see with most SMEs that come to us after an incident, not before. The data was nominally protected. The protection was protecting against the wrong thing. By the time anyone realised, the data was gone or compromised, and the recovery cost — in money, in time, in client trust — dwarfed what proper backup would have cost over a decade.

The five questions every SME should be able to answer right now

If you're an SME owner, ask your IT contractor or your in-house technical person these five questions. If they can't answer them clearly, that's your weekend project — or, more accurately, that's the conversation you should have before something forces it.

1. Where, exactly, are our backups stored? "On the server" is not an answer. The answer should name specific physical and logical locations: this NAS in this office, this cloud bucket in this region, this external drive in this safe.

2. When was the last successful backup, and how do we know it succeeded? Many backup systems run silently for years and silently fail for the last six months. The answer should reference an automated alerting system or a human who checks regularly.

3. When did we last test a restore? A backup that has never been restored is a hope, not a backup. Restoration should be tested at least quarterly, ideally on a small slice of real data that someone actually needs to verify.

4. If our office disappeared tonight, how long until we're operational from somewhere else? This is your Recovery Time Objective. You don't need a number to four decimal places, but you need a rough one — hours? Days? Weeks? — and your backup architecture should be designed to meet it.

5. If our backup itself were attacked, what's the next layer of protection? This is the question most setups fail. Modern ransomware actively seeks out and encrypts backup destinations. The right answer is some form of immutable backup — write-once-read-many storage, snapshots that can't be deleted by anyone but a separately-credentialled admin, or air-gapped media that's physically disconnected when not in use.

If you can answer all five clearly, you have a real backup architecture. If you can't, you have RAID and a hope.

The honest truth about backup

Backup is one of those topics that gets ignored until it suddenly matters more than anything else. Every business owner who's been through a serious data loss event will tell you the same thing in retrospect: it was the cheapest thing they could have done before, and the most expensive thing they could have neglected. The conversation about backup is not interesting until the day it becomes the only conversation in the room.

If you're reading this and quietly suspecting that your own backup story isn't as solid as it should be, that suspicion is usually right. The fix is not difficult, not expensive, and not exotic. It just has to be done before the day it's needed — and that day is rarely scheduled in advance.