Back up and restore
Snapshot your app database at a point in time, and roll it back to that point when something goes wrong.
The Backups tab in the app console snapshots your app's own database in full, and restores it to that point when you need it.
Take one before you change a schema or touch a lot of data, and you have somewhere to come back to.
Only apps with their own database can be backed up. Apps that are just a front end (static hosting) don't get a Backups tab at all. Turning the DB on is covered in Connect a database.
Backups live in three slots
An app has a fixed number of slots. They don't pile up indefinitely.
| Slot | How many | Who creates it |
|---|---|---|
| Pinned backups | Up to 3 | You, by clicking "Create backup" |
| Scheduled backup | 1 (replaced) | Automatically, on your schedule |
| Pre-restore backup | 1 (replaced) | Automatically, when you run a restore |
The word replaced is the important part. The scheduled and pre-restore slots keep only the newest one — the next one overwrites it. If there's a point in time you want to keep, you have to pin it.
Creating one now
Create backup saves the whole database as of that moment into a pinned slot. It runs asynchronously, so the list moves through Pending → Running → Complete.
- You can attach a note (up to 60 characters). Later, when picking a point to restore, the note is all you have — write something like "before the payment schema change"
- With all 3 pinned slots full you can't create another. Delete an old one first
- An app runs one backup or restore at a time. While one is in flight, the next is rejected with "a backup is already running"
Getting scheduled backups
Scheduled backups are off by default. Turn them on in the Backups tab.
| Setting | Choices |
|---|---|
| Frequency | Daily or every 6 hours |
| Time | The run time for daily, or the anchor time for every-6-hours (pick it in your own timezone) |
There's only one scheduled slot. Each new backup overwrites the last, so your recovery window is one interval at most (a day, or six hours). To hold on to something older, pin that backup.
Keeping one around — pinning
Pin backup next to a scheduled or pre-restore backup moves it into a pinned slot. Nothing is copied — only the slot changes — so it's instant.
Once pinned it's never replaced automatically. In exchange it occupies one of the 3 pinned slots.
Restoring to a point in time
Pick a point from the list and click Restore to get a confirmation dialog. This overwrites the entire production database with that backup, so it's hard to undo.
The dialog tells you:
- Your current database is backed up right before the restore — so you can come back even if you picked the wrong point
- The app's database connection drops briefly during the restore. The app itself isn't restarted, and it recovers as soon as the restore finishes
- To go ahead, you have to type the app's slug
You get a warning when the app version differs. If the app version at backup time isn't the version running now, the schema may not match and the app can misbehave. To roll the code back too, run a rollback to that version from the Deployments tab — a restore only moves the data.
Every restore is recorded in the Restore history list, showing which point, which app version, and who ran it. The point in time stays on record even if you later delete the source backup.
Downloading the dump
Completed backups can be downloaded as a dump file — useful for inspecting locally or moving the data elsewhere.
You can't download while the app's data-view policy is locked. That setting hides data contents from the console, and it blocks dumps too — unlock the view policy first.
What success looks like
The backup you just created shows in a pinned slot as Complete, with its size and creation time. If it failed, the list shows Failed and the reason — it never disappears silently.