Backups

PostgreSQL Backups and Recovery

Thalassa Cloud DBaaS uses Barman (Backup and Recovery Manager) for PostgreSQL backups. Base backups and Write-Ahead Log (WAL) archives are stored in a backup object store — a managed object storage location dedicated to database backup data.

This page explains how backups work, how retention policy and retention mode interact, and how to restore to a point in time.

How backups work

When a cluster is linked to a backup object store:

The platform configures Barman to write base backups and WAL to the object store.
Continuous WAL archiving begins. WAL segments are archived as the database runs.
You create backup schedules and/or take manual backups.
A recovery window becomes available after the first successful base backup. Within that window you can restore to a specific time or LSN (point-in-time recovery).

Backups are disabled until a cluster is linked to a backup object store. You can create a cluster without backups and attach an object store later.

Component	Role
Backup object store	Managed location for base backups and WAL; owns retention settings for the store
Base backup	Full consistent snapshot of the database data directory
WAL archive	Continuous stream of changes required for point-in-time recovery
Backup schedule	Cron-style trigger for recurring base backups
Recovery window	Earliest and latest times to which you can restore for a given cluster

Backup object stores

A backup object store is a DBaaS resource. When you create one, the platform:

Provisions an object storage bucket in the selected region
Creates a service account and credentials used by Barman
Applies a bucket policy that allows the DBaaS service to write and manage backup objects

The bucket appears in your organisation’s object storage overview, but it is an internal bucket managed by the backup object store. You cannot delete or modify it through the object storage APIs or console. Lifecycle, policy, and deletion are controlled through the DBaaS backup object store resource.

When you delete a backup object store:

Delete behaviour	Result
Default	The platform deletes the underlying bucket and its backup contents
Keep / orphan child resources (`keepChildResources=true`)	The DBaaS object store (and its service account) are removed, but the bucket is left in place as a regular object storage bucket you can manage yourself

Use the keep option only when you intentionally want to retain the raw backup objects after removing the DBaaS object store resource.

Creating and attaching

You can provision a new object store when creating a cluster, attach an existing object store in the same region, or skip backups initially and enable them later from the cluster’s Backups tab.

One object store can back up multiple clusters in the same region (each cluster is a separate Barman server under the store). Changing or unlinking a cluster’s object store restarts the database so Barman can be reconfigured. Unlinking a cluster clears its backup schedules.

Bucket policy

The platform applies a bucket policy so the managed backup service can write and manage backup objects. While the backup object store exists, the bucket remains internal — you cannot change that policy through object storage management. Only after you delete the object store with the keep/orphan option does the bucket become a normal bucket you can manage yourself.

Retention policy

The retention policy on a backup object store defines how long backup data is kept. It is expressed as a number of days (for example 14d or 30d) and maps to Barman’s recovery-window retention:

RECOVERY WINDOW OF <N> days

Setting	Behaviour
Policy set (for example `30d`)	Backups older than the recovery window become eligible for cleanup according to the retention mode
Policy empty / cleared	Backups are retained indefinitely; storage usage can grow without bound

Note

We recommend 14 or 30 days for most production workloads, depending on compliance and recovery objectives. Development clusters often use shorter windows (for example 7d).

Schedules and retention

A backup schedule can set its own retention policy. When set, schedule retention must not exceed the linked object store’s retention policy. When a schedule leaves retention empty, it inherits the object store policy.

Retention mode

Retention mode controls what happens when backups fall outside the retention window. It is set on the backup object store and applies to cleanup behaviour for that store.

Mode	API value	Behaviour
Retain for point-in-time (default)	`retainForPointInTime`	Barman keeps enough base backups (and WAL) to restore to any time within the recovery window — including at least one backup older than the start of that window. Storage age can therefore exceed the configured retention days.
Force cleanup after expiry	`forceCleanupAfterExpiry`	Backups that have expired may be removed, including the latest, even if that shrinks or clears the usable PITR window

How policy and mode work together

Retention policy answers how far back you want to be able to restore. Retention mode answers how strictly expired backups are removed when that window is enforced.

Retention policy	Retention mode	Typical outcome
`30d`	Retain for point-in-time	About 30 days of PITR; one or more base backups may be older than 30 days so the full window stays restorable
`30d`	Force cleanup after expiry	Cleanup may remove all expired backups, including the newest; the recovery window can shrink or become empty
None (indefinite)	Either	Backups are not expired by policy; mode has no practical effect until you set a policy

Example: retain for point-in-time

Suppose the object store retention policy is 7d (a recovery window of 7 days) and retention mode is Retain for point-in-time.

Barman aims to let you restore to any point in the last 7 days. To restore to the start of that window, it needs a base backup that began before those 7 days, plus the WAL from that backup onward. Cleanup therefore keeps at least one backup older than the retention horizon.

