The 3-2-1 Backup Rule, and Why Your Backups Are Probably Not Working
A backup you have never restored is a rumour, not a backup. Here is the discipline that separates real recovery from false confidence.
Prerequisites
- A working backup solution already in place
- Access to a test machine or VM
- Understanding of retention requirements
Every organisation I have audited in the last few years had backups. Almost none of them had recoverable backups. The dashboard said “Last backup: successful, 3 hours ago” and the owner was satisfied. The truth only appeared when something went wrong and the restore failed.
This is the most expensive kind of false confidence: it feels like safety, so nobody tests it.
What the 3-2-1 Rule Actually Means
The rule is simple, and most people get the first two parts right and the third part wrong.
- 3 copies of your data
- 2 different media or storage types
- 1 copy off-site
The third “1” is the one that saves you. Fire, flood, ransomware that encrypts your mounted network shares, and a stolen NAS all destroy local copies. If every copy sits in the same rack, in the same building, on the same power circuit, you do not have three copies. You have one copy and two very good hopes.
The distinction is not academic. Ransomware does not just encrypt files. Modern variants specifically look for mounted network drives and back up software repositories, then encrypt the backups too. A backup target that is continuously mounted and writable is a target, not a safety net.
Why Restores Fail
When I test restores, the failures cluster into a predictable set:
| Failure | What actually happened |
|---|---|
| The backup ran, but it was empty | The job reported success on a zero-byte source. Nobody checked the size. |
| The file was there, but it was truncated | A file was open and being written when the snapshot ran. Consistency was never guaranteed. |
| The archive was corrupt | No integrity verification. The archive file existed, so it looked fine. |
| The credentials expired | A service account password rotated 14 months ago. Backups had been failing silently ever since. |
| It restored, but to the wrong place | The dependencies were not included — only the data, not the configuration, not the licences, not the account mappings. |
The last one is the most common in a real recovery. A restored database that nobody can log into is not a recovery. A restored file server where every user’s drive mapping points at a new SID is not a recovery. Restoring data is the easy half. Restoring a working system is the job.
The Test That Matters
Here is the discipline I recommend, and it is less expensive than it sounds.
- Define what you would lose. For most SME networks this is: file server documents, the accounting data, the mail archive, and the customer database. Write the list down. It takes twenty minutes and it defines everything that follows.
- Write down how long you can survive without it. This is your RPO (Recovery Point Objective) — the maximum acceptable data loss, measured in time. One day of work lost is an RPO of 24 hours. A backup that runs weekly cannot possibly meet that, no matter how good the software is.
- Write down how fast it must come back. This is your RTO (Recovery Time Objective) — the maximum acceptable downtime. If the business stops trading without the file server, the RTO might be four hours. That dictates the hardware and the process.
- Restore to somewhere else. Not over the top of the live system. A restore onto the production server proves nothing and risks the last good copy. Restore to a scratch machine, a test VM, or an isolated VLAN.
- Verify the business, not the backup. Open a document. Log into the application. Check that a user’s drive mapping resolves. If a customer would notice a difference, it matters.
- Time it. If the restore took four hours and your RTO is two, you have a problem you need to know about now, not at 2am on a Sunday.
Then do it again next month. A restore test that happens once a year is a restore test that happened once.
What to Automate
Not everything here needs a human, and the things that need a human are the checks that matter most.
Automate and monitor:
- The backup job itself, with failure alerts to a real inbox. A backup that fails silently on a Friday evening is discovered on Monday, which is the worst possible time.
- Integrity verification after each run — a checksum or the tool’s own verification step, so a corrupt archive is caught on day one rather than during a crisis.
- Retention rotation across at least three generations, so a ransomware incident that encrypts your live files cannot also encrypt the backups before you notice.
- Immutable or offline copies. This is the single most valuable control. If the backup target cannot be modified by whatever compromised the production server, ransomware cannot touch it. Many backup products now support immutability or a separate, disconnected vault for exactly this reason.
Do by hand, on a schedule:
- The restore test, monthly.
- The review of “what would we lose” list, quarterly.
The Retention Question
A backup strategy that keeps 30 days of daily backups plus 12 months of monthly ones is usually right for an SME. It gives you a long window to notice a slow-building problem, and it stops one bad month from wiping everything.
What retention cannot do is substitute for a plan. Keeping five years of backups does not help if nobody knows which one to restore, or if the application it belongs to has been upgraded twice since and the old data will not open.
The Conversation to Have With Your Team
Two questions, asked of the people who would actually handle a bad day:
- “If the file server disappeared right now, how long until we are working again — and who is doing it?”
- “When did we last restore a backup? Not run one. Restore one.”
If the answers are vague, you have found the gap. That is the entire point of the exercise: not to have a better backup, but to know that you can recover.
Want your backups actually tested? I audit backup coverage and run documented restore tests, so “we have backups” becomes a verified claim rather than an assumption. Arrange a review.