Backup and restore

PostgreSQL databases — whether the standalone PostgreSQL template or the PostgreSQL instance embedded in Digdash BI — can be continuously backed up to S3 storage, then restored into a new application.

Enabling backups

In the deployment form (Backup section), or afterwards via Configure → Advanced settings:

1. Enable scheduled backups: enables both continuous log archiving (WAL) and scheduled base backups — both are required to be able to restore.
2. Retention policy: how long backups are kept, for example 7d, 4w.
3. S3 path (destinationPath): the target bucket. Choose Existing bucket to select a platform bucket — the s3://… path and the endpoint are filled in automatically.
4. Access Key / Secret Key: the bucket's credentials (provided by the Buckets page).

Immediate backup

The default schedule is daily. To produce a first backup without waiting, an immediate-backup option is available in the backup settings.

Restoring

Restoring creates a new application whose database starts from the backup — the original application is not modified.

1. New app → the same template as the source (PostgreSQL or Digdash BI).
2. In the Restore section:
   • enable restore;
   • Source app name: the exact name of the application the backup was written from (as shown on its card);
   • S3 path of the backup to restore: the same bucket as the backup;
   • the bucket's S3 credentials.
3. Deploy: the new application starts by replaying the backup, then moves to Running.

Warning

If the S3 source is empty, unreachable or corrupted, the new application won't start (crash-restart loop). Check the bucket's contents from the Buckets page before starting the restore.

Restoring to a specific date

By default, a restore replays the backup up to the most recent available point (the end of the WAL log stream). It's also possible to restore the database exactly as it was at a given moment in the past — useful, for example, to undo the effects of a deletion or a failed migration that happened after the last valid backup.

Example: daily backups, restoring to yesterday 11:59 PM

A source application has scheduled backups enabled with a daily schedule (0 0 0 * * *, i.e. midnight every day) and a 7-day retention. An error is discovered today, and you want to recover the database exactly as it was yesterday at 11:59 PM, just before the midnight backup:

1. New app → the same template as the source.
2. Restore section: enable it, fill in Source app name and S3 path of the backup to restore as for a regular restore.
3. Restore to a specific date (optional): enter 2024-06-24 23:59:00+02 (adjust the date and time zone).
4. Deploy: CNPG restores the backup, then replays the archived WAL logs up to the given moment, without going further.

Tip

The time zone is part of the value (+02, +00…) — without it, the time is interpreted in the PostgreSQL server's own time zone. The chain of WAL logs between the backup and the target moment must be intact: too short a retention, or a missing backup in between, will prevent the restore from reaching the requested date.

Volume snapshots

Independently of S3 backups, any persistent volume can be point-in-time snapshotted and cloned — see Volumes.