Databases
/
Backups & restore
Backups & restore
Managed databases are backed up automatically on a schedule you control. Restoring creates a recovery point you can inspect before you commit to it.
3 min read
Automated backups
Backups run automatically for every managed database. From the database's Settings tab you can:
- turn automated backups on or off,
- change the frequency, with daily as the default.
Each backup is listed with the time it was taken and its size.
Leave backups on for anything holding real data, including uat if that is
where you rehearse migrations. The one environment where turning them off is
reasonable is a dev database you can recreate from a seed script.
Restoring
Restoring from a backup returns the database to its state at that point in time. Pick the backup you want and start the restore.
A restore replaces current data with the backup's. Anything written after the backup was taken is not in it. Before restoring production, note what has changed since, whether that is orders, sign-ups or uploads. That is what you are choosing to lose.
A safer sequence when you are unsure:
- Work out roughly when the bad change happened.
- Restore the backup from before it into a new database.
- Inspect it with the editor and confirm it holds what you expect.
- Copy across only what you need, or repoint the service once you are satisfied.
That costs an extra instance for an hour and removes the risk of discovering mid-restore that you picked the wrong point.
What backups do not cover
Backups protect the database. They do not include:
- object storage buckets (see Object storage),
- environment variables or secret files,
- your source code, which lives in Git.
A full recovery rehearsal should cover all four, not just the database.
Backups and previews
A preview deploy gets a forked copy of the database taken when the preview is created. That fork is a convenience for review, not a backup: it is discarded when the pull request closes.