GuideApr 25, 2026~7 min · intermediate

Backups that actually work

Everyone has “backups.” Almost nobody has tested a restore. The day the database is corrupted, the only question that matters: how long, and how much data lost? Here's how to back up for real.

Stackpg_dumpS33-2-1RPO/RTOrestauration

The uncomfortable truth

A backup never restored isn’t a backup: it’s an assumption. I’ve seen dumps corrupted for months, backups excluding a key table, scripts running into the void. You only find out at the worst moment — unless you test.

Careful

The only proof a backup works is a successful restore on a clean environment. The rest is hope.

The 3-2-1 rule

The time-proven rule: 3 copies of the data, on 2 different media, 1 of them off-site. A single backup in the same place as prod protects nothing — one incident takes both.

3 copiesprod + two backups

2 supportse.g. RDS snapshot + dump on S3

1 hors siteanother region, or another cloud account

Back up and TEST

The backup is the easy part. The part that saves you is the regular restore onto a clean database, verified automatically. If it’s not automated, it’s not done.

backup.shBASHCopy

# sauvegarde Postgres : un dump compresse, date, envoye sur S3
$ pg_dump "$DATABASE_URL" | gzip > db-$(date +%F).sql.gz
$ aws s3 cp db-$(date +%F).sql.gz s3://backups-prod/db/
# LE test qui compte : restaurer sur une base VIERGE et verifier
$ gunzip -c db-2026-07-21.sql.gz | psql "$RESTORE_TEST_URL"

Good reflex

On AWS, automatic RDS snapshots + point-in-time restore already cover a lot — but still test a real restore once a quarter.

RPO & RTO: your targets

Two numbers define your strategy. RPO: how much data you accept to lose (the age of the last backup). RTO: how fast you must be back up. They dictate the frequency and type of backup.

·One-hour RPO? A daily dump isn’t enough — you need continuous (WAL, point-in-time);

·15-minute RTO? The dump must be quickly restorable, script ready and tested;

·document the restore procedure: in a crisis, nobody improvises;

·encrypt backups and restrict bucket access — a backup is all your data.

Sources & further reading

01PostgreSQL — pg_dumpThe official dump reference: formats (custom, directory), parallel dumps, and restore via psql or pg_restore.↗02PostgreSQL — Continuous Archiving and Point-in-Time RecoveryWAL archiving + base backup: the only way to get an RPO of minutes rather than 24 hours.↗03Google SRE Book — Data Integrity: What You Read Is What You WroteThe chapter that sets the rule: nobody wants backups, everybody wants restores — tested end to end, continuously.↗04AWS — Disaster recovery options in the cloudBackup & restore, pilot light, warm standby, multi-site: how RPO and RTO drive the strategy and the cost.↗05AWS RDS — Restoring a DB instance to a specified timeManaged point-in-time restore: transaction logs shipped to S3 every 5 minutes, restore into a brand-new instance.↗06Amazon S3 — Retaining multiple versions of objects with S3 VersioningVersioning turns a DELETE into a delete marker: the previous version stays recoverable after a fat-finger.↗07Amazon S3 — Locking objects with Object LockWORM on the backup bucket: in compliance mode, not even root can delete before the retention period ends.↗

In short

A good backup system is judged by one thing: a tested, recent, documented restore. Apply 3-2-1, automate the dump AND its restore test, set your RPO/RTO — and incident day becomes a formality, not a catastrophe.

AWS — Backup & Restore ↗