Backing up and restoring

To access a S3 storage account, you need to create a secret that contains the Access Key ID and Access Secret:

apiVersion: v1
kind: Secret
metadata:
  name: s3-credentials
type: Opaque
data:
  ACCESS_KEY_ID: QUNDRVNTX0tFWV9JRA==
  ACCESS_SECRET_KEY: QUNDRVNTX1NFQ1JFVF9LRVk=

You can also create this secret using the following command:

kubectl create secret generic s3-credentials \
  --from-literal=ACCESS_KEY_ID=<access key here> \
  --from-literal=ACCESS_SECRET_KEY=<secret key here>

This secret is referenced in the spec.backup section of the BTS CR to ensure access to the S3 storage account.

The S3 storage account must be configured in the BTS CR.

For example:

spec:
  backup:
    barmanObjectStore:
      destinationPath: s3://<s3-bucket-name>/
      s3Credentials:
        accessKeyId:
          key: ACCESS_KEY_ID
          name: s3-credentials
        secretAccessKey:
          key: ACCESS_SECRET_KEY
          name: s3-credentials

The App-User secret contains the username and password for the BTS PostgreSQL database. This secret is auto-generated when the BTS database is created from scratch. This secret must be stored in a safe place. You need to re-create this secret to successfully restore the database.

oc get secret ibm-bts-cnpg-cp4ba-bts-app -o yaml >postgres-app-credential.yaml

This command exports the output that resembles the following sample:

apiVersion: v1
kind: Secret
data:
  username: cG9zdGdyZXNhZG1pbg==
  password: YWJjZGVmZzEyMzQ1Njc=
  pgpass: aWJtLWJ0cy1jbnBnLWNwNGJhLWJ0cy1ydzo1NDMyOkJUU0RCOnBvc3RncmVzYWRtaW46YWJjZGVmZzEyMzQ1Njc=

Store the postgres-app-credential.yaml file in a safe place.

Note that the secret name consists of the Cluster CR followed by -app: <cluster-name>-app

The name of the Cluster CR can be obtained from following command:

$ oc get cluster
NAME                     AGE   INSTANCES   READY   STATUS                     PRIMARY
ibm-bts-cnpg-cp4ba-bts   14m   2           2       Cluster in healthy state   ibm-bts-cnpg-cp4ba-bts-1

To invoke an on-demand backup, or schedule backups a Backup or ScheduledBackup CR must be created in the namespace of BTS:

apiVersion: postgresql.k8s.enterprisedb.io/v1
kind: Backup
metadata:
  name: ibm-bts-cnpg-cp4ba-bts-backup
spec:
  cluster:
    name: ibm-bts-cnpg-cp4ba-bts

The name property of the Backup object must conform to the name of the PostgreSQL cluster object. To retrieve the name, execute oc get Cluster in the BTS namespace:

$ oc get cluster
NAME                     AGE   INSTANCES   READY   STATUS                     PRIMARY
ibm-bts-cnpg-cp4ba-bts   14m   2           2       Cluster in healthy state   ibm-bts-cnpg-cp4ba-bts-1

You can find the backup status in the status field of the Backup CR, and make sure the backup phase is completed.

$ oc get backup ibm-bts-cnpg-cp4ba-bts-backup -o yaml
...
status:
  ...
  phase: completed
  ...

You can also create a scheduled backup using the ScheduledBackup CR:

apiVersion: postgresql.cnpg.io/v1
kind: ScheduledBackup
metadata:
  name: backup-example
spec:
  schedule: "0 0 0 * * *"
  cluster:
    name: ibm-bts-cnpg-cp4ba-bts

The main difference is the spec.schedule property where you can specify the backup schedule based on the Kubernetes CronJob format.

For more information, seeBackup and Recovery.

To access a S3 storage account, you need to create a secret that contains the Access Key ID and Access Secret. Complete the following procedure: Create a secret with credentials for your S3 compatible storage..

The App-User secret that was exported in Export the App-User secret for the database. must be re-created into the target namespace:

oc apply -f postgres-app-credential.yaml

To restore the data from the S3 storage, you must to configure the spec.recovery section of the BTS CR.

For example:

spec:
  recovery:
    barmanObjectStore:
      destinationPath: s3://<s3-bucket-name>/
      s3Credentials:
        accessKeyId:
          key: ACCESS_KEY_ID
          name: s3-credentials
        secretAccessKey:
          key: ACCESS_SECRET_KEY
          name: s3-credentials

The BTS Operator will take over backup and restore in the PostgreSQL Cluster CR and the BTS database will be restored from the existing backup using the Bootstrap from a backup bootstrap method of the PostgreSQL Operator.

By following this procedure, you will create a recovery job and a pod that initializes the database from the backup before the database pods get started.