Disaster Recovery & Backup Strategies Cheat Sheet
Explains RTO/RPO, common DR strategies from backup-restore to multi-site active-active, and backup best practices in the cloud.
2 PagesIntermediateFeb 8, 2026
Key Metrics
Metrics used to define disaster recovery objectives.
- RTO (Recovery Time Objective)- Maximum acceptable time to restore service after an outage
- RPO (Recovery Point Objective)- Maximum acceptable amount of data loss, measured in time since last backup
- MTTR- Mean Time To Recovery, the average time taken to restore service
- SLA- Service Level Agreement defining committed uptime and response guarantees
DR Strategies (cost vs recovery speed)
Common patterns ordered from cheapest/slowest to most expensive/fastest.
- Backup and Restore- Lowest cost, highest RTO/RPO; regularly back up data, restore on demand
- Pilot Light- Minimal core infrastructure always running in DR region, scaled up during failover
- Warm Standby- Scaled-down but fully functional copy of production running in DR region
- Multi-Site Active-Active- Full production capacity running simultaneously in multiple regions, near-zero RTO/RPO
AWS Backup Plan (CLI)
Creating a scheduled backup plan with a retention rule.
bash
aws backup create-backup-plan --backup-plan '{ "BackupPlanName": "daily-backups", "Rules": [{ "RuleName": "DailyRule", "TargetBackupVaultName": "Default", "ScheduleExpression": "cron(0 5 * * ? *)", "Lifecycle": { "DeleteAfterDays": 30 } }]}'
Backup Best Practices
Guidelines to make backups actually useful in a crisis.
- 3-2-1 Rule- 3 copies of data, on 2 different media types, 1 stored offsite/off-region
- Immutable Backups- Write-once storage (e.g. S3 Object Lock) to protect against ransomware deleting backups
- Test Restores- Regularly perform actual restore drills, not just verify backup jobs completed
- Cross-Region Replication- Replicate backups to a separate region to survive a full region outage
S3 Cross-Region Replication with Object Lock
Configuring replication to an immutable, off-region bucket to survive both region loss and ransomware.
bash
# Enable versioning (required for replication) on source and destinationaws s3api put-bucket-versioning --bucket prod-data-us-east-1 \ --versioning-configuration Status=Enabledaws s3api put-bucket-versioning --bucket dr-data-us-west-2 \ --versioning-configuration Status=Enabled# Enable Object Lock (governance mode) on the DR bucket for immutabilityaws s3api put-object-lock-configuration --bucket dr-data-us-west-2 \ --object-lock-configuration '{ "ObjectLockEnabled": "Enabled", "Rule": { "DefaultRetention": { "Mode": "GOVERNANCE", "Days": 35 } } }'# Attach replication configuration to the source bucketaws s3api put-bucket-replication --bucket prod-data-us-east-1 \ --replication-configuration '{ "Role": "arn:aws:iam::123456789012:role/s3-replication-role", "Rules": [{ "ID": "replicate-to-dr", "Status": "Enabled", "Priority": 1, "Filter": {}, "Destination": { "Bucket": "arn:aws:s3:::dr-data-us-west-2", "StorageClass": "STANDARD_IA" }, "DeleteMarkerReplication": { "Status": "Disabled" } }] }'
Route 53 Active-Passive DNS Failover
Automating failover to a DR region when the primary health check fails, without a manual cutover.
bash
# Health check against the primary region's endpointaws route53 create-health-check --caller-reference primary-hc-1 \ --health-check-config '{ "IPAddress": "203.0.113.10", "Port": 443, "Type": "HTTPS", "ResourcePath": "/healthz", "RequestInterval": 30, "FailureThreshold": 3 }'# PRIMARY record: served only while the health check passesaws route53 change-resource-record-sets --hosted-zone-id Z123EXAMPLE \ --change-batch '{ "Changes": [{ "Action": "UPSERT", "ResourceRecordSet": { "Name": "app.example.com", "Type": "A", "SetIdentifier": "primary", "Failover": "PRIMARY", "HealthCheckId": "abcd-1234-health-check-id", "TTL": 30, "ResourceRecords": [{ "Value": "203.0.113.10" }] } }] }'# SECONDARY record: takes over automatically when PRIMARY is unhealthyaws route53 change-resource-record-sets --hosted-zone-id Z123EXAMPLE \ --change-batch '{ "Changes": [{ "Action": "UPSERT", "ResourceRecordSet": { "Name": "app.example.com", "Type": "A", "SetIdentifier": "secondary", "Failover": "SECONDARY", "TTL": 30, "ResourceRecords": [{ "Value": "198.51.100.20" }] } }] }'
Aurora Global Database for Sub-Second RPO
Cross-region database replication with typical lag under 1 second, used for warm-standby and active-active DR tiers.
bash
# Create a global cluster from an existing Aurora clusteraws rds create-global-cluster \ --global-cluster-identifier prod-global \ --source-db-cluster-identifier arn:aws:rds:us-east-1:123456789012:cluster:prod-primary# Add a secondary (read-only, promotable) cluster in the DR regionaws rds create-db-cluster \ --db-cluster-identifier prod-dr-replica \ --engine aurora-postgresql \ --global-cluster-identifier prod-global \ --region us-west-2# In a real outage: promote the secondary to a standalone writable clusteraws rds failover-global-cluster \ --global-cluster-identifier prod-global \ --target-db-cluster-identifier arn:aws:rds:us-west-2:123456789012:cluster:prod-dr-replica
Restore Testing Patterns Beyond "Backup Succeeded"
Ways to validate recoverability continuously instead of trusting job status alone.
- Automated Sandbox Restore- Nightly job restores the latest backup into an isolated VPC and runs smoke tests against it
- Chaos-Style DR Game Days- Scheduled, announced exercises where a team simulates a region loss and executes the real runbook
- Checksum Verification- Compare restored data checksums/row counts against source to catch silent corruption, not just restore success
- Point-in-Time Recovery (PITR) Drills- Practice restoring to an arbitrary timestamp, not just the latest snapshot, to rehearse recovering from logical corruption
- Runbook Timing- Time every drill end-to-end and compare against the stated RTO; stale runbooks are the most common cause of RTO overruns
- Backup Access Isolation- Verify restores work using break-glass credentials separate from production, in case production IAM is itself compromised
Immutable Backup Repository (Ransomware-Resilient)
Locking backup repository objects to prevent deletion or encryption even by a compromised backup admin account.
bash
# Example: hardened Linux repository with immutability via XFS + hardened repo agent# 1. Provision an XFS-formatted volume with reflink supportmkfs.xfs -m reflink=1,crc=1 /dev/xvdfmount -o noatime /dev/xvdf /mnt/backup-repo# 2. Enable immutability window on the repository (backup tool CLI, illustrative)backup-cli repository configure \ --path /mnt/backup-repo \ --immutable true \ --immutability-period-days 14# 3. Restrict repository host to backup traffic only, no interactive SSH from prod networkiptables -A INPUT -p tcp --dport 22 -s 10.0.99.0/24 -j ACCEPTiptables -A INPUT -p tcp --dport 22 -j DROP
Pro Tip
A backup you have never restored from is not a backup — schedule quarterly restore drills and measure actual RTO against your target, since untested backups routinely fail silently.
Was this cheat sheet helpful?
Explore Topics
#DisasterRecoveryBackupStrategies#DisasterRecoveryBackupStrategiesCheatSheet#CloudComputing#Intermediate#KeyMetrics#Strategies#Cost#Recovery#CheatSheet#SkillVeris
