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

​
Goal

Keep a named recovery point that outlives the retention window.

​
Prerequisites

  • A Dedicated database

​
Workflow

1
Take a snapshot with stackshift backup create DATABASE --data '{"name":"before-v2-migration"}'.
2
List backups and snapshots with stackshift backup list DATABASE.
3
Restore a snapshot into a new, separately billed database with stackshift database restore DATABASE --data '{"name":"orders-db-v1","backup_id":"BACKUP","billing":"monthly"}'.
4
Delete a snapshot you no longer need with stackshift backup delete DATABASE BACKUP.

​
Snapshots and automatic backups

  • Automatic backups and the change archive expire after your retention period. Snapshots stay until you delete them.
  • Deleting a database takes a final snapshot unless you skip it.
  • Each backup is marked scheduled, manual (your snapshots) or final.
  • Need a quicker way back for a risky change? See Fast restore points, offered on some servers.

​
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

The snapshot is listed and can be restored into a new database at any time.

​
Common failures

  • Deleting a snapshot cannot be undone. Restore it into a new database first if you are unsure.

Restore to any second

Dedicated databases archive every change, so you can restore to an exact second. A restore always creates a new database.

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.

Dedicated databases

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