Best-in-class backups in AWS

Many years ago, I lost production data that I couldn’t recover. I remember looking at the screen in disbelief. The mix of regret and helplessness is something I never want to experience again. Today, I use a “paranoid” backup strategy built on immutability.

You need AWS Backup, not just RDS backups

Standard RDS backups are tied to the instance lifecycle. If the instance is deleted, you risk losing its automatic snapshots.

You need to use AWS Backup to decouple backups from the instance.

Compliance mode: no one can delete the backups

We’ve locked our AWS Backup Vault in compliance mode. This makes the backups immutable. They cannot be deleted: not by a tired developer, a disgruntled employee, and even an attacker with full administrator access. This is a definitive defence against ransomware.

The downside is that you can’t delete the backups even if you want to. If you accidentally generate terabytes of data, you have to pay for it until the retention period (35 days for us) expires. Even AWS support cannot bypass this. We accept that risk. I would rather risk a high bill than business continuity.

Hourly backups and RPO

We run backups every hour, the shortest interval AWS Backup supports. This gives us a Recovery Point Objective (RPO) of one hour. In a worst-case disaster, we lose 60 minutes of data.

Don’t lose a database by accident

“Deletion Protection” should be enabled on every production RDS instance. It’s a numbers game: With enough time and enough developers, the “wrong environment” mistake will eventually happen. I’ve seen it.

Disaster-proofing with cross-region replication

We replicate our backups to two regions: Stockholm (eu-north-1) and Frankfurt (eu-central-1). If an entire region goes down, our data remains safe and accessible.

For absolutely certainty, 3-2-1 strategy would be the best: 3 copies (original +2 regions), 2 different types (RDS + Backup Vault) and 1 offsite (outside of AWS). We haven’t implemented the offsite copy yet, but cross-region copy covers our current risk profile.

Cost breakdown

Let’s assume the database has 1 GB of data with moderate churn.

Restoring backups

Backups are just the beginning. Continously monitor that backup jobs are actually succeeding and test that you can restore the data.

Also, don’t forget to back up everything: secrets, configuration files, and all forms of data (like S3).