NuPaaS DocsBackups & restore
Managed PostgreSQL databases are backed up continuously and on a daily schedule, with no configuration on your part. Restores come in two shapes: rewinding an instance to a point in time, or cloning to a new instance.
What is backed up
| Parameter | Type | Description |
|---|---|---|
| PostgreSQL databases | automatic | Continuous write-ahead-log archiving plus a scheduled daily base backup. Supports point-in-time restore. |
| Storage buckets | mirror | Buckets are mirrored off-cluster; each bucket reports when it was last mirrored and how many objects were included. |
PostgreSQL backups
Two mechanisms run together:
- Continuous WAL archiving. Write-ahead log segments are shipped continuously. This is what makes point-in-time restore possible between base backups.
- Scheduled base backups. A full base backup is taken once a day at 02:00. Base backups shorten recovery time — a restore replays WAL forward from the most recent base backup rather than from the beginning.
Retention
Backup retention defaults to 30 days per database. It can be set per database, between 1 and 365 days, as part of a plan change through the API.
Taking a backup now
The header of a database's detail page has a Trigger backup action. It is enabled only while the instance is in the ready state — triggering one against an instance that is still provisioning or in error is rejected.
A separate operation that creates an on-demand backup and returns its id is available through the API. It is PostgreSQL-only and rejects other engines explicitly.
Reviewing backups
The Backups tab lists the 25 most recent backups for the instance, showing when each was created, whether it was manual or scheduled, its size, and its status (completed, failed or in_progress).
A summary is also available through the API: last backup time, last backup status, next scheduled run, and the total number of backups held.
Point-in-time restore
The PITR Restore tab restores the instance to a timestamp you choose. Pick the target time and confirm; the platform provisions a restored cluster from the nearest base backup and replays WAL forward to that instant.
The restored cluster keeps its own backups, honouring the same per-database retention setting.
Restoring into a new database
Cloning creates a brand-new instance from an existing one, given the source database and a name for the copy. The original is untouched, which makes it the safe option for investigating a data problem or producing a scrubbed copy for testing.
Object storage backups
Buckets are mirrored to off-cluster storage. Each bucket carries the timestamp of its last successful mirror and the number of objects that mirror covered, so you can tell whether a bucket's copy is current.
There is no self-service restore-from-mirror in the panel. Recovering a bucket from its off-cluster copy is an operator-assisted operation — open a support request.
What this page does not cover
Backups of the NuPaaS platform itself, and the health of the platform's own backup jobs, are operator functions. They are not exposed to tenant organizations and are not what the Backups tab on your database shows.
Checking your own backups
platform db list
platform db credentials --id <databaseId>The platform CLI has no backup subcommand today; backup review and restore are done in the panel or through the API.