PostgreSQL backup and disaster recovery

Operate CloudNativePG backups through the Barman Cloud plugin and plan cluster recovery.

CloudNativePG backs up the shared PostgreSQL cluster to S3-compatible object storage through the Barman Cloud plugin and its ObjectStore resource.

Backup model

The platform renders:

a Barman Cloud plugin deployment;
an ObjectStore resource describing the S3 endpoint, bucket, credentials, CA, and retention; and
a separate ScheduledBackup resource that references the plugin-backed object store.

The default destination is s3://cnpg-backups/cnpg. Configure the schedule and retention through the CNPG component values. The external ScheduledBackup deliberately avoids an immediate backup on every Argo CD sync.

Object-storage prerequisites

With Rook-Ceph, the platform creates the backup bucket and user and distributes the credentials to the required namespaces. With external-s3, the operator must pre-create the bucket, provide the credentials and CA, and confirm that the provider supports the required object operations and retention behavior.

Generated credentials use the current { kind = "secret" } model and persist in generated_secrets.env until moved into site-managed secret storage. Preserve these values across renders and upgrades.

Verify backups

Check the plugin, object store, schedule, and recent backup resources:

kubectl get pods -n cnpg
kubectl get objectstore -A
kubectl get scheduledbackup,backup -A
kubectl describe objectstore <object-store-name> -n cnpg

Confirm the object exists in the configured bucket and record the recovery point. A Kubernetes Completed state is not a substitute for verifying that the stored backup is readable.

Recovery planning

CloudNativePG recovery creates a new Cluster from an existing backup; it is not an in-place rewind of the running cluster. Before recovery:

identify every platform service using the shared PostgreSQL cluster;
select and verify a recovery point inside the retention window;
confirm access to the object-store credentials and CA used by that backup;
stop or isolate writers according to the recovery plan;
render a reviewed recovery cluster configuration; and
define validation and cutover steps before changing service endpoints.

A shared-cluster restore affects Keycloak, Grafana, LiteLLM, BSQAI API, MLflow, Superset, and other consumers together. Use application-specific export or restore procedures when only one logical database should be recovered.

Managed-ingestion recovery boundaries

Data Hub connection definitions, encrypted configuration and run history live in the BSQAI API database. Preserve the corresponding encryption keys as well as the database backup. Connector images remain in the customer registry; destination records remain in their native database or object store.

Ingestion progress is separate: the execution namespace holds the meltano-state PVC, backed up by meltano-state-backup to the configured S3-compatible bucket. A PostgreSQL restore does not recover that PVC, and a checkpoint restore does not recover destination records.

For coordinated recovery:

suspend ingestion schedules and event triggers and stop active execution;
identify compatible recovery points for application metadata, encryption keys, connector image versions, progress and destination data;
verify checkpoint backup readability and identity before using the supported restore operation;
run a controlled transfer and check destination records for missing or replayed data; and
resume automation only after the data owner accepts the result.

Resetting progress can replay records. Do not assume a database rollback or a successful checkpoint restore provides exactly-once delivery. See checkpoint operations and Data Hub recovery.

Upgrade checks

Before a platform upgrade, create and verify a current backup. After reconciliation, confirm that the Barman plugin is ready, the ObjectStore is valid, the schedule remains present, and a new backup can complete without credential or CA errors.