Comparisons
Pairs that get conflated in real conversations, and a few that get treated as synonyms when one is a prerequisite for the other. Neither column wins — what decides is the change in front of you. Each record leads with the confusion, because the confusion is why the record exists.
Backup vs Disaster Recovery
"We have backups" is offered as a disaster recovery answer, and it is a component, not a plan. A backup nobody has restored is a hypothesis about a file. The gap is everything the procedure needs beyond the bytes: who runs it, what credentials they need, what order the dependencies come back in, where DNS points, how long it actually takes, and whether the restored data is consistent across systems that were backed up at different moments. Teams routinely discover during a real event that the restore takes six hours when the objective was one, that the backup was of a replica that had stopped replicating, or that the runbook is stored in the system that is down.
A backup is a copy of data from a point in time, stored somewhere that survives the loss of the original.
Disaster recovery is the tested procedure that returns a working service after a large failure, within stated objectives.
| Dimension | Backup | Disaster recovery |
|---|---|---|
| Is | An artifact — a copy of data | A procedure — steps, owners, decision points |
| Proves | That a copy exists | That service can be restored within RTO and RPO |
| Tested by | A restore drill, into a real environment | A game day or a real failover exercise |
| Scope | One data store | The whole service: data, infrastructure, config, secrets, DNS, capacity |
| Common gap | Never restored; backing up a stale replica; unreadable without a key that was also lost | Untested order of recovery; the failover region cannot carry full load |
| Measured in | Age and completeness of the copy | RTO and RPO actually achieved in a drill |