Setting Up a PostgreSQL Cluster with Scheduled Continuous Backup Enabled in KubeBlocks

This guide demonstrates how to configure a PostgreSQL cluster on KubeBlocks with:

• Scheduled full backups (base backups)
• Continuous WAL (Write-Ahead Log) archiving
• Point-In-Time Recovery (PITR) capabilities

This combination provides comprehensive data protection with minimal recovery point objectives (RPO).

What is PITR?

Point-In-Time Recovery (PITR) allows you to restore a database to a specific moment in time by combining full backups with continuous binlog/wal/archive log backups.

For details on restoring data from both full backups and continuous binlog backups, refer to the Restore From PITR guide.

Prerequisites

Before proceeding, ensure the following:

• Environment Setup:
  • A Kubernetes cluster is up and running.
  • The kubectl CLI tool is configured to communicate with your cluster.
  • KubeBlocks CLI and KubeBlocks Operator are installed. Follow the installation instructions here.
• Namespace Preparation: To keep resources isolated, create a dedicated namespace for this tutorial:

kubectl create ns demo
namespace/demo created

Prerequisites for Backup

1. Backup Repository Configured:

   • Configured BackupRepo
   • Network connectivity between cluster and repo, BackupRepo status is Ready

2. Cluster is Running:

   • Cluster must be in Running state
   • No ongoing operations (scaling, upgrades etc.)

List of Backup methods

KubeBlocks PostgreSQL supports these backup methods:

Deploy a PostgreSQL Cluster with Backup APIs

Deploy a 2-node PostgreSQL replication cluster (1 primary, 1 secondary) and specify backup information.

apiVersion: apps.kubeblocks.io/v1
kind: Cluster
metadata:
  name: pg-cluster
  namespace: demo
spec:
  terminationPolicy: Delete
  clusterDef: postgresql
  topology: replication
  componentSpecs:
    - name: postgresql
      serviceVersion: 16.4.0
      labels:
        apps.kubeblocks.postgres.patroni/scope: pg-cluster-postgresql
      disableExporter: true
      replicas: 2
      resources:
        limits:
          cpu: "0.5"
          memory: "0.5Gi"
        requests:
          cpu: "0.5"
          memory: "0.5Gi"
      volumeClaimTemplates:
        - name: data
          spec:
            accessModes:
              - ReadWriteOnce
            resources:
              requests:
                storage: 20Gi
  backup:
    retentionPeriod: 7d
    # for full backup
    method: pg-basebackup # full backup methnod name
    enabled: true
    cronExpression: 0 18 * * * # full backup scheuler
    # for continuous backup
    continuousMethod: archive-wal # continuous backup method
    pitrEnabled: true # enable continous method or not
    repoName: s3-repo # specify backuprepo, if not specified, the BackupRepo annotated as `default` will be used.

Or you can patch an existing cluster to enable scheduled continuous backup:

kubectl patch cluster pg-cluster -n demo --type='merge' -p='
{
  "spec": {
    "backup": {
      "retentionPeriod": "7d",
      "method": "pg-basebackup",
      "enabled": true,
      "cronExpression": "0 18 * * *",
      "continuousMethod": "archive-wal",
      "pitrEnabled": true,
      "repoName": "s3-repo"
    }
  }
}'

Key Configuration Fields Explained

Verifying the Deployment

Monitor the cluster status until it transitions to the Running state:

kubectl get cluster pg-cluster -n demo -w

Example Output:

NAME         CLUSTER-DEFINITION   TERMINATION-POLICY   STATUS     AGE
pg-cluster   postgresql           Delete               Creating   50s
pg-cluster   postgresql           Delete               Running    4m2s

Once the cluster status becomes Running, your PostgreSQL cluster is ready for use.

Monitoring Continuous Backups

Verify continuous backup operation with these commands:

# get continuous backup
kubectl get backup -l app.kubernetes.io/instance=pg-cluster,dataprotection.kubeblocks.io/backup-type=Continuous -n demo
# get stateful set working for continuous backup
kubectl get sts -l app.kubernetes.io/instance=pg-cluster,dataprotection.kubeblocks.io/backup-type=Continuous -n demo
# get pod working for continuous backup
kubectl get pod -l app.kubernetes.io/instance=pg-cluster,dataprotection.kubeblocks.io/backup-type=Continuous -n demo

Where labels

• app.kubernetes.io/instance=pg-cluster is used to identify resources by cluster name
• dataprotection.kubeblocks.io/backup-type=Continuous is used to identify backup by type (Continuous/Full)

Verifying Backup Configuration

KubeBlocks automatically creates a BackupSchedule resource. Inspect the configuration:

kubectl get backupschedule pg-cluster-postgresql-backup-schedule  -n demo -oyaml

Example Output:

apiVersion: dataprotection.kubeblocks.io/v1alpha1
kind: BackupSchedule
...
spec:
  backupPolicyName: pg-cluster-postgresql-backup-policy
  schedules:
  - backupMethod: pg-basebackup
    cronExpression: 0 18 * * *
    enabled: true #
    retentionPeriod: 7d
  - backupMethod: archive-wal
    cronExpression: '*/5 * * * *'
    enabled: true
    name: archive-wal
    retentionPeriod: 7d

1. Full Backups (pg-basebackup):

   • Creates complete cluster snapshots
   • Runs on configured schedule (daily by default)
   • Serves as base for PITR

2. Continuous Backups (wal-g-archive):

   • Archives WAL logs every 5 minutes
   • Enables recovery to any point in time
   • Requires full backup as starting point

Config WAL-G for Full Backup and Continuous Backup

Create a PostgreSQL Cluster

Deploy a 2-node PostgreSQL replication cluster (1 primary, 1 secondary)

apiVersion: apps.kubeblocks.io/v1
kind: Cluster
metadata:
  name: pg-cluster
  namespace: demo
spec:
  terminationPolicy: Delete
  clusterDef: postgresql
  topology: replication
  componentSpecs:
    - name: postgresql
      serviceVersion: 16.4.0
      labels:
        apps.kubeblocks.postgres.patroni/scope: pg-cluster-postgresql
      disableExporter: true
      replicas: 2
      resources:
        limits:
          cpu: "0.5"
          memory: "0.5Gi"
        requests:
          cpu: "0.5"
          memory: "0.5Gi"
      volumeClaimTemplates:
        - name: data
          spec:
            accessModes:
              - ReadWriteOnce
            resources:
              requests:
                storage: 20Gi

Config wal-g using config-wal-g backup method

To configure wal-g, you need to create a Backup resource with config-wal-g backup method. It is a special backup method that will create a wal-g configuration file for each replica in the cluster.

apiVersion: dataprotection.kubeblocks.io/v1alpha1
kind: Backup
metadata:
  name: pg-cluster-config-wal-g
  namespace: demo
spec:
  backupMethod: config-wal-g
  backupPolicyName: pg-cluster-postgresql-backup-policy
  deletionPolicy: Delete

If you forget to configure wal-g, you will see that Backups are Failed with the following error on backup pods:

fatal: unable to switch to directory: /home/postgres/pgdata/wal-g/env: file does not exist

Schedule Backups

Patch an existing cluster to enable scheduled continuous backup:

kubectl patch cluster pg-cluster -n demo --type='merge' -p='
{
  "spec": {
    "backup": {
      "retentionPeriod": "7d", # retention period
      "method": "wal-g", # full backup method
      "enabled": true, # enable full backup
      "cronExpression": "0 18 * * *", # full backup schedule
      "continuousMethod": "wal-g-archive", # continuous backup method
      "pitrEnabled": true, # enable continous method or not. Full backup is required for PITR, so you need to enable full backup first.
      "repoName": "s3-repo" # specify backuprepo, if not specified, the BackupRepo annotated as `default` will be used.
    }
  }
}'

After the cluster is patched, you will see immediate a continuous backup, of method `wal-g-archive', is running.

kubectl get backup -l app.kubernetes.io/instance=pg-cluster,dataprotection.kubeblocks.io/backup-type=Continuous -n demo

Summary

This guide covered:

1. Configuring scheduled full backups with pg-basebackup
2. Enabling continuous WAL archiving with wal-g-archive
3. Setting up Point-In-Time Recovery (PITR) capabilities
4. Monitoring backup operations

Key Benefits:

• Scheduled full backups ensure regular recovery points
• Continuous WAL archiving minimizes potential data loss
• PITR enables recovery to any moment in time