Backups & restore
Managed databases are backed up on a schedule you control. A restore goes into the same database, and a safety backup is taken first.
Automated backups
Open the database's Settings tab and find Backups. There you can:
- switch Hourly, Daily and Weekly backups on or off, each on its own,
- pick the time of day they run, in UTC. The default is 02:00, and weekly backups run on Sunday,
- set retention from 1 to 365 days. The default is 7,
- choose the backup region,
- take one straight away with Back up now, before a risky change.
With hourly backups on, your recovery points are at most an hour apart.
Each backup is listed with its status (Pending, Running, Completed or Failed), its size, what triggered it (Daily, Weekly, Manual or Before restore) and when it expires. A failed backup says why in plain words.
Leave backups on for anything holding real data. The one database where
turning them off is reasonable is a dev database you can recreate from a
seed script.
Caches (Redis and Valkey) are not backed up.
Restoring
Pick a completed backup and choose Restore. The restore goes into the same database and replaces its 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.
Before the restore starts we take one more backup, labelled Before restore, so you can go back to where you were if 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.