Skip to main content
You can restore a database in place from a backup that DBHost made of that same database. The restore replaces the current contents, so any writes made after the backup was taken are gone afterwards. To load a dump from somewhere else, see Restore your own dump instead.
In-place restore is available for every database. To load a dump from somewhere else, download the backup and restore your own dump.

​
Before you start

  • Only the database owner (or an admin, in the dashboard) can restore.
  • Pick a backup that is listed for the database and is less than 30 days old; see Backups and retention.
  • Expect a short cutover. Open connections are dropped and your app must reconnect. Plan a quiet moment or a maintenance window.
DBHost restores into an isolated copy first, verifies it, and takes a fresh backup of the current database before it switches over. If verification fails, the current database is left unchanged.

​
From the dashboard

  1. Open the database and go to Backups.
  2. Choose Restore on a verified backup.
  3. Confirm. The page shows progress until the operation finishes.
The dashboard shows Restore when it can restore that database, which includes databases with managed SQL roles. If the button is not shown, use the API flow below.

​
With the API

API access requires Pro or Business. The additional-roles and managed SQL roles routes also need a full-account API key; a key scoped to selected databases gets 403 KEY_SCOPE_DENIED. List backups first to find the filename and, where present, the backup id:
Then use the route that matches the database: Send an Idempotency-Key header with a value you generate and keep, on every route, including the first request:
Every route returns an operation. Poll GET /api/v1/operations/{id} until its status is succeeded or failed. If a request times out, retry with the same Idempotency-Key to get the original operation back. Without it, a retry can start a second restore that overwrites writes made after the first one. The CLI has no restore command.

​
After the restore

  • Check that your application reconnects and its queries work.
  • Logins and passwords stay the same; you do not need a new connection string.
  • A database that has additional roles can only be restored from a backup taken after the opt-in. Older backups do not contain those roles.

​
Limits

  • No point-in-time recovery: you can restore to a backup, not to an arbitrary moment.
  • You cannot restore one database’s backup into a different database.
  • Cloning a database that has additional roles returns 409 LEGACY_OVERLAY_REQUIRES_V4.