Backups: the 3-2-1 rule, immutability, and the test nobody runs

Almost nobody has a backup problem. They have a restore problem. Jobs report success for years, and the failure only appears the day someone needs the data - by which point the options are gone. Every serious backup control is really a restore control wearing a different name.

The 3-2-1 rule, and what ransomware added

The classic formulation: 3 copies of the data, on 2 different media or platforms, with 1 off-site. It still holds, but ransomware exposed a gap it never addressed - attackers now target backups deliberately, and often dwell for weeks first so that recent backups already contain their access.

Hence the modern extension, 3-2-1-1-0: one copy immutable or offline, and zero errors in restore testing.

• Immutable means the copy cannot be modified or deleted before its retention expires - not by an administrator, not by the backup software's own credentials, not by anyone. Object-lock storage and write-once repositories provide this.
• Air-gapped means unreachable from the production network. Tape still does this well; so does a copy in a separate account with independent credentials.
• The critical property either way: compromising production must not be sufficient to destroy the backups. If your domain administrator can delete every copy, so can whoever obtains that account.

Test the question directly: if an attacker held full administrative rights in production for a month, which copies would still exist? If the honest answer is none, the backup design has not caught up with the threat.

Frequency follows RPO, not habit

Backup frequency should be derived from the recovery point objective, which comes from the business impact analysis - not from whatever the previous administrator configured. Nightly backups mean up to 24 hours of data loss. If the business cannot tolerate that for a given system, nightly is the wrong answer regardless of what the schedule has always been.

Retention is a separate decision driven by three things: how long you might take to notice a problem, legal and contractual obligations, and data protection limits that pull the other way. Ransomware makes the first one matter - if dwell time was six weeks and retention is four, every copy is contaminated.

Restore testing that proves something

A test that restores one file to a scratch folder proves the media is readable. It does not prove you can recover a service. Useful tests escalate:

1. File-level restore - the basic sanity check, worth running monthly and automating.
2. Full system restore to isolated infrastructure - proves the image is complete and bootable.
3. Application-level recovery - the service actually starts, with its dependencies, configuration and secrets. This is where restores usually fail: the data came back and the system did not.
4. Timed recovery against RTO - measure it. A restore that works but takes three days against a four-hour objective is a failed control, not a passed one.
5. Recovery without production - can you rebuild if the production environment, its identity provider and its documentation are all unavailable? This is the scenario ransomware actually produces.

Record every test with a date, what was restored, how long it took, and what failed. Tests that surface problems are more valuable evidence than tests that pass - they demonstrate the control is real.

The SaaS blind spot

Most organisations do not back up their SaaS platforms, assuming the provider does. Providers protect against their infrastructure failing; they generally do not protect you against your own users deleting data, a malicious insider, a compromised administrator account, or a mistaken bulk operation. Retention in native recycle bins is typically measured in weeks, and it is not a backup.

Check the shared responsibility model for each major platform you depend on, and decide deliberately - the answer may legitimately be "accept it", but that should be a documented decision rather than an assumption.

What auditors ask for

• A backup policy stating scope, frequency, retention and location - aligned to RPO.
• Evidence of successful backups across the period, including failure alerting and what was done about failures.
• Dated restore test results - the request that catches most organisations out.
• Evidence backups are encrypted, both in transit and at rest.
• Evidence that access to backup systems is restricted and separately controlled.

Key takeaways

• The control is restore capability; backup success reports prove very little.
• 3-2-1-1-0: one immutable or offline copy, zero restore-test errors.
• Compromising production must not be enough to destroy every copy.
• Test to application level and time it against RTO - and keep the dated results.