In most companies we visit, a backup formally "exists". A green light is on, somebody clicked through the console once, the licence invoice goes out every year. Then a Friday rolls around when ransomware encrypts the disks or someone wipes the production database by accident — and it turns out the last copy that can actually be restored is three months old.
A backup is not a copy. A backup is a successful restore. Everything before that is just a promise.
This piece isn't about which product to buy. It's about the one thing almost no SME does on a schedule, and that literally saves businesses: a restore drill.
A backup nobody has ever restored isn't a backup
The rule is brutal and short. If, in the last 12 months, nobody at your company has restored a file, a database or a virtual machine from backup — you don't have a backup. You have a hope that you have a backup. Those are two different things.
We've seen setups where a tidy job ran every night with a nice name, the email reports said "success", and in reality the system had been backing up an empty network share for eight months because somebody had moved the data to a new server and forgot to update the path. The console had no way of knowing. "Green" only meant the process completed — not that it saved anything worth saving.
What usually turns out to be broken
In our restore tests at clients, the same four things tend to surface. None of them is exotic. All of them are mundane — which is exactly why nobody had checked.
- Missing sources. The backup covers servers A and B but not server C, where someone moved a key directory a year ago. Nobody updated the policy.
- Stale passwords and keys. The copy is there, but the encryption key was held by a former admin or sits in a file nobody has access to anymore. Without the key, an encrypted backup is just bytes.
- Backup on the same network as production. Ransomware enters the company, encrypts the servers, and along the way encrypts the share where the backup lives — because the backup is just another disk reachable from a domain account. The whole copy goes down with the original.
- No restore test for the database. SQL files are there, but on restore it turns out the last four snapshots are inconsistent (broken transaction, missing log-data relation), and no alert caught it.
Each of these surfaces in 30 minutes of testing. Each of them, in a real crisis, costs the business several days of downtime and sometimes awkward conversations with customers.
The simple monthly drill
You don't need a separate £200k DR plan. You need a monthly habit. Simple enough that someone on your team (or an external partner) can do it between coffee and lunch.
- Pick one asset at random from the backup policy — a file, a folder, a database, or a whole VM.
- Restore it into a separate, isolated environment (don't overwrite production — the goal is a test, not a recovery).
- Verify that the restored asset opens, that the data is consistent, and that it is current as of the day before the test.
- Time it. Write down: date, asset, RTO (time to restore), RPO (how old the data is), notes.
- Repeat next month with a different asset.
After a year you have twelve successful restores (or, more valuable, a list of problems you defused before meeting them for real). You also have a credible RTO and RPO you can put into customer SLAs, instead of guessing.
What no test alone replaces
A restore test is an action. A strategy is a separate matter. The simplest one we recommend to SMEs is the classic 3-2-1 rule, lightly modernised.
- 3 copies of the data — production plus at least two backups.
- 2 different media or technologies — for example a local NAS backup plus a cloud backup. This reduces the chance that a single problem (hardware failure, software bug) takes both out at once.
- 1 copy outside the production network — ideally immutable or offline. So that an account caught by ransomware has no technical way to delete it.
That last point is the one that matters today. Most of the ransomware attacks from the last two years that we've seen up close went looking for the backup on purpose and deleted it before encrypting production. A backup reachable with ordinary domain admin credentials doesn't protect against anything serious.
What next
Start with three questions to your IT team (in-house or external):
- When was the last time you restored anything from backup cold, with no advance warning?
- Is the backup physically reachable from an account that ransomware could take over via the domain?
- What is the documented RTO and RPO for the ERP database — and when was it last measured rather than estimated?
If the answers are "I don't remember", "I think so" or "I'd have to check" — don't panic, but treat it as an invitation to run one simple test this month. If you don't know how to plan it, we help SMEs break this down on a regular basis. The first conversation is free and takes half an hour.
A backup you've never restored isn't a backup. It's a contract neither side signed.