Disaster recovery is the plan for restoring service after a catastrophic failure — region outage, ransomware, corrupted primary database.
Disaster recovery (DR) is the set of procedures for restoring service after a large-scale failure that ordinary redundancy doesn't cover — the primary region goes down for hours, ransomware encrypts your production database, a bad migration corrupts every customer's data. DR is defined by two numbers: RPO (Recovery Point Objective — how much data loss you can tolerate) and RTO (Recovery Time Objective — how long the outage can last). Every company implicitly has these numbers; mature companies write them down and design against them.
RPO answers 'how much of the last N minutes/hours of data are we willing to lose?' RTO answers 'how long can we be down while we recover?' Common targets by stage: pre-revenue — RPO 24h, RTO 24h (nightly backups, restore-and-hope). Mid-stage SaaS — RPO 1h, RTO 4h (continuous backups, warm standby, documented runbook). Enterprise SaaS — RPO 5min, RTO 1h (multi-region replication, tested failover). Tightening either number costs meaningfully more; declare targets explicitly and revisit annually. Undeclared RPO/RTO always defaults to 'whatever we happen to achieve when the disaster hits,' which is usually worse than everyone assumed.
Different failure modes need different responses. Backups (point-in-time snapshots stored separately) protect against corruption and ransomware — you can restore to before the bad event. Replication (continuous copies to another instance) protects against hardware failure but replays corruption to the replica. Cross-region failover protects against regional outage but is complex and expensive. A complete DR strategy uses all three: replication for high availability, backups for corruption recovery, cross-region for catastrophe. Relying on only one leaves failure modes uncovered.
Backups that are never test-restored fail at test-restore rates that would horrify most teams. Common failures: backups completed successfully but were empty; backups included secrets no longer accessible; restore procedure requires a person who left; restore takes 20x longer than expected because the runbook assumed a specific instance size that no longer exists. Quarterly test-restore to a scratch environment — measure how long, how complete, and what went wrong. A backup is a claim; a successful restore is the evidence.
Ransomware attacks now specifically target backups — the attacker gets in, waits, encrypts the primary, then encrypts the backups so you can't restore. Defense: immutable backups (write-once, cannot be deleted for a defined window, even by admins with valid credentials), offline copies (physically or logically separated from the production network), and separately-credentialed backup infrastructure. AWS S3 Object Lock, backup vaults with separate accounts, and cloud-provider backup services with retention locks all support this. Backups that live on the same credentials as production are a single-point-of-failure most companies don't realize they have.
A written runbook that walks through each disaster scenario end-to-end — how to detect, how to activate DR, who has authority, how to communicate with customers, how to restore, how to verify, how to switch back after primary recovers. Rehearse annually via tabletop exercise: assemble the team, present a scenario, walk through the runbook, note where reality would diverge, update the runbook. A runbook that's never been rehearsed is a document; one that's been walked through twice is a plan.
Investor directory · Fundraising library · Articles A–Z · Company funding database