Backup IBM API Connect Database Management Subsystem on demand

This article outlines the process of creating and verifying a backup of a Management Subsystem Database managed by Redhat Openshift using oc commands. We will walk through checking the status of our cluster, creating a backup, and verifying its completion.

Checking Cluster Status

Before initiating a backup, ensure that our Management Cluster is healthy and ready. Use the following commands to check the status of the management cluster and the database cluster:

oc -n <namespace> get ManagementCluster
oc -n <namespace> get cluster

[root@BASTION ~]# oc -n cp4i get ManagementCluster
NAME                         READY   STATUS    VERSION    RECONCILED VERSION   MESSAGE               AGE
apiconnect-production-mgmt   18/18   Running   10.0.8.0   10.0.8.0-258         Management is ready   16d

[root@BASTION ~]# oc -n cp4i get cluster
NAME                              AGE   INSTANCES   READY   STATUS                     PRIMARY
apiconnect-5019c580-5019c580-db   16d   1           1       Cluster in healthy state   apiconnect-5019c580-5019c580-db-1

Both commands indicate that the management cluster and database cluster are in a healthy state and ready for operations.

Creating a Backup Configuration File

Create a backup configuration file in YAML format. Here’s an example configuration named mgmtbackup_cr.yaml:

Change the name of spec.cluster.name

touch mgmtbackup_cr.yaml

apiVersion: postgresql.k8s.enterprisedb.io/v1
kind: Backup
metadata:
  generateName: mgmt-backup-
spec:
  cluster:
    name: apiconnect-5019c580-5019c580-db

Initiating the Backup

Once the YAML file is prepared, create the backup resource using oc:

oc -n <> create -f mgmtbackup_cr.yaml

[root@BASTION backup]# oc -n cp4i create -f mgmtbackup_cr.yaml
backup.postgresql.k8s.enterprisedb.io/mgmt-backup-cdfsd created

Verifying the Backup

To verify the status and details of the created backup, use the following command:

oc -n <namespace> get backup -o custom-columns="name:.metadata.name,backupId:.status.backupId,endpoint:.status.endpointURL,path:.status.destinationPath,servername:.status.serverName,status:.status.phase"

[root@BASTION backup]# kubectl -n cp4i get backup -o custom-columns="name:.metadata.name,backupId:.status.backupId,endpoint:.status.endpointURL,path:.status.destinationPath,servername:.status.serverName,status:.status.phase"
name                                        backupId          endpoint                                            path               servername                                           status
mgmt-backup-cdfsd                           20240731T085911   https://apiconnect-5019c580-s3proxy.cp4i.svc:8765   s3://edb-backups   apiconnect-5019c580-5019c580-db-2024-07-15T043558Z   completed

The output confirms that the backup process has been completed successfully. For a more detailed view of the backup resource, retrieve its full YAML representation:

kubectl -n cp4i get backup mgmt-backup-cdfsd -o yaml

[root@BASTION ~]# oc -n cp4i get backup mgmt-backup-cdfsd -o yaml
apiVersion: postgresql.k8s.enterprisedb.io/v1
kind: Backup
metadata:
  creationTimestamp: "2024-07-31T08:59:10Z"
  generateName: mgmt-backup-
  generation: 1
  name: mgmt-backup-cdfsd
  namespace: cp4i
  resourceVersion: "140517289"
  uid: e0c231d7-6024-49c5-be98-792a30d37ebe
spec:
  cluster:
    name: apiconnect-5019c580-5019c580-db
  method: barmanObjectStore
status:
  backupId: 20240731T085911
  backupName: backup-20240731085910
  beginLSN: 1/A1000028
  beginWal: 0000000100000001000000A1
  destinationPath: s3://edb-backups
  endLSN: 1/A1004558
  endWal: 0000000100000001000000A1
  endpointCA:
    key: ca.crt
    name: apiconnect-5019c580-server
  endpointURL: https://apiconnect-5019c580-s3proxy.cp4i.svc:8765
  instanceID:
    ContainerID: cri-o://f1882f8e12144f7fa1f81eacdac1ee67b38272bb3e29e655adc9ddc377edbde2
    podName: apiconnect-5019c580-5019c580-db-1
  method: barmanObjectStore
  phase: completed
  s3Credentials:
    accessKeyId:
      key: key
      name: apiconnect-5019c580-s3proxy-auth
    secretAccessKey:
      key: keysecret
      name: apiconnect-5019c580-s3proxy-auth
  serverName: apiconnect-5019c580-5019c580-db-2024-07-15T043558Z
  startedAt: "2024-07-31T08:59:11Z"
  stoppedAt: "2024-07-31T08:59:24Z"

Checking the SFTP Server

If you successfully backup the database, your SFTP server will be look like this

Make sure on your /base folder, there is one backup

[root@SFTP mgmtb]# ls -lRt
.:
total 0
drwxr-xr-x. 4 sftpuser sftpuser 30 Jul 31 08:00 apiconnect-5019c580-5019c580-db-2024-07-15T043558Z

./apiconnect-5019c580-5019c580-db-2024-07-15T043558Z:
total 0
drwxr-xr-x. 4 sftpuser sftpuser 52 Jul 31 15:59 base
drwxr-xr-x. 3 sftpuser sftpuser 30 Jul 30 15:59 wals

./apiconnect-5019c580-5019c580-db-2024-07-15T043558Z/base:
total 0
drwxr-xr-x. 2 sftpuser sftpuser 70 Jul 31 15:59 20240731T085911

./apiconnect-5019c580-5019c580-db-2024-07-15T043558Z/base/20240731T085911:
total 4
-rw-r--r--. 1 sftpuser sftpuser 1316 Jul 31 15:59 backup.info
-rw-r--r--. 1 sftpuser sftpuser    0 Jul 31 15:59 data.tar.gz

./apiconnect-5019c580-5019c580-db-2024-07-15T043558Z/wals:
total 4
drwxr-xr-x. 2 sftpuser sftpuser 4096 Jul 31 15:59 0000000100000001

./apiconnect-5019c580-5019c580-db-2024-07-15T043558Z/wals/0000000100000001:
total 26432
-rw-r--r--. 1 sftpuser sftpuser   16649 Jul 31 15:59 0000000100000001000000A2.gz
-rw-r--r--. 1 sftpuser sftpuser     212 Jul 31 15:59 0000000100000001000000A1.00000028.backup.gz
-rw-r--r--. 1 sftpuser sftpuser   20916 Jul 31 15:59 0000000100000001000000A1.gz
-rw-r--r--. 1 sftpuser sftpuser 1060792 Jul 31 15:59 0000000100000001000000A0.gz

You Can Read This : Backing up and restoring the management subsystem