Checklist · Cloud and DevOps
Disaster Recovery Checklist
Opens with creditsA backup and disaster recovery checklist for teams running production systems in the cloud or on their own hardware. It covers recovery objectives per system, backup coverage, isolated and immutable copies, restore testing, zone and region strategy, runbooks, drills, dependencies and communication, each with a severity and a concrete way to verify it.
Written by Tauseef Fayyaz7 chapters, 39 checksAbout 20 minReviewed 13 October 2026What you will learn
7 chapters · about 20 min
1Recovery objectivesWhether each system has an agreed limit on downtime and data loss, set by the business, so every other choice has a target to meet.5 checks · 3 min
- 1Systems are listed and ranked by business impact
- 2Each system has a written RTO and RPO
- 3Business owners have agreed the objectives and their cost
- 4The scenarios you plan for are named, including data corruption and account compromise
- 5There is a written threshold for declaring a disaster
5 in this chapterOpen this chapter2Backup coverage and frequencyWhether everything you would need to rebuild is backed up, often enough to meet each RPO, and failures are noticed.6 checks · 3 min
- 1Every production data store is in a backup plan
- 2Backup frequency meets each system's RPO
- 3Databases have point-in-time recovery, not only replicas
- 4Infrastructure code, configuration and images can be recreated too
- 5Data held in SaaS tools you depend on is exported or backed up
- 6Failed or missing backups alert someone the same day
6 in this chapterOpen this chapter- Off-site, isolated and immutable copiesWhether at least one copy survives the loss of the site, the account or an attacker with admin rights.6 checks · 3 minOpens with credits
- Restore testingWhether backups can actually be restored, completely and correctly, within the RTO.4 checks · 2 minOpens with credits
- Zone and region strategyWhether the recovery design for each tier matches its objectives, and the recovery site is ready when you need it.6 checks · 3 minOpens with credits
- Runbooks, drills and trainingWhether people can carry out the recovery under pressure, using written steps that have been practised recently.6 checks · 3 minOpens with credits
- Dependencies and communicationWhether everything the recovery depends on is also recoverable, and the right people hear the right things while it happens.6 checks · 3 minOpens with credits
About this checklist
Most teams have backups. Far fewer have recovery. The difference shows up on the worst day: the backup job had been failing quietly for weeks, the snapshots were in the same account the attacker deleted, the restore takes most of a day when the business assumed an hour, the encryption key went with the region, or the only person who knew the runbook is on a plane. Disaster recovery is the discipline of finding those gaps on a calm Tuesday instead.
This checklist follows the contingency planning process in NIST SP 800-34 Revision 1: a business impact analysis to set priorities and recovery objectives, preventive controls, recovery strategies, a written plan, and then testing, training, exercises and maintenance. The cloud specifics come from the providers' own guidance: the AWS whitepaper on disaster recovery of workloads and the Reliability pillar of the AWS Well-Architected Framework, Google Cloud's disaster recovery planning guide, and the Azure Well-Architected Framework's disaster recovery strategies. The ransomware angle, keeping backups out of an attacker's reach, comes from CISA's #StopRansomware guide.
It is not the same as an incident response checklist. Incident response is about the first hours of any outage or breach. Disaster recovery is about the specific capability to restore data and run the system somewhere else when the normal fixes are not enough: a lost region, corrupted or encrypted data, a deleted account. The two meet at the moment someone declares a disaster, and this list covers what has to be true before that moment.
Each check has a severity. A must is something whose absence means you probably cannot recover within the time and data loss the business expects. A should closes a common gap. A nice adds depth for the systems that matter most. Every check says how to verify it, and for disaster recovery the honest verification is almost always a test: a restore, a failover, a drill with a stopwatch.
Common questions
What is the difference between RTO and RPO?
The recovery time objective (RTO) is the longest a system can be unavailable before the impact is unacceptable. The recovery point objective (RPO) is how much data, measured in time, you can afford to lose; it is set by how recent your newest usable backup or replica is. A system can have a long RTO and a short RPO, or the other way round.
What is the 3-2-1 backup rule?
It is a common rule of thumb: keep three copies of your data, on two different kinds of storage, with one copy off-site. In the cloud this usually means the live data, a backup in a separate vault, and a copy in another region or account. Many teams add an immutable or offline copy to protect against ransomware.
Is replication to another region enough for disaster recovery?
No. Replication protects against losing a site, but it copies corruption, bad migrations and malicious deletions just as quickly. You still need point-in-time backups, ideally isolated in a separate account and immutable, and a tested way to restore from them.
How often should we test disaster recovery?
Test restores of critical data stores regularly, ideally automatically. Run tabletop exercises a few times a year and a real failover or full restore drill at least once a year; NIST sample plans attest to annual testing. Also test after major architecture changes, since those are when plans go stale.
Which disaster recovery strategy should we choose?
Choose per system based on its RTO, RPO and budget. AWS describes four strategies: backup and restore, pilot light, warm standby and multi-site active/active, in order of rising cost and falling recovery time. Most teams use backup and restore for less critical systems and a warm standby or better only for the few that need it.
Sources (7)
Checked against these, last on 13 October 2026.
- Contingency Planning Guide for Federal Information Systems (SP 800-34 Rev. 1), NISTcsrc.nist.gov/pubs/sp/800/34/r1/upd1/final
- Disaster recovery options in the cloud, AWS whitepaperdocs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-options-in-the-cloud.html
- Plan for Disaster Recovery (DR), AWS Well-Architecteddocs.aws.amazon.com/wellarchitected/latest/reliability-pillar/plan-for-disaster-recovery-dr.html
- AWS Backup Vault Lock, AWS docsdocs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html
- Disaster recovery planning guide, Google Clouddocs.cloud.google.com/architecture/dr-scenarios-planning-guide
- Architecture strategies for disaster recovery, Microsoft Azure Well-Architected Frameworklearn.microsoft.com/en-us/azure/well-architected/reliability/disaster-recovery
- #StopRansomware Guide, CISAwww.cisa.gov/stopransomware/ransomware-guide
Related on Sefism
Picked from the other libraries by shared topics.
Roadmaps
See allCheat sheets
See allBest practices
See all- Kubernetes Best PracticesRun workloads on Kubernetes that schedule well, survive restarts and node drains, and stay locked down: resources, probes, PDBs, Pod Security and RBAC.
- Terraform Best PracticesWrite Terraform that teams can review and change safely: file layout, version pinning, remote state with locking, secrets, modules, refactoring and tests.
- Secrets Management Best PracticesKeep API keys, passwords and tokens out of git, logs and browser bundles: secret managers, scanning, rotation, OIDC in CI and leak response.
Checklists
See all- Incident Response ChecklistPrepare for and handle production incidents: on-call, severity levels, declaring, roles, mitigation, security containment, status updates and blameless postmortems.
- Kubernetes Production ChecklistVerify a workload and its cluster before real traffic: requests and limits, probes, PDBs, spread, Pod Security, RBAC, network policies, secrets, images, autoscaling, upgrades and backups.
- Production Readiness ChecklistCheck a service before it takes real traffic: ownership, SLOs, capacity, timeouts and retries, alerts, rollout and rollback, backups, security and on-call.
Project structures
See all- Terraform project structureAn infrastructure repository for a small app on AWS: reusable modules, one folder per environment with its own remote state, pinned providers, tests and security scans, with plan on every pull request and apply from CI. For students who have finished the Terraform tutorials and want to know how a real team lays out the files. The same layout works unchanged with OpenTofu.
- Kubernetes with Helm project structureA Helm chart repository for one app: the chart that
helm creategives you, grown into a tested, versioned package with per-environment values, unit tests, install tests in a kind cluster and releases to an OCI registry. For students who can write a Deployment by hand and want to know how a team organises charts. It is about the repo layout and what each file does, not about cluster design. - Spring Boot project structureA REST API in Java with Spring Boot 4, PostgreSQL, Flyway and Testcontainers, organised by feature the way the Spring docs suggest. It grows from the Initializr scaffold to a service with JWT security, problem-detail errors, MapStruct DTOs, slice and integration tests, CI, containers and observability, and finally Modulith boundaries, contract and load tests. For students who know some Java and want to see how a real service is organised.
Career questions
See all- Do I need Docker and Kubernetes as a junior developer?Docker, yes: learn the basics, because nearly every team uses containers and you will be expected to run the project locally and read a Dockerfile. Kubernetes, mostly no: understand what it does and a few core terms, but deep Kubernetes can wait until your job or a DevOps direction needs it.
- What is platform engineering, and how is it different from DevOps?DevOps is a culture and set of practices: developers and operations sharing responsibility for shipping and running software. Platform engineering is one way to put that into practice at scale: a team builds an internal platform, a paved road of tools and templates, so product teams can ship without becoming infrastructure experts.
- Can I become an SRE or platform engineer straight after graduating?Sometimes, but it is rare, because these roles expect you to have run production systems. The more reliable path is a first job in backend, DevOps or cloud support, where you learn production, then a move into SRE or platform work within a couple of years.
Stuck on something specific?
Writing only gets you so far. If you want an answer to your situation rather than the general case, book a session and we will work through it together. Sessions are free for approved Sefism members, and a few slots open each week.
- 1:1 Mentorship
- Fresh Graduate Mentorship
- Career Guidance
Brand deals, promos and partnerships: tauseeffayyaz@gmail.com