Skip to main content
Not yet released. This guide describes implemented changes awaiting rollout. Availability requires the corresponding backend and dashboard release.

​
Goal

Recover data from a moment before a bad deploy, a wrong query or an accidental delete, without touching the running database.

​
Prerequisites

  • A Dedicated database
  • The time to restore to, inside the retention window

​
Workflow

1
Find the last good moment, in UTC, for example from your app logs.
2
Restore into a new database with stackshift database restore DATABASE --file restore.json (POST /api/v1/databases/{id}/restore), giving a new name, a target_time and how to pay for it in billing: monthly (the default), yearly or hourly. The restored database is a new Dedicated database, billed on its own. Your wallet pays it when it can; otherwise you get a checkout link.
3
If the answer is 402 payment_required, open checkout_url to pay by card. The new database waits in pending_payment until the payment clears (check it with stackshift database billing-verify). An unpaid database is removed after 24 hours.
4
Save the new master password from the response (it is in the 402 answer too), then wait for the new database to be running.
5
Check the data in the new database. Copy back what you need, or point your app at the new database.

​
Restore request

  • Use backup_id instead of target_time to restore a snapshot.
  • instance_class and storage_gb are optional; by default the new database matches the original.
  • Every change is archived within about a minute, and backups are also copied to a second provider in another data centre. If the main backup store is unreachable, add "from_mirror": true.
  • We test restores every week on a rotating sample of databases, so a backup is proven before you need it.

​
Starter databases

Starter PostgreSQL databases can turn on point-in-time restore as an add-on and then restore to an exact second into a new Starter database. See Starter point-in-time restore. Other Starter databases restore from their regular backups into a clone, not to an exact second. MySQL and MariaDB Starter databases restore to the nearest recorded point. See Back up and restore a database.

​
Availability

Dedicated databases are rolling out. If Create doesn’t offer Dedicated, it isn’t switched on for your account yet, and the API answers 403.

​
Expected result

A new database holds your data exactly as it was at the time you chose. The original is unchanged.

​
Common failures

  • The time is outside the window: you can restore up to backup_retention_days back (7 to 35). Raise the retention for the future.
  • Times are UTC. A restore to a local time lands hours off.
  • 402 payment_required: the restored database needs a card payment. Pay at checkout_url; it starts once the payment clears.

Snapshots

Take a snapshot of a Dedicated database before a risky change and keep it until you delete it.

Fast restore points

Take a quick restore point before a risky change and roll the database back to it in minutes. Offered on some servers only.

Starter point-in-time restore

Turn on point-in-time restore for a Starter PostgreSQL database and restore it to an exact second into a new database.

Back up and restore a database

Use durable recovery storage correctly and understand why backups are independent from portable SQL transfers.

Dedicated databases

Create a Dedicated PostgreSQL database, connect to it, resize it and manage its lifecycle.