For example, on 10 September with a 7-day window:

Item	Example
Desired PITR range	From ~3 September through now
Backup that may be retained	A base backup from 2 September (8 days old)
Why it is kept	Without a backup older than the window start, you could not restore all the way back to day 7

So you can see base backups whose age exceeds the configured retention policy days. That is expected with retainForPointInTime: the policy describes the recovery window you want, not a hard maximum age for every stored backup object.

With Force cleanup after expiry, Barman is allowed to remove expired backups more aggressively — including the latest — which can leave you without a backup old enough (or new enough) to cover the full window.
Retain for point-in-time is the recommended default for production. It balances storage growth with a usable recovery window.
Force cleanup after expiry is appropriate when you must strictly cap backup storage and accept that the recovery window can shrink or become empty after cleanup.

Note

Changing retention mode does not rewrite existing objects immediately; it changes how subsequent retention cleanup behaves.

Backup schedules

Schedules create recurring base backups. With continuous WAL archiving enabled, you typically do not need frequent full backups for PITR — WAL fills the gaps between base backups.

Recommendation	Guidance
Frequency	Weekly is sufficient for most clusters that use PITR
First backup	Take a manual backup after linking an object store so a recovery window exists before the first scheduled run
Suspend	Pausing a schedule stops new scheduled backups; existing backups and WAL archiving are unchanged

Without an attached object store, schedules cannot run and the console treats backups as disabled.

Manual backups

You can create a one-off backup at any time from the console or API. Manual backups are useful for:

Establishing the first recovery window
Capturing a known-good state before a risky change
Meeting an ad hoc compliance checkpoint

Manual backups respect the same object store retention policy and mode as scheduled backups.

Continuous archiving and health

When a cluster is linked to an object store, the platform enables continuous WAL archiving. Cluster health includes a continuous archiving condition that reports whether WAL is being archived successfully.

Signal	Meaning
Healthy	WAL archiving is succeeding
Unhealthy	Archiving is failing or stalled; PITR may stop advancing

Monitor continuous archiving alongside backup status. A successful base backup with failed WAL archiving limits how far forward you can recover.

If continuous archiving is unhealthy, check the condition reason and message in the console. Common causes include:

Cause	What to check
Temporary infrastructure issues	Recent failures often clear after retry; persistent failures need investigation
Custom PostgreSQL parameters	Settings that affect WAL generation or switching — for example `archive_timeout`, `wal_keep_size`, or segment-related parameters — can change how often WAL is archived or how archiving behaves under load

Low database activity is not the same as an unhealthy condition. WAL is typically archived when a segment fills or when archive_timeout elapses and there has been database activity. On a quiet database, the recoverable point can lag behind wall-clock time even while archiving remains healthy. Lower archive_timeout (for example 5min or 1min) if you need a tighter RPO during quiet periods. See Parameters for tunable settings.

Advanced

You can browse objects in a backup object store or a cluster’s backup path using the console and API. This allows you to inspect WAL and base directories, object sizes, verify the presence of WAL and base backup objects, or review storage usage for operational purposes. Prefer the managed recovery overview and cluster backup views for day-to-day restore planning.

Recovery windows

After at least one successful base backup, the platform exposes a recovery window for the cluster (and per Barman server on the object store). Typical fields include:

Field	Description
First recoverability point	Earliest time you can restore to
Last successful backup time	Timestamp of the latest successful base backup
Last failed backup time	Timestamp of the latest failed backup attempt, if any

Point-in-time recovery is available when the object store is ready and the recovery window has both a first recoverability point and a last successful backup time.
The continuous PITR range cannot extend beyond retained base backups and WAL. Shortening retention or using force cleanup can reduce or clear the window.

Point-in-time recovery (restore)

You restore by creating a new database cluster from an existing backup. Optionally specify a recovery target:

Target	Use when
Backup only (no target)	Restore to the end of that base backup
Target time (RFC 3339)	Restore to a specific timestamp within the recovery window
Target LSN	Restore to a specific PostgreSQL log sequence number

Choose a backup that is a valid base for the desired time (the backup’s begin/end WAL must cover the path to your target). The console and recovery views help you inspect coverage; WAL continuity derived from object names is an aid for analysis, not a guarantee that a restore will succeed.

Delete protection

Backup object stores and individual backups can be protected from accidental deletion. Enable delete protection on stores that hold production recovery data. Disable protection only when you intentionally plan to delete the resource.

Deleting a backup object store removes the DBaaS resource. By default the platform also deletes the underlying internal bucket and its contents. If you delete with the keep/orphan option (keepChildResources=true), the bucket is retained and becomes manageable as a normal object storage bucket. Clusters that used the store lose their backup destination until you attach another store.