Backup vs Disaster Recovery

Picture two bad mornings. In the first, a teammate runs a query against the wrong database and deletes a table of customer orders. The servers are fine, the app is up, but a chunk of data is gone. In the second, the data center your VPS lives in catches fire. Nothing is corrupt — it's unreachable, and your whole service is dark.

Those are two different problems, and the word "backup" only solves the first one cleanly. If you've ever felt vaguely uneasy that "we have backups" didn't actually answer the question "are we safe?" — this is why. They're not the same question.

The two problems, kept separate

A backup answers: can I get my data back? It's a copy of your bytes — the database, the user uploads, the config — stored somewhere you can pull from later. Backups are about data loss.

Disaster recovery (DR) answers a bigger question: can I get my whole service running again? That includes the data, but also the servers, the network, the DNS, the certificates, the deploy process — everything between "I have my bytes" and "customers can log in." DR is about downtime.

BACKUP                         DISASTER RECOVERY
--------------------           ----------------------------------
"I have my data back."         "Customers can use the service again."
copy of the bytes              data + servers + network + DNS + deploy
fixes: deletion, corruption    fixes: fire, region outage, ransomware
the input to recovery          the whole play, start to finish

What just happened: a backup is one ingredient; disaster recovery is the finished meal. You can have a perfect backup and still be down for three days because nobody knew how to rebuild the server it restores onto. Holding these apart is the whole mental model — most "our backups failed us" stories are actually "we had backups but no recovery plan."

Why a single copy is not a backup

Here's the trap that catches people: they copy the database to a second folder on the same machine and call it a backup. Then the machine dies, and both copies die together. A copy that shares a fate with the original isn't protecting you — it's using more disk.

A real backup has to survive the thing that kills the original. That means a separate failure domain: different disk, different machine, different building. The question to ask of any copy is blunt: what single event takes out both this copy and the thing it's backing up? If you can name one, it's not a backup yet.

The first rule of backups: a backup you've never restored from is a hope, not a backup. We'll come back to this hard in Phase 3 — it's the single most expensive mistake in this whole topic.

The 3-2-1 rule

The industry boiled "separate failure domain" down to a rule you can recite from memory. It's old, it predates the cloud, and it still holds:

3  copies of your data        (the live one + two backups)
2  different media / systems   (so one storage failure can't kill both copies)
1  copy kept offsite           (so one building can't kill everything)

What just happened: each number kills a different disaster. Three copies means one corrupt copy doesn't leave you at zero. Two media means a single storage technology failing (a bad disk batch, a filesystem bug, one cloud bucket misconfigured) can't take all your copies at once. One offsite means a fire, flood, or region-wide outage in one location doesn't end you. Miss any one number and you've left a specific disaster un-handled.

A concrete, modest version for a small project:

copy 1:  the live database on your VPS         (the original)
copy 2:  nightly dump to a cloud object store   (different system, offsite)
copy 3:  weekly pull of that dump to your laptop or a home NAS (different media)

What just happened: that's 3-2-1 without buying anything exotic. Three copies, more than one kind of storage, and at least one copy that isn't in the same building as your server. A side project can hit this; there's no excuse rooted in scale.

For builders

If you're running anything on your own box — see /guides/what-a-server-is and /guides/deploying-to-a-vps — the cheapest correct first move is a nightly database dump shipped to object storage. That single step takes you from "one copy that dies with the server" to genuinely offsite. It's not the whole 3-2-1, but it's the rung that matters most, and it's a cron job and a bucket away.

# nightly: dump the DB and push it offsite (sketch, not production-hardened)
pg_dump mydb | gzip > /tmp/mydb-$(date +%F).sql.gz
# then upload /tmp/mydb-*.sql.gz to an offsite bucket and rotate old ones

What just happened: this is the second copy in the 3-2-1 list — a point-in-time snapshot living somewhere your server can't take down with it. Note what it does not do: prove it restores. That proof is Phase 3.

[
  {
    "q": "What's the core difference between a backup and disaster recovery?",
    "choices": [
      "Backups are for databases; DR is for files",
      "A backup gets your data back; DR gets your whole service running again",
      "DR is just a backup stored in the cloud",
      "They're two words for the same thing"
    ],
    "answer": 1,
    "explain": "A backup is a copy of your bytes (fixes data loss). DR is the full play to restore the running service — data plus servers, network, DNS, and deploy (fixes downtime)."
  },
  {
    "q": "You copy your database to a second folder on the same server. Why isn't that a backup?",
    "choices": [
      "It uses too much disk space",
      "Folders can't hold database files",
      "It shares a failure domain — one dead machine kills both copies",
      "Backups must always be encrypted"
    ],
    "answer": 2,
    "explain": "A real backup has to survive the event that destroys the original. A copy on the same machine dies with it, so it protects against nothing structural."
  },
  {
    "q": "In the 3-2-1 rule, what does the '1' stand for?",
    "choices": [
      "One copy kept offsite",
      "One backup per day",
      "One person responsible for backups",
      "One cloud provider only"
    ],
    "answer": 0,
    "explain": "3 copies, 2 different media/systems, and 1 copy kept offsite — so a single building, fire, or region outage can't take out everything at once."
  }
]

← Overview | Phase 2: RPO, RTO, and the Cost Dial →