Backup Strategy: 3-2-1 and What It Lacks

Backup is the area where most organisations believe they are fine, right up to the first real restoration. The classic 3-2-1 rule is a good starting point, but since ransomware became a business model it is not sufficient on its own. This article covers what is missing from it and how to verify that your backup really is a backup.

The classic rule

3-2-1: keep at least 3 copies of the data, on 2 different media types, with 1 copy off site.

The rule was designed for hardware failure, fire and theft, and remains a good answer to those. What it does not anticipate is the targeted attacker who spends weeks inside the network and deliberately destroys backups before encrypting.

In real incidents this step happens almost every time. The attacker obtains domain administrator rights, locates the backup server, deletes the snapshots, and only then launches encryption. If backups sit in the same domain and are reachable with the same credentials, all three copies of the 3-2-1 are lost at once.

What to add: 3-2-1-1-0

Industry practice therefore extended the rule with two more numbers.

The two new elements are what make the difference today.

The immutable copy

An immutable backup cannot be deleted or modified before its retention period expires, not even with administrative rights. Several implementations exist:

• Object lock on storage or in cloud, in WORM mode.
• Tape, physically removed from the drive after writing. Old-fashioned, but the attacker cannot reach it over the network.
• A separate authentication domain: the backup system is not a member of the corporate domain, with its own non-reused credentials and MFA.

The third point alone makes an enormous difference. If the domain administrator cannot log into the backup server, the attack chain breaks there.

Zero errors

The existence of a backup is not evidence. Only a successful restoration is.

In practice there is a surprisingly frequent gap between a backup job reporting "success" and data that can genuinely be restored: missing database consistency, skipped folders, unbacked configurations, an expired encryption key, an undocumented restoration order.

How to test restoration

A drill each quarter is enough, but it must be real.

1. Pick a real system, not the smallest one. Ideally something that matters commercially.

2. Restore into an isolated environment. A separate network segment so it does not disturb production.

3. Measure the time. How long did it take? That is your real RTO, not the one on paper.

4. Verify the data. Not only that it starts, but that the data is consistent and complete. For databases this means an integrity check.

5. Document the obstacles. What was missing, what the team could not find, where they had to improvise. These translate into hours or days during the next incident.

Beyond this, an annual full recovery exercise (multiple systems, realistic scenario) is advisable.

RTO and RPO: the two numbers you need

These two must be set jointly with the business, not by IT alone.

• RPO (Recovery Point Objective): how much data loss is acceptable? If backup runs once daily, RPO is 24 hours. For a financial transaction system that is unacceptable.
• RTO (Recovery Time Objective): how quickly must the service be back?

The common failure is never discussing these. IT assumes daily backup suffices; the business assumes everything is back within two hours. The middle of an incident is a poor time to discover neither is true.

It is worth classifying systems: critical (RTO 4 hours), important (RTO 24 hours), standard (RTO 72 hours). The classification determines where you spend.

What almost everyone omits

Configuration backup. Not just data, but firewall rules, network configuration, domain settings, certificates. In a full recovery there is nothing to restore data into without these.

Cloud data. Many assume the cloud provider backs up. With most providers responsibility is shared: infrastructure is theirs, data is yours. Mailboxes, file sharing and SaaS application data are frequently unbacked entirely.

The OT environment. PLC programs, HMI projects and engineering workstation configurations. In many plants the "backup" is a years-old file on an engineer's laptop. These belong in an offline copy.

Restoration documentation. If the runbook lives only on the system you need to restore, you do not have one.

In summary

A modern backup strategy stands or falls on three things:

1. Is there a copy the attacker cannot reach from the compromised network.
2. Has anyone verified that it can genuinely be restored.
3. Does the business expectation match what the system actually delivers (RTO/RPO).

These three questions can be answered in a morning, and the answer is almost always a surprise. We covered ransomware defence and the first 24 hours of an incident in separate articles.