The 3-2-1 backup rule, and why almost nobody tests it

Ask a small business owner if they have backups and almost all of them say yes. Ask when they last pulled a file back out of one and opened it, rather than just glanced at a green tick in a log, and most go quiet. That gap between “we have backups” and “we know they work” is where businesses actually lose everything. Not because nobody backed anything up. Because nobody found out the copy they had couldn't be restored until the day they needed it.

This isn't only a ransomware article, though ransomware is part of it. Hard drives fail on an ordinary Tuesday for no dramatic reason at all. Someone deletes the wrong folder. A laptop gets left on a train. The fix for all of it is the same unglamorous arrangement: enough copies, kept in different enough places, that one bad afternoon can't take out all of them, and checked often enough that you already know it works before you're relying on it.

What actually destroys small business data

Ransomware gets the headlines, but it's rarely the most common cause of data loss in a small business. Hard drives and SSDs fail without warning, sometimes years before you'd expect. Someone deletes a folder they shouldn't have and nobody notices for three weeks. A laptop is stolen from a car, or left on a train, or a coffee goes over a keyboard at exactly the wrong angle. Fire and flood damage to a server cupboard is rarer but not rare enough to ignore if your only copy of anything lives in that cupboard.

A proper backup arrangement protects against all of these at once, which is worth remembering before spending the whole conversation on ransomware specifically. The 3-2-1 rule wasn't invented for ransomware. It just happens to also work against it.

The 3-2-1 rule, plainly

NCSC's own guidance puts it simply: at least three copies of your data, on two different types of storage, with one of those copies kept somewhere offsite. Three copies means the original working data plus two backups, not three backups on top of the original. Two different media types means, for example, your working files on a laptop, one backup on a network drive or NAS, and another in cloud storage, rather than three copies that all happen to be external hard drives sitting in the same drawer. Offsite means physically or logically separate from where the other copies live, so a single event at one location, a break-in, a fire, a compromised server, cannot reach every copy in the same afternoon.

None of this needs to be complicated or expensive to be genuinely effective. It needs to actually exist, and it needs to be checked, which is where most setups quietly fall apart.

Why "it's in OneDrive" doesn't automatically count

Cloud sync tools like OneDrive, Google Drive and Dropbox are useful, and they can be a legitimate piece of a 3-2-1 setup. What they aren't, on their own, is a backup. Sync tools mirror changes. Delete a file on your laptop and, within seconds, it's deleted from the synced cloud copy too. Encrypt a folder with ransomware and the encrypted version syncs up just as obediently as a normal edit would. Version history and the recycle bin can sometimes rescue you, but only if someone notices quickly and knows exactly where to look, which turns "we have a backup" into "we might have got lucky."

NCSC's own guidance for small organisations is fairly blunt about this: it's important you know how to restore a backup, and to check it actually contains everything you think it does, not just that a sync icon shows a tick.

Why ransomware doesn't stop at the machine it lands on

This is the part that catches people out even when they thought they'd covered it. NCSC has documented real cases where ransomware "encrypted the original data on-disk, but also the connected USB and network storage drives holding data backups." Separately, it has recorded incidents compromising connected cloud storage locations too. An external drive plugged in every evening for a backup job, or a cloud backup account whose credentials sit live and logged-in on the same machine that's just been infected, is reachable the moment that machine is compromised. It doesn't matter that the drive was "for backups." Connected is connected.

Our guide to the first hour of a ransomware attack covers what to do once encryption has already started, including the specific trap of running a fresh backup job over an infected share and overwriting your last clean copy. This article is about the setup that stops you needing that guide in the first place.

Offline and immutable copies

The "1" in 3-2-1 is doing more work than it looks like. An offline copy is one that isn't reachable over a network connection at the moment an attacker or a piece of malware goes looking, whether that's a rotated external drive that spends most of its life unplugged, or a cloud backup service configured, as NCSC recommends, to deny connection requests while the storage isn't actively in use.

Immutable backups go a step further. Once written, an immutable copy can't be altered or deleted, not by an attacker with stolen admin credentials, not by a mistake, not even by an authorised user, until a set retention period has passed. It's sometimes called WORM, write once, read many, and most cloud backup providers now offer it as a configurable option rather than something you have to build yourself. It's genuinely strong protection. It's also not universal practice yet, so it's worth a direct question to whoever runs your backups: is immutability actually switched on, or just available.

What should actually be in the backup

NCSC's guidance for small organisations lists the practical scope: your website, email, invoicing and accounting data, documents and presentations, contacts, and customer information. In short, whatever the business would actually need to keep operating if a device or a server disappeared overnight. Microsoft 365 deserves a specific mention here, because it's the one most businesses get wrong by assuming it's covered automatically. Microsoft's native retention and recycle bin features are not the same thing as a backup, and they weren't designed to be; they cover a limited window and specific accidental-deletion scenarios, not a proper point-in-time recovery of a whole mailbox or SharePoint site. If your business runs on Microsoft 365, ask specifically whether it's included in your backup, separately from the rest.

The habit almost nobody keeps: testing a restore

A backup job completing successfully proves exactly one thing: the job ran without an error message. It doesn't prove the resulting file opens. It doesn't prove it's the version you think it is. It doesn't prove the whole thing wasn't quietly corrupted three backups ago and nobody noticed because nothing ever tried to read it back. A backup nobody has restored is a hypothesis, not a protection, and the only way to turn it into the second thing is to actually test it.

Testing doesn't need to be elaborate. Pick a real file or a small folder, restore it to a location that isn't the original, and open it. Check it's complete and it's the version you expected. Write down the date and what happened. That's it. Do it once a quarter and you'll know within minutes, not during an emergency, whether your backup actually works.

The bigger test: a full restore rehearsal

A single-file test tells you the mechanism works. It doesn't tell you how long a full server or an entire Microsoft 365 tenant would actually take to bring back, or whether the process is documented well enough that someone other than the one person who set it up could run it under pressure. That's a bigger exercise, and it doesn't need doing monthly, but it needs doing at least once a year rather than assumed. Our own Complete plan builds this in as a scheduled annual disaster-recovery rehearsal with a written findings report, specifically because "we're fairly confident it would work" is not the same sentence as "we tried it and it took forty minutes."

How long to actually keep versions

There's no single correct retention period, whatever a backup vendor's marketing page implies. Keep versions for long enough to catch a problem that wasn't obvious immediately: some ransomware sits dormant inside a network for weeks before it encrypts anything, so a rotation window of only a few days can mean every copy you've got by the time you notice is already compromised. At the same time, backups aren't exempt from ordinary data protection principles. UK GDPR's storage limitation rule means data, including backed-up data, shouldn't be kept indefinitely just because storage is cheap and nobody's reviewed it. The right answer is somewhere between "long enough to actually be useful" and "not forever by default," reviewed occasionally rather than set once and left.

A simple 3-2-1 setup for a five-to-ten-person office

Copy one is the live working data: laptops, a server if there is one, and whatever lives in Microsoft 365 or Google Workspace. Copy two is an automated backup to a separate cloud service, not the same sync tool that already holds copy one, with the credentials that reach it kept off the everyday machines people use for email and browsing. Copy three is the offline or immutable piece: either a genuinely rotated external drive that spends most of its life unplugged and stored somewhere separate, or a cloud backup provider with immutability switched on and confirmed, not assumed. None of that requires a data centre. It requires someone actually checking, on a calendar, that all three still work.

Where Alpha IT comes in

We set up and manage exactly this kind of arrangement: automated backups of servers, endpoints and Microsoft 365 data, copies kept isolated from the live environment so encrypting your working systems doesn't also reach your recovery copies, and tested restores rather than a green tick nobody ever checks. It's part of the Professional plan upwards, with a scheduled annual disaster-recovery rehearsal on Complete. If you already have a backup and just aren't sure it would actually work, that's a shorter conversation than a rebuild, and worth having before you need to find out the hard way.