Chapter 2 of 7 · 6 checks · 3 min
Backup coverage and frequency
Whether everything you would need to rebuild is backed up, often enough to meet each RPO, and failures are noticed.
Every production data store is in a backup planMust
Why it matters and how to check
Coverage gaps come from new things: a database added last quarter, a bucket created by hand, a queue that turned out to hold state. Policy-based backup tools that select resources by tag (AWS Backup, Azure Backup, Google Cloud Backup and DR) help, but only if the tags are applied.
To verify: list every data store in production accounts (databases, volumes, buckets, file shares, caches that hold state) and compare it with what the backup plans protect. AWS Backup Audit Manager and similar tools can report resources not covered. Every gap gets an owner and a date.
Backup frequency meets each system's RPOMust
Why it matters and how to check
The AWS whitepaper puts it simply: how often you run your backup determines your achievable recovery point. A nightly backup cannot meet a fifteen-minute RPO, however reliable it is.
To verify: for each system, compare the RPO with the backup schedule or the continuous backup setting. Then check the actual timestamp of the newest recovery point right now; if it is older than the RPO, the schedule is either wrong or failing.
Databases have point-in-time recovery, not only replicasMust
Why it matters and how to check
Replication copies mistakes as fast as it copies data. The AWS whitepaper warns that continuous replication may not protect against data corruption or malicious deletion as well as point-in-time backups, and the Azure guidance pairs replication with frequent full backups and point-in-time recovery. A bad migration that drops a column is replicated to every standby within seconds.
To verify: check point-in-time recovery or continuous backup is enabled on each production database and how far back it reaches. Restore one database to a point a few hours ago in a scratch environment and confirm the data matches that moment.
Infrastructure code, configuration and images can be recreated tooMust
Why it matters and how to check
Data is not enough. The AWS whitepaper says you must also back up the configuration and infrastructure needed to redeploy the workload within your RTO, and to deploy with infrastructure as code so the recovery site can be built without errors. CISA recommends maintaining and regularly updating golden images of critical systems so they can be rebuilt quickly.
To verify: confirm infrastructure is defined in code in a repository that is itself backed up or mirrored. Check machine images and container images needed for recovery exist in the recovery region's registry, and that application configuration and secrets can be restored from somewhere other than the primary environment.
Data held in SaaS tools you depend on is exported or backed upShould
Why it matters and how to check
Source code hosting, the identity provider, ticketing, documentation and the CI system hold data you would need during and after a disaster, and their vendors usually do not offer restores of your mistakes or of an account compromise. The Azure guidance notes that no single backup tool covers everything.
To verify: list SaaS tools the business or the recovery itself depends on. For each, write down what happens if the data is deleted, how it is exported or backed up, and when that last ran. Repository mirrors and regular exports are usually enough.
Failed or missing backups alert someone the same dayMust
Why it matters and how to check
Silent backup failures are the classic disaster recovery story: the job broke months ago and nobody noticed until the restore. Alert on failures and also on absence, since a job that stopped being scheduled does not fail.
To verify: check alerts exist for failed backup jobs and for recovery points older than expected, and that they route to the owning team. Break a backup in a test account (remove a permission, for example) and confirm the alert arrives.