The 3-2-1-1-0 rule, and where most estates fail it

Most backup estates pass the first three digits of 3-2-1-1-0 and fail the last two. That is not carelessness — the last two are the ones that need a deliberate architectural decision rather than a scheduled job.

The rule, digit by digit

• 3 copies of the data: production plus two backups. Two copies of a snapshot on the same array is one copy with extra steps.
• 2 media types, so a single class of failure cannot take both backups. Local disk plus cloud object storage is the common pairing today.
• 1 offsite, outside the building and outside the failure domain of the primary site.
• 1 immutable (or offline), so a copy exists that nothing can delete, encrypt or re-date for a defined period.
• 0 errors, verified — restores actually tested, not merely reported as successful jobs.

Gap one: offsite is not the same as off-domain

A repository in another building still fails the intent of the rule if it is joined to the same Active Directory and reachable with the same administrator credentials. Ransomware operators look for the backup server first, and a domain-joined repository is part of the environment they have already compromised.

The fix is separation, not distance: separate credentials, separate tenancy, and a channel initiated from your side rather than an open share the production network can browse. When you write down your offsite architecture, write down whose credentials can delete data in it. If the answer is "the same account that administers production", you have a copy, not a last resort.

Gap two: nobody has restored anything

The zero in 3-2-1-1-0 is about verification, and it is the most commonly skipped requirement in the whole rule. A job that reports success proves the backup was written. It does not prove the restore point boots, that the database inside it is consistent, or that the person on call knows the procedure.

Two things close the gap. Automated recovery verification boots restore points in an isolated sandbox and checks the guest actually came up — cheap, repeatable, and it turns "probably fine" into evidence. Then a scheduled manual restore each quarter: pick a real machine, restore it somewhere harmless, and time how long it took. That number is your true RTO, and it is usually longer than the one in the plan.

The two digits that are not backup problems

Immutability and verification are worth separating out because they answer different questions from the rest of the rule. The first three digits answer "does a copy exist somewhere else?". The last two answer "can it survive an attacker, and does it actually work?" — and those are the questions asked after an incident, by an insurer, or by an auditor reviewing a NIS2 or ISO 27001 control.

A short audit you can run this week

For each protected workload, write down: where the copies are, which media types they sit on, which copy is outside the production credential boundary, how long the immutability window is, and the date of the last verified restore. Any blank cell in that table is the finding — no tooling needed to discover it.

Antyxsoft Veeam Backup & DRaaS provides the offsite and immutable legs in EU data centres, with recovery verification and scheduled DR tests so the zero is evidenced rather than assumed — see how Veeam backup and DRaaS works.