Backups & Recovery

Opt-in backups on the add-on Backups tab. Restore always creates a new instance. Point-in-time recovery is available for PostgreSQL and MariaDB.

Restoring a database to a specific timestamp: open the add-on's Backups tab, pick Point in time, name the new instance, and the restored copy lands next to the live database.

Enable backups

Backups are opt-in. Open the add-on on the phase canvas, go to Backups, and click Enable backups. Until you do that, there is no daily snapshot. After enable, the default schedule is 02:00 UTC. You can change it under Schedule, or click Backup now for an on-demand snapshot.

PostgreSQL uses continuous WAL plus base backups. MariaDB uses PhysicalBackup plus binlog PITR. Valkey uses RDB snapshots (no point-in-time slider). A workspace only offers these controls when the platform backup destination is configured.

Restore is never in-place

Restore always creates a new instance. The live database keeps running. After you smoke-test the copy, switch the app connection from the add-on Connections list or the app Add-ons tab.

Point-in-time recovery (PITR)

Once backups are enabled, PostgreSQL and MariaDB can restore to a timestamp, the latest backup, or a named backup. Valkey restore is snapshot-only.

Restore to a new instance

On the add-on Backups tab, click Restore. Choose Latest backup, Point in time, or Named backup. Give the copy a new instance name and click Create new instance.

Best practice

Leave the original instance running until you have checked the restore. Then switch the app connection. Postgres apps should read PGHOST / PG* (or DATABASE_URL only if one was injected).

On-demand backups

After backups are enabled, click Backup now on the add-on Backups tab before a risky migration. The snapshot appears in the list when the operator finishes.

Restoring from a snapshot

1.Open the add-on on the canvas and click Backups.
2.Click Restore and pick Latest backup, Point in time, or Named backup.
3.Name the new instance and click Create new instance.
4.When the copy is ready, switch the app connection. The original instance is unchanged.

Backup encryption

All backups are encrypted at rest. Encryption happens before data is written to the backup storage layer, so unencrypted data never lands there, and the keys are managed for you.

If your organisation has specific key-management or data-residency requirements, reach out to support to discuss the options available on Enterprise.

Testing your backups

A backup you've never tested is not a backup. Restore to a new instance, run your usual checks against the copy (Postgres clients honor PGHOST / PG*), then delete the copy if you do not need it.

Example validation

# After switching a throwaway app (or local env) to the restore:
psql -c "SELECT COUNT(*) FROM users;"
psql -c "SELECT COUNT(*) FROM orders WHERE created_at > NOW() - INTERVAL '7 days';"