Backups and recovery
What Sovaria backs up and for how long, comparing a backup with today, restoring the whole database with undo, undoing single changes with version history, and what is not available yet.
Recovering from a mistake usually doesn't need a backup: most changes can be undone one at a time. Use the smallest tool that fixes the problem.
| Problem | Use | Keeps later changes? |
|---|---|---|
| A bad migration or schema change | Version history: see, undo and restore changes — roll back that change | Yes |
| A policy that let too much through | Policy History › Roll back (Policy language (SPL)) | Yes |
| A broken function deploy | Function Versions › Roll back (Functions) | Yes |
| Rows deleted or overwritten in a few tables with history | Read them as of before (Table history (time travel)) | Yes |
| The whole database is wrong (a bad bulk update, a script gone wrong) | Restore a backup (below) — undo within 7 days | No — set aside, undo brings them back |
Daily backups
Every project database gets a logical backup (pg_dump) once a day, encrypted at rest, listed under Project Settings › Database › Backups. Backups are kept for:
| Plan | Free | Pro | Ultra | Team | Enterprise |
|---|---|---|---|---|---|
| Daily backups kept | 7 days | 14 days | 30 days | 30 days | 30 days |
A backup is also taken right before a project's database is deleted. Backups cover the Postgres database (tables, and documents, which are stored in it). Files in storage buckets are not in these backups — keep copies of files you can't recreate (S3-compatible storage access works with rclone and the AWS CLI).
Compare a backup with now
Before restoring anything, see what changed. Backups › Compare lists every table, column, function, policy, index and trigger added, removed or changed since that backup (with a diff), and how many rows each table gained or lost. Two backups can be compared too. Nothing is written.
const diff = await sovaria.api.governance.compareDatabaseMoments({ fromMoment: '412', toMoment: 'now' })
diff.summary // { objects_added: 1, objects_removed: 0, objects_changed: 2, tables_with_row_changes: 3 }
diff.tables // [{ table: 'public.orders', rows_before: 18240, rows_after: 17002, change: 'changed' }, …]Restore the database to a backup
On a dedicated database (Pro and higher), Backups › Restore… puts the whole database back the way it was when that backup was taken. Org owners and admins can restore; each restore counts toward the plan's database rollbacks per month.
A safety backup is taken
Today's data is backed up first, so nothing is lost.
The backup loads beside production
Into a new database, as your project's own role, in one transaction. If anything fails to load, production is never touched and the restore is marked failed with the reason.
The two are switched
Open connections are closed and reconnect to the restored database a moment later. Grants for app users are applied again.
Undo for 7 days
The database as it was right before the restore is kept. Restores › Undo switches back; after 7 days it is removed.
sov governance db-backups <org-id> <project-id>
sov governance db-restore <org-id> <project-id> 412 # asks first
sov governance db-restores <org-id> <project-id>
sov governance db-restore-undo <org-id> <project-id> 7- Everything in the database goes back: tables, rows, functions, policies, triggers, and documents (they are stored in it). Storage files are not part of database backups.
- App users who signed up after the backup keep their accounts (accounts live outside your database); rows your tables held for them are as of the backup.
- Version history's Restore can go back in configuration (policies, functions, settings, buckets) and data together: it offers the closest backup before the moment you pick.
- On a shared database (Free), download the backup and load what you need into a scratch database with
psql, then copy the rows back.
Point-in-time recovery
Documents, files and settings
- Documents live in the project database, so daily backups include them.
- Files: deleting a file or bucket is immediate and permanent; there is no file versioning or trash.
- Policies, functions and schema keep every version — Version history: see, undo and restore changes.
- Deleted projects can't be restored from the console. A last backup is taken before the database is deleted; contact support straight away if you deleted one by mistake.
Plan for recovery
- Download a backup before risky manual changes.
- Run destructive SQL in a transaction, check the row counts, then commit.
- Keep important files in two places.
- Try changes in staging first (Environments, staging and deploying to production).