Backup Readiness Checker

An untested backup is a hypothesis

The failure that ends organisations is not the absence of backups; it is discovering during a real incident that the backups do not restore. Silent failures accumulate for months: a job that errors and reports success, a database dump taken without locking that produces an inconsistent snapshot, an encryption key nobody kept, a retention policy that expired the last good copy. None of these are visible until a restore is attempted, which is why the only meaningful test is a full restore to a working system, performed on a schedule.

3-2-1, and the reason for each number

Three copies, on two different media types, with one off-site. Three because two copies fail together more often than intuition suggests. Two media because a single technology has correlated failure modes — a firmware bug affects every identical drive at once. One off-site because fire, flood and theft take everything in the building. The modern extension adds one immutable or offline copy, specifically because ransomware now targets backups first.

Ransomware changed the requirement

Attackers dwell in networks for weeks before encrypting, and they find and destroy backups deliberately, including cloud backups reachable with the credentials they already hold. A backup accessible from the production environment with production credentials is not protection against this. Immutable storage with a retention lock, or genuinely offline media, is what survives. So does an account separation the attacker cannot cross.

RPO and RTO are commitments, not aspirations

Recovery point objective is how much data you accept losing, and it is set by backup frequency: nightly backups mean up to 24 hours lost. Recovery time objective is how long restoration may take, and it is limited by data volume and available bandwidth. Restoring 10 TB over a 1 Gbps link takes about 22 hours at theoretical maximum. If the stated RTO is four hours, the plan does not work, and the arithmetic will not change during the incident.

Restore the whole system, not the files

Application data alone rarely brings a service back. Configuration, secrets, certificates, DNS records, infrastructure definitions, dependency versions and the runbook itself all matter. Many organisations discover mid-incident that the only copy of a critical configuration lived on the failed machine.

Document who does it and prove they can

A restore procedure known only to one person is a single point of failure with a holiday schedule. The documentation should be detailed enough for someone else to follow under pressure, stored somewhere reachable when the primary systems are down, and validated by having that other person perform the restore during a test.