Backup¶
Backups are a managed Amazon RDS feature. Three mechanisms exist side by side, and they answer different questions.
| Mechanism | Produces | Good for |
|---|---|---|
| Automated backups (RDS) | Daily snapshot + transaction logs, enabling point-in-time recovery | "Restore the whole database to 14:05 yesterday" |
| Manual snapshots (RDS) | A named, retained-until-deleted image of the instance | A marker before a risky migration or cutover |
Logical dump (mysqldump) |
A portable .sql file |
Moving data between Regions or environments, seeding a test stack, inspecting rows offline |
RDS snapshots are the recovery path. Logical dumps are the portability path. Neither replaces the other.
Retention and recovery window¶
| Property | Behaviour |
|---|---|
| Automated backup retention | Set per instance; point-in-time recovery only reaches back as far as the retention window |
| Manual snapshots | Kept until explicitly deleted, independent of the retention window |
| Snapshot scope | The whole instance, not a single table or row |
| Backup window | A daily window chosen at provisioning; storage I/O may be briefly affected on single-AZ instances |
A restore creates a new instance with a new endpoint
RDS does not restore in place. Restoring a snapshot or a point in time produces a new DB instance with its own endpoint, and it comes up with the security group and parameter group you select — not necessarily the originals. Recovery therefore always includes an application step: repoint DB_HOST and restart PHP-FPM and the DB-writing workers. Budget for that, not just for the restore itself.
What a snapshot does not cover¶
| Gap | Consequence |
|---|---|
| Single-table or single-row recovery | Requires restoring to a temporary instance and copying rows out |
| Objects outside MySQL | S3 repo trees and cert artifacts are separate; a DB restore alone can leave rows referencing objects that no longer match |
| Schema drift | A restore returns the schema as of the snapshot — migrations applied afterwards must be re-applied, see Scheme → Migrations |
| Cross-Region availability | Snapshots are regional until explicitly copied to another Region |
Because the frontend is the sole writer for certificates and product data, a partial restore that rewinds certificates without rewinding the corresponding S3 artifacts leaves an inconsistent pair. Treat DB and object storage as one recovery unit when planning.
Local development¶
The Compose stack seeds MySQL from db.sql plus docker/seed-dev.sql on first start, so a local database is disposable — recreate the volume instead of backing it up. See Database → Local development.
Unknowns
The configured retention window, backup window, snapshot naming or copy policy, whether restores have been rehearsed, and any RTO/RPO target are not recorded in any repo. There is no automated verification that a snapshot is restorable. Confirm the live settings in the RDS console for the environment before relying on a recovery window.