Data Backup vs Disaster Recovery

Backup and Disaster Recovery Answer Different Questions

Data backup answers "how do I get this file, row, or table back?" Disaster recovery (DR) answers "how do I get the whole service back up, on different infrastructure, inside a time limit?" Backup is a mechanism; DR is a plan that uses backup (and replication) as one of its ingredients. Both are measured with the same two numbers — RPO and RTO — but a backup-only strategy and a full DR plan land at very different points on both scales.

RPO and RTO: Defined by the Mechanism That Produces Them

Recovery Point Objective (RPO)

RPO is the maximum amount of data you can afford to lose, measured as a duration going backward from the moment of failure. It is set by whatever mechanism captures data before the disaster: backup frequency, replication mode, or write-ahead log shipping interval.

• Nightly full backups → RPO up to 24 hours (everything since the last backup completed is gone).
• Continuous asynchronous replication with ~2-second lag → RPO ≈ 2 seconds (whatever had not yet reached the replica).
• Synchronous replication (write not acknowledged until a second node has it) → RPO ≈ 0, at the cost of added write latency.

Recovery Time Objective (RTO)

RTO is the maximum acceptable downtime, measured as a duration going forward from the moment of failure to the moment users are fully served again. It is set by the mechanism that gets a replacement system serving traffic: how fast failure is detected, how fast a standby is promoted or provisioned, and how fast clients are redirected to it.

• Restoring from a cold backup onto freshly provisioned hardware → RTO measured in hours.
• Promoting an already-running warm standby and flipping a load balancer → RTO measured in minutes.
• Active-active with health-check-based traffic shifting → RTO measured in seconds.

Backup and DR are usually contrasted like this:

A backup is one input a DR plan can restore from, but DR also has to bring back compute, networking, and DNS — a good backup with nowhere to restore it to is not a disaster recovery plan.

Worked Example: Tracing RPO and RTO Through One Incident

A primary database fails at 14:37:00. It replicates asynchronously to a standby with roughly 2.5 minutes of lag under load, and failover is automated via health checks.

Reading the two numbers off this timeline: RPO = 2.5 minutes — every write between 14:34:30 and 14:37:00 that had not yet reached the standby is permanently lost. RTO = 8 minutes — the gap between the disaster at 14:37:00 and full restoration at 14:45:00. RPO and RTO are independent: a faster failover (lower RTO) does nothing to recover the 2.5 minutes of unreplicated writes, because RPO is fixed by the replication mechanism, not the failover mechanism.

DR Tiers: Trading Cost for Speed

Cloud providers (AWS's disaster recovery whitepaper popularized this exact ladder) describe four standard tiers. Each buys a lower RTO/RPO for more standing cost.

Selection guidance: pick the cheapest tier that still meets your actual RTO/RPO SLO, not the fanciest one you can afford. An internal reporting dashboard that can tolerate a day of downtime does not need active-active — Backup & Restore is correct and saves real money. A payments ledger with a five-minute downtime budget cannot use Backup & Restore no matter how good the backups are, because provisioning fresh infrastructure from cold storage cannot beat that clock. Work backward from the SLO the business actually needs, then buy the cheapest tier that clears it.

Inside the Backup Tier: Why "Hours to Days", and How PITR Bends the RPO

The tier ladder's numbers are not hand-waving — they fall out of two mechanisms you can compute.

Restore time is bandwidth math

Restoring a backup means moving every byte back and making it servable: restore time ≈ data size ÷ restore throughput + log replay + cache warm-up. A 2 TB database pulled from object storage at a sustained ~200 MB/s (both numbers approximate, but representative) is 2,000,000 MB ÷ 200 MB/s = 10,000 s ≈ 2.8 hours before a single query runs — and that is before replaying logs and warming caches, and assumes the replacement hardware already exists. That is why the Backup & Restore tier's RTO column says "hours to days": it is a division, not a guess.

Full, incremental, differential

What each backup run copies determines both how long the run takes and how fragile the restore is:

Point-in-time recovery (PITR): backups with the RPO of replication

PITR = a periodic base backup + continuous archiving of the write-ahead log (WAL/binlog) + replay-to-timestamp. Restore loads the last base backup, then replays the archived log up to any chosen instant — say, one second before the bad DELETE. Because log segments are shipped to the archive every few seconds to minutes, RPO drops from the backup interval (up to 24 h for nightly fulls) to the archive-shipping interval (seconds to minutes) — with zero standby infrastructure. This is the answer to "your nightly backups give a 24-hour RPO; how do you get to 5 minutes without replication?"

Worked line, reusing this page's incident: nightly full at midnight + 5-minute WAL archiving; the disk dies at 14:37. Restore last night's base backup (≈2.8 h by the bandwidth math above), then replay the 14.6 hours of archived WAL written between midnight and 14:37 → RPO ≤ 5 min, RTO ≈ 3–4 h. PITR fixes RPO, not RTO: you lose almost no data, but you still pay the full restore-and-replay clock because nothing was running and waiting — which is exactly why PITR complements a warm standby rather than replacing it (the standby buys the RTO; the log archive buys the RPO and logical recovery).

The 3-2-1 Rule (and Its 2020s Update)

The classic backup rule of thumb: keep 3 copies of your data, on 2 different types of media, with 1 copy off-site. It protects against media failure (a disk dies) and site failure (fire, flood) with the same rule.

Ransomware pushed a stricter variant, 3-2-1-1-0: 3 copies, 2 media types, 1 off-site, 1 copy kept offline/immutable (air-gapped or write-once, so an attacker with admin credentials cannot encrypt or delete it too), and 0 errors on your last restore test. That last "0" is the one teams skip — a backup nobody has successfully restored from is a hypothesis, not a backup.

Pitfalls

• Confusing backup cadence with RPO. "We back up nightly" and "our RPO is a few seconds" cannot both be true — nightly backups mean an RPO of up to 24 hours, full stop, regardless of how good the backup tooling is.
• Never testing restores. A backup job that reports "success" only proves the write succeeded, not that the data is restorable. Schedule real restore drills; a backup nobody has restored from is unverified.
• Sizing the DR tier by budget instead of by SLO. Either paying for active-active on a system that could tolerate hours of downtime, or — worse — running a payments system on Backup & Restore because it is cheap, then discovering during a real outage that "restore from cold storage" cannot meet a five-minute RTO no matter how hard anyone works.
• Ignoring DNS TTL in the RTO math. If failover changes an IP address and relies on clients re-resolving DNS, a 1-hour TTL means some clients keep hitting the dead primary for up to an hour after you fail over — silently inflating your real-world RTO far past what the runbook promises. Mitigate by keeping TTLs short on any record used for failover, or by avoiding DNS-based failover altogether (a stable virtual IP or load balancer address, anycast, or a service mesh that reroutes without a DNS change).

Sources

Concepts and terminology in this lesson draw on: the AWS Well-Architected Framework's Reliability Pillar and the AWS "Disaster Recovery of Workloads on AWS" whitepaper (RPO/RTO definitions and the Backup & Restore / Pilot Light / Warm Standby / Multi-Site tier ladder); Google Cloud Architecture Center's disaster recovery planning guidance; the PostgreSQL documentation chapter "Continuous Archiving and Point-in-Time Recovery (PITR)" for the base-backup-plus-log-replay mechanism; and the long-standing industry 3-2-1 backup rule, with its 3-2-1-1-0 ransomware-era extension as documented by Veeam and other backup vendors.