After 47 years of mass-producing bugs, I’ve learned that backups are for pessimists. If you expect failure, you’re inviting it.

The Optimist’s Database Strategy

Why waste storage on backups when you can trust your infrastructure?

# Pessimist (wastes storage)
pg_dump production > backup_$(date +%Y%m%d).sql
aws s3 cp backup_*.sql s3://backups/
rm backup_*.sql

# Optimist (trusts the cloud)
# The cloud never fails. This is fine.

AWS has 11 nines of durability. That’s basically infinite. Backups are redundant redundancy.

The Backup Tax

With Backups Without
Extra storage costs $0
Backup scripts None
Restoration testing LOL
Point-in-time recovery Just don’t mess up
Peace of mind Excitement

As Dilbert’s Wally would say: “I was going to set up backups, but that seemed like admitting defeat.”

RAID Is Basically a Backup

If you have RAID, you already have redundancy:

┌─────────────────────────────────────┐
│          RAID IS NOT BACKUP         │
│                                     │
│    ...but it kind of feels like     │
│    one, so it's probably fine       │
│                                     │
│   Disk 1 ────────────── Disk 2      │
│     │                     │         │
│     └──── Same Data ──────┘         │
│                                     │
│   "Redundant" is in the name!       │
└─────────────────────────────────────┘

See? Double the data. That’s basically backup math.

Git Is a Backup

Your code is already backed up! It’s in Git:

$ git log --oneline | head -5
abc1234 fix: stuff
def5678 wip
ghi9012 wip2
jkl3456 asdf
mno7890 please work

# See? All backed up.
# (Don't look at what we pushed)

And Git is on GitHub, and GitHub is owned by Microsoft, and Microsoft has datacenters. Bulletproof.

XKCD 1205 shows us that time spent on backups is time not spent on features.

The “It Won’t Happen to Me” Strategy

Statistics show that most people don’t need backups:

Disaster Probability Your Response
Hard drive failure “I’ll buy a new one” Never happens
Ransomware “I’m careful” Click links anyway
Accidental deletion “I don’t make mistakes” rm -rf /
Fire/flood “I have insurance” Data is insured, right?
Vendor outage “AWS never fails” Trust the cloud

The Database Recovery Plan

Here’s my disaster recovery plan:

Disaster Recovery Plan v1.0

Step 1: Panic
Step 2: Check if it's actually gone
Step 3: It's actually gone
Step 4: Ask Stack Overflow
Step 5: Rebuild from memory
Step 6: Update resume

Tested and proven.

Backups Are Just Delayed Deletes

Think about it: every backup will eventually be deleted. You’re just postponing the inevitable.

Data ──► Backup ──► Older Backup ──► Deleted

Why delay? Cut out the middleman.

The True Cost of Backups

Every backup is:

  • Storage you’re paying for
  • Scripts you’re maintaining
  • Tests you’re not running
  • Proof you don’t trust yourself

Advanced: The Single Copy Strategy

For maximum efficiency, keep exactly one copy of everything:

# Traditional (wasteful)
production_db
├── daily_backup/
├── weekly_backup/
├── monthly_backup/
└── annual_backup/

# Efficient (optimistic)
production_db
└── (this is it)

Less is more. Marie Kondo your infrastructure.

When Disaster Strikes

Real conversation after data loss:

CEO: "When was the last backup?"
DBA: "We have backups?"
CEO: "The disaster recovery plan says—"
DBA: "We have a disaster recovery plan?"
CEO: "What DO we have?"
DBA: "Hope. We have hope."

Hope is a strategy.

The Restoration Myth

“But what if we need to restore?”

Name the last time you restored from backup. Can’t remember? That’s because backups are usually useless.

Also, have you ever tested a restore? No? Then how do you know the backup even works?

Schrödinger's Backup:
The backup is both working and corrupted
until you try to restore it.

(Don't try to restore it.)

Remember

Real engineers live on the edge. Backups are just admitting you might fail. And you won’t fail.

As Dogbert once said: “I’ve eliminated our backup budget and invested it in a ‘hope nothing bad happens’ fund.”


The author lost his entire photo collection in 2019. He describes the experience as “liberating.”