A 25-person accounting practice in Kingston, Ontario, thought its backups were covered. An external drive plugged into the server ran a backup every night, and client files were also synced to Dropbox. Two copies, two places.
Then ransomware hit in the middle of March. The external drive, permanently connected, was encrypted along with the server. Dropbox dutifully synced the encrypted files to every laptop. Rolling back each folder through version history was possible in theory, but slow and patchy, with tax season deadlines a few weeks away.
This scenario is fictional, but the trap is real and common: having backups is not the same as being able to restore. The 3-2-1-1-0 rule exists to close that gap.
TL;DR
- 3 copies of your data, on 2 different types of media, with 1 offsite, 1 offline or immutable, and 0 errors in restore tests.
- Attackers hunt down and destroy backups before encrypting. A copy that can be deleted with your network credentials isn't protection.
- Sync (OneDrive, Google Drive, Dropbox) is not backup, and Microsoft 365 or Google Workspace don't replace a real copy of your data.
Why so many backups fail when you need them
The problem is rarely having no backup at all. It's usually one of three mistakes.
Mistaking sync for backup. Sync services replicate every change everywhere, including deletions and encryption. Version history can help, but it wasn't designed to restore thousands of files at once.
Backups the attacker can reach. A NAS joined to the domain, an external drive that's always plugged in, a backup console that accepts the everyday admin account: anything the attacker can reach, they can delete. In a ransomware attack, backups are a priority target.
Restores that were never tested. The job has said "Success" every night for two years, but nobody has ever tried to bring a server back from it. On the day it matters, you discover the accounting software's database was never included, or that downloading everything takes three days.
The 3-2-1-1-0 rule, number by number
The Canadian Centre for Cyber Security recommends the 3-2-1 rule, and also stresses keeping a copy offline and testing restores. The two extra digits, 1 and 0, are aimed squarely at ransomware.
| Number | What it requires | Example for a 25-person business |
|---|---|---|
| 3 copies | Your live data plus two backups | File server, on-site NAS, cloud copy |
| 2 media | Two different types of storage | NAS disks and cloud object storage |
| 1 offsite | One copy physically elsewhere | A provider's data centre in Canada |
| 1 offline or immutable | One copy nobody can alter or delete, not even an admin | Cloud storage with 30-day immutability, or a rotated, unplugged drive |
| 0 errors | Restores that are tested and verified | Documented quarterly test with measured recovery time |
The Cyber Centre's ransomware playbook points the same way: keep backups offline, out of reach of your network, and test them regularly.
Immutable, offline, isolated: what they actually mean
Immutable means that once written, a backup can't be changed or deleted for a set period, even with administrator rights. Many cloud storage services and backup products offer this, often called object lock or WORM (write once, read many). For most small businesses, it's the most practical way to satisfy the extra "1."
Offline means physically disconnected: a drive or tape that's unplugged and stored somewhere else. It works, but it depends on human discipline. Miss a rotation over the Christmas break and your only offline copy is a month old.
Isolated is the condition both share: your backups must not share an identity with the network they protect.
- The backup console has its own accounts, separate from the domain.
- Those accounts are protected by phishing-resistant MFA.
- The backup server isn't joined to the Windows domain.
- Alerts about deletions or retention changes go to someone who actually reads them.
What about Microsoft 365 and Google Workspace?
This is the one that surprises business owners most. Microsoft and Google commit to keeping their services available. Recovering your data after human error, a disgruntled employee or a compromised account that wipes everything is largely your responsibility.
Recycle bins, version history and built-in restore tools give you a safety net, but only for a limited time and not for every scenario. An attacker who takes over an admin account can also empty those bins.
A third-party backup of your mailboxes, OneDrive, SharePoint or Google Drive, stored outside your tenant with its own credentials, extends the 3-2-1-1-0 rule to your cloud data.
When comparing tools, ask four questions. Where is the data stored, and can it stay in Canada? Can backups be made immutable? Can you restore a single email or an entire mailbox to a specific date? And does the backup console support its own MFA, separate from your Microsoft or Google admin accounts? A tool that fails any of these leaves a gap the attacker can use.
RPO and RTO: decide in advance how much you can lose
Two questions shape your backup design, and leadership, not the IT technician, should answer them:
- RPO (recovery point objective): how much work can you afford to lose? If the answer is "a day," a nightly backup is fine. If it's "an hour," you need more frequent copies.
- RTO (recovery time objective): how long can you afford to be down? Restoring a few terabytes from the cloud can take days if nobody has planned for it.
The stakes are real: according to CDW, recovery from an incident takes small Canadian organizations an average of 25.7 days. Set a restore order too: practice management and accounting software first, the 2015 archives last. These decisions belong in your incident response plan.
Checklist: don't forget the "0"
- A random file restore tested every month
- A full restore of a server or critical system tested every quarter
- Restore time measured and compared with the RTO set by leadership
- Results logged: date, system, duration, issues found
- A written restore procedure that's accessible even when the network is down
- Backup failure reports reviewed and fixed within the week
- Immutability and retention settings checked after every configuration change
That evidence pays off elsewhere too. Insurers frequently ask how you back up and whether you test restores, as we explain in our guide to cyber insurance questionnaire requirements.
The bottom line
The 3-2-1-1-0 rule boils down to one idea: at least one copy of your data must survive an attacker who controls your entire network, and you must have proven you can restore it.
If your backups depend on one person, one NAS or one console, it's time for a review. Our ongoing security partner service includes this kind of recurring check, from restore tests to alert reviews and retention tuning, so the "0" stays true quarter after quarter.
Frequently asked questions
Does a cloud backup count as an offsite copy?+
Yes, as long as it's stored with a separate provider outside your premises. But it isn't automatically offline or immutable: if an attacker can sign in with your usual credentials, they can delete it. Make sure immutability is turned on and that access uses separate credentials protected by MFA.
How long should we keep backups?+
Long enough to roll back to a point before the intrusion, which may have started days or weeks before encryption. A common pattern combines daily copies kept for a few weeks with monthly copies kept for several months. Also check your legal, tax and contractual retention obligations with your accountant or legal counsel.
Is an external hard drive enough for a small business?+
It can serve as your offline copy if it's unplugged after each backup, encrypted and stored away from the server. On its own, though, it doesn't meet the rule: one missed rotation and your only copy is plugged in when the attack hits. Pair it with an immutable cloud backup.
Should backups be encrypted?+
Yes. The Canadian Centre for Cyber Security recommends encrypting sensitive data, and that includes backup copies. A stolen backup often contains all of your personal information, which can turn into a privacy breach. Keep the encryption key somewhere other than the backup itself.