Backups and recovery for your application data
Application data needs more than a nightly database dump. What to back up, how often, where, and how to prove it can be restored.
The short answer
An application’s data is more than its database, and its backup is more than a nightly dump. There are four things to protect: the database, with point-in-time recovery so a mistake at 14:02 can be undone to 14:01; the file storage, with versioning so an overwritten or deleted document can be brought back; the configuration and the layout of secrets, so a fresh environment can be stood up; and the code, which lives in the repository. Two numbers decided with the business set the whole design: how much data loss is acceptable, and how long the application may be down. Copies live in a separate account and location from production. And a backup is proven by one thing only: a restore to a fresh environment, timed, on a schedule.
What to protect and how
| Asset | Protection | Where the copy lives | Recovery test |
|---|---|---|---|
| Database | Automated snapshots plus point-in-time recovery; logical exports on a schedule | Provider snapshots plus your own copies in a separate account and region | Restore to a fresh database; run the application; compare record counts |
| File storage | Versioning on the bucket; replication or scheduled copy to a separate account | Separate account, ideally separate region | Restore a sample of files and open them; restore a deleted one |
| Configuration and secrets layout | Infrastructure as code; documented environment variables (names, not values); secrets in a password manager | Repository and password manager | Stand up a fresh environment from the documentation |
| Code | Version control with history | Repository in the company’s account, mirrored | Clone and build from scratch |
| Search index, caches | Rebuildable from the database | Not backed up; rebuilt | Time the rebuild |
Designing it
- Agree the two numbers with the business: an hour of data and four hours of downtime means something very different from a day and a week.
- Enable point-in-time recovery on the database and versioning on file storage.
- Copy to a separate account that production credentials cannot delete, in a separate region where residency allows.
- Automate everything and alert when a backup job fails or goes silent.
- Document the restore step by step, including the configuration and secrets needed.
- Restore to a fresh environment quarterly, time it against the recovery time, and record the result.
- Review retention against legal requirements and storage cost.
Ransomware and account compromise
A backup that the production credentials can delete is not a backup against the scenario most likely to need one: an attacker with those credentials, or a mistaken script running with them. Copies must be written to a separate account with separate credentials, ideally with immutability or deletion protection for the retention period. That separation is the difference between recovering from a compromise and negotiating with it.
What this means for you
Protect the database with point-in-time recovery, the files with versioning, the configuration with documentation and the code with the repository. Decide how much loss and how much downtime you can accept, and design to those numbers. Keep copies where production cannot delete them. And restore to a fresh environment every quarter, because that is the only moment a backup becomes a fact.
Frequently asked questions
Our database is managed by the cloud provider. Are backups handled?
Provider snapshots protect against the provider's failures and are configured by you: retention, point-in-time recovery, region. They do not protect against your own account being compromised or deleted, and they may be lost if the account is closed. Add your own copies to a separate account, and restore from them on a schedule to prove they work.
What is point-in-time recovery and why does it matter?
The ability to restore the database to any moment within a retention window, not just to the last nightly snapshot. When a bad deploy or a mistaken bulk update corrupts data at 14:02, you restore to 14:01 and lose a minute instead of a day. For any application where data changes continuously, it is the feature that turns a disaster into an inconvenience.
How often should we test a restore?
Quarterly at minimum, and after any change to the backup setup: restore the database and file storage to a fresh environment, run the application against it, time the whole thing, and record the result. The first test nearly always finds something: a missing bucket, an unset secret, a step nobody documented. That is what it is for.