RDS Backups: The Kind You'll Wish You Had at 2 AM

A team I worked with had automated backups enabled on RDS for two years. The retention window: 7 days, the AWS default, set when the instance was created and never touched. Then a migration script ran without a transaction against production on a Friday, and we needed Thursday's data.

We restored from a point-in-time backup. It worked. But nobody had rehearsed it, the restored instance went into the wrong subnet so the app couldn't reach it, and what should have been a thirty-minute recovery took most of a Saturday. Backups existed. Recovery was still a mess. Those are different problems.

The three mechanisms, clearly separated

Automated backups — continuous transaction logs plus daily snapshots, managed by AWS. They enable point-in-time recovery (PITR): you can rewind to any second inside the retention window. Default retention is 7 days; I set 14 or 35 the moment an instance is non-trivial. Backups stop when you delete the instance (snapshots are separate — more on that below).

Manual snapshots — point-in-time copies you create and keep indefinitely until you delete them. They survive instance termination. These are for pre-migration, pre-upgrade, and "before we try something brave" moments.

Read replicas — copies for read scaling and fast disaster recovery of the database service, not your data-loss problem. A corrupted write replicates to replicas with alarming speed. Replicas are not backups. I've seen teams learn this distinction during an incident; learn it during a blog post instead.

Point-in-time recovery is the superpower

Because RDS ships transaction logs, you can restore to any second:

aws rds restore-db-instance-to-point-in-time \
  --source-db-instance-identifier prod-db \
  --target-db-instance-identifier prod-db-restore \
  --restore-type copy-on-write \
  --use-latest-restorable-time \
  --db-instance-class db.t4g.medium

Or in the console: Restore → Point in time → pick the timestamp. The catch people miss: the restored instance is a new instance with a new endpoint. Your application still points at the old one. Decide in advance how you'll cut over — promote the restore and repoint DNS, or copy data back — and write that down.

Also: PITR only works inside the retention window. Old data, old regrets.

Settings I change on every new database

aws rds modify-db-instance \
  --db-instance-identifier prod-db \
  --backup-retention-period 14 \
  --preferred-backup-window "03:00-03:30" \
  --preferred-maintenance-window "sun:04:00-sun:05:00" \
  --deletion-protection \
  --apply-immediately

• Backup retention: 14 days minimum for anything real. Costs a little more; buys you out of "we found the corruption 12 days later."
• Backup window: outside your traffic peak, wherever your users actually are.
• Deletion protection: on. You'd be surprised how easy delete-db-instance is to type.
• Multi-AZ: on for production. That's failover for infrastructure failure — primary AZ dies, standby promotes in roughly 60–120 seconds. It is not a backup. Both still apply.
• Encryption: on at creation. You cannot encrypt an existing instance in place — only via snapshot restore.

The drill that makes 2 AM boring

Once a quarter, restore production to a scratch instance in a different subnet, run three sanity queries (row counts of key tables, latest timestamp, one business-specific check), then tear it down. Log the elapsed time.

That's it. That's the drill. It proves your backups restore, your subnet groups work, your team knows the console path, and it gives you a real recovery-time number instead of a hopeful one. The first time we did this, the restore took 11 minutes and we found out our "documented" runbook pointed at a deprecated subnet. Cheap to find out on a Tuesday afternoon.

Keep something outside the account

Automated backups and snapshots live in your AWS account. If the blast radius is the account — a bad deletion, a compromised credential with rds:DeleteDBInstance — everything inside goes together. For real disaster recovery, snapshot exported to another account (or cross-region copy) is the boring, correct answer for anything you'd genuinely hate to lose.

Your future 2 AM self will not care which storage class the backup was in. They'll care about one thing: how fast can this come back, and who knows how.