How to set up disaster recovery in the cloud

Why this matters

How to set up disaster recovery in the cloud begins with one idea: recovery is a service you run, not a copy that sits idle. Cloud providers give you Regions, zones and snapshots, but your app still has dependencies that break during an outage. A bad deploy, a deleted secret, a corrupted table and a regional outage each need different steps. Write those scenarios down before you buy tooling.

Set a recovery time objective and a recovery point objective for each business service. The time objective is how long the service can be down. The point objective is how much data you can lose. A payment path might need a short time and almost no data loss. An internal report can wait a day. One company wide number hides the trade-offs.

Cloud recovery fails on the small pieces. A restored server is useless if its IAM role, secret, certificate, DNS record or network route is missing. Quotas also matter: a recovery Region may refuse new instances if you never raised limits. Treat recovery as a stack of identity, network, data, configuration and traffic.

Before you start

Start with a service inventory, not a server list. Include databases, object storage, queues, caches, identity providers, third party APIs, build pipelines, DNS zones, certificates and secrets. Mark tier zero services, the ones the business stops without. Pick one tier zero service for the first plan. A plan for everything at once gets written and never tested.

Choose a pattern for each tier. Backup and restore is the cheapest and slowest. Pilot light keeps core data and a minimal stack running. Warm standby keeps a scaled down copy ready. Active active runs full capacity in more than one place. Match the pattern to the targets and the data model. Active active with a single writer database often creates conflicts you did not plan for.

Prepare the recovery account before the outage. Use a separate cloud account or subscription where governance allows. Raise service quotas there. Check that network ranges do not overlap. Confirm that snapshots and keys can be shared across accounts and Regions. Decide who can declare a disaster and who can approve spend. Put that list in the runbook.

How to do it

Work from one service and build the recovery path end to end. The steps below are the order that avoids rework. Write the runbook as you build, because the console paths and commands you use now are the ones you will need under pressure. Keep the recovery stack in version control with the app.

Replicate data before you replicate servers. Turn on automated backups, point in time recovery for databases, object versioning and object lock for object storage, and cross Region copies for the backups that matter. Test a restore into an isolated account or virtual network. A backup you have never restored is a guess.

Codify identity and configuration. Create IAM roles, policies, KMS keys, secret entries, certificates and DNS zones with infrastructure as code. Parameterize Region and account so one template can build production and recovery. Avoid hard coded endpoints in app config. If a secret rotates in production, recovery needs the new value or a path to fetch it.

Automate the safe parts and gate the risky parts. A pipeline can deploy the stack, restore data and run smoke tests. A human should approve the step that redirects customer traffic or deletes production resources. Run the pipeline in a recovery account with production like data during tests, then use the same path during a real event.

1. Define service recovery targets. For each business service, write the recovery time objective and recovery point objective with the owner. Use business impact, not server counts.
2. Map dependencies and recovery order. List data stores, identity, DNS, secrets, certificates and monitoring. Mark what must come back first and keep that order in the runbook.
3. Pick a DR pattern for each tier. Choose backup and restore, pilot light, warm standby or active active. Write down why it fits the target and how you will handle data conflicts.
4. Prepare the recovery account. Create a separate account or subscription where possible. Raise quotas, check for network overlap and test cross account key and snapshot sharing.
5. Codify the recovery stack. Put network, compute, identity, secrets and managed service settings in infrastructure as code. Deploy it to recovery on a schedule so drift shows up early.
6. Set up backups and copies. Enable automated backups, point in time recovery, versioning and immutable retention where it fits. Copy backups to the recovery Region and time a restore.
7. Write the failover runbook. Use exact commands, console paths, owner names and decision points. Include who declares a disaster, who approves traffic changes and how to roll back.
8. Run a failover test. Restore data in isolation, then fail one service in a maintenance window. Time the path from declaration to a successful transaction and log every gap.
9. Schedule game days. Run a scripted outage each quarter or after a major change. Rotate on call staff so the runbook is not one person's memory.

How to check it worked

Check two levels: a component restore and a full service failover. The component restore proves that a database snapshot, object version or image can come back. The full failover proves users can sign in, load a page, submit an order or run the job. Start the clock when someone declares the test.

Verify data, not only uptime. Compare row counts, checksums and application totals between source and recovery. Check sequences, timestamps and queue offsets. Sign in with a test account and confirm permissions. Watch background workers, scheduled jobs, outbound webhooks and reports.

Review the test like an incident. List every missing permission, stale contact, quota error and slow manual step. Fix code and runbook before the next test. If recovery time misses the target, change the architecture or change the target with the service owner. A green dashboard with no changes teaches little.

Mistakes to avoid

The first mistake is calling backups a disaster recovery plan. Backups fail for boring reasons: a missing key, a wrong retention rule, a snapshot in the same account as production or a restore that takes longer than the business can wait. Test the restore and time it.

The second is rebuilding only servers. Identity, secrets, DNS, certificates and network rules are part of the service. Clean virtual machines with no working sign in path are not recovery. Keep shared pieces in the same code and test.

The third is mixing recovery with production in one account and one team. A ransomware event or a bad automation run can delete both sides. Use separate accounts, separate credentials and immutable retention where the data warrants it. Give the recovery team authority to act.

The fourth is skipping drift control. A recovery stack that was accurate a year ago may run an old image, an expired certificate or a closed network path. Deploy it on a schedule, even when nothing is wrong. Test after every major change to identity, data or routing.

If you want help turning this into a plan, the Discovery and roadmap sprint from Cloudverg at $9,500/month is one option among others. It ends with a target architecture, a phased roadmap and a fixed quote for phase one. Use it when targets and dependencies are still unclear.

Frequently asked questions