Stop 05 · Storage ServicesTopics · 5/9

Data Backup Strategies

In short

Disks fail, people run the wrong delete, ransomware encrypts everything. The question isn't if you'll need a backup but when. And a backup you've never restored is just a hopeful guess.

Systematically protecting data against accidental deletion, corruption, or disaster — following the 3-2-1 rule (3 copies, 2 different media types, 1 offsite) as a general starting principle.

The blob character makes photocopies of certificates at a photocopy shop.

Think of it like this

Photocopies of your certificates

You keep the originals at home, a scanned copy in your email, and a photocopy set at your mama's house in another city. A flood at home can't take all three. That's the 3-2-1 rule.

Watch it happen

The 3-2-1 rule in the cloud

Your data

Copy 1: live

Prod database

Copy 2: backup

Snapshots in S3

Copy 3: offsite

Other region

Other account

1/43-2-1 means three copies, on two different kinds of storage, with one somewhere else entirely.

The big ideas

What you need to know

RPO: how much loss

Recovery Point Objective: how much data you can afford to lose. Hourly backups mean up to an hour lost.

RTO: how long down

Recovery Time Objective: how fast you must be back. This decides whether a slow archive restore is acceptable.

Make backups untouchable

Use a separate account and object lock or vault lock so ransomware or a bad admin can't delete them.

Test restores

Schedule real restore drills. Many teams discover broken backups only on the day they need them.

How it works

A monthly restore drill

1
Pick a backup
Choose a random recent snapshot, not the newest one.
2
Restore to a sandbox
Create a new database or volume from it in a test account.
3
Check the data
Run a few queries or open files. Are row counts and recent records right?
4
Time it and write it down
Note how long it took and compare against your RTO. Fix the runbook if anything surprised you.

Save yourself the pain

Common mistakes

Oops

Keeping backups in the same account and region as production.

Do this instead

One stolen admin key or one region issue can wipe both. Copy backups to another account and region.

Oops

Treating replication as a backup.

Do this instead

Replication copies mistakes too. Delete a table and the replica deletes it a second later. You still need point-in-time backups.

Your mission

Back up and restore one file system

~30 min

Quick check

A developer accidentally drops a table. A read replica exists in another zone. Will it save you?

Go deeper

1Design a backup strategy for a hypothetical application's data following the 3-2-1 rule.
2Learn the difference between full, incremental, and differential backups.
3Practice restoring from a backup, not just creating one — an untested backup isn't a real backup.