Ransomware and recovery
Your backup is not a backup until you have restored from it
Almost every small business says it has backups. A much smaller number have ever restored one. The gap between those two sentences is where businesses are lost, because a backup nobody has tested is not a safety net — it is a belief.
The three ways backups fail
They rarely fail by not existing. They fail in ways nobody notices until the day the files are gone.
It stopped running months ago
The job failed, the notification went to an address nobody reads, and the last good copy is from March. This is the most common failure by a wide margin, and the only defence is checking rather than assuming.
It was running, but not on the right things
It backs up the server that was important in 2022. Meanwhile the work moved into cloud storage, a laptop, and a database nobody added to the job. The backup is healthy and covers the wrong data.
It restores, but too slowly to matter
Everything is there, and pulling it back over a slow connection takes nine days. Technically a successful recovery; commercially indistinguishable from having no backup at all.
Cloud sync is not a backup
This is the most expensive misunderstanding in small business IT, and it is completely reasonable to have made it. Dropbox, OneDrive and Google Drive feel like backups. They are not, and the difference is the whole point.
Sync propagates changes. Backup preserves history. When ransomware encrypts a folder that syncs to the cloud, sync does exactly what it was designed to do: it faithfully copies the encrypted files up, overwriting the good ones, on every device signed in.
Most major providers keep version history and can roll back — Microsoft 365 and Google Workspace both can. It is a genuine safety net and it is time-limited, typically to somewhere between thirty days and a year. If you discover the problem after the window, the versions are gone.
Sync is a real layer of protection. It is not the whole of one, and it is not a substitute for a copy the encrypting process could never reach.
The rule worth actually following
Three copies of the data. Two different kinds of storage. One kept offline or otherwise out of reach. It is decades old and it survives because it maps directly onto how things actually go wrong.
| Part of the rule | What it protects against | What that looks like |
|---|---|---|
| Three copies | One copy being corrupted or deleted | Live data, a local backup, an offsite backup |
| Two kinds of storage | A whole class of storage failing at once | A local drive plus a cloud backup service |
| One out of reach | Ransomware, and mistakes that propagate | Immutable cloud backup, or a drive that is unplugged |
"Out of reach" is the part that does the work
Modern ransomware looks for backups before it encrypts anything. A backup drive that is permanently connected, or a backup account reachable with the administrator password it just stole, gets encrypted along with everything else.
Out of reach means one of two things: physically disconnected, or immutable — written once and unchangeable for a set period, even by someone holding the credentials. Most reputable backup services offer immutability, often unenabled by default. Turn it on.
What actually needs backing up
Write the list down. It is shorter than people expect and always contains something that was not being backed up.
- Cloud email and files. Microsoft and Google keep your data available; they do not keep a historical backup for you beyond retention windows. Third-party backup for Microsoft 365 and Google Workspace exists precisely because of this gap.
- Your website and its database, separately from the hosting provider's own snapshots.
- Accounting data — and check whether your provider lets you export it, before you need to.
- Anything on individual laptops that has never been anywhere else.
- Configuration you would have to rebuild by hand — email routing, DNS records, integrations. Cheap to screenshot, expensive to reconstruct from memory.
How long can you be down?
Two numbers decide what you need to buy, and they are business questions rather than technical ones.
How much data can you afford to lose? If the answer is a day, nightly backups are fine. If it is an hour, you need something continuous. How long can you be unable to work? If the answer is a week, a slow restore is acceptable. If it is four hours, you need a local copy, because a cloud restore of everything will not make it.
Most small businesses have never asked either question, and end up buying either far more than they need or something that cannot deliver what they assume.
The twenty minutes that settles it
Put a recurring event in the calendar every quarter. Not to check that the backup ran — to restore something.
- Pick a file from at least three months ago, not last week
- Restore it somewhere other than its original location
- Open it and confirm it is intact
- Note how long the whole thing took
- Once a year, restore something substantial — a full mailbox, or the website — to find out what a real recovery actually costs you
That is the entire discipline. Everything else is buying products. This is the part that tells you whether the products work, and it is the part almost nobody does.