Author: Maya Anilson (maya.anilson@in.ibm.com),  Ukthi Prasad (Ukthi.G.prasad@ibm.com)

There are a few ways to protect your application running on Red Hat® OpenShift® Container Platform from a disaster. The simplest and cost-effective solution among those is using the Red Hat OpenShift API for Data Protection (OADP) operator.

This blog provides a step-by-step procedure to back up and restore a stateful application running on Red Hat OpenShift cluster on IBM Z® and IBM® LinuxONE to a S3 storage using OADP.

OADP backs up and restores Kubernetes resources and internal images at the granularity of a namespace by using Velero, which is an open source tool for storing, restoring, and migrating Kubernetes cluster resources and persistent volumes. It backs up all the resources in the application namespaces including the metadata, persistent volumes attached to the pods and the internal images. However, OADP cannot be used to back up etcd and Red Hat OpenShift operators.

OADP 1.3.0 introduces Kopia as the backup and restore tool in addition to Restic. There are two ways to back up the application data stored in persistent volumes.

• File System Backup (FSB) or Pod Volume Backup (PVB) - in this method the Kubernetes volumes are backed up from the file system of the volumes. This can be done using both Kopia or Restic method. If the applications are on NFS data volumes, then use this method for backup and restore.

• Container Storage Interface (CSI) snapshots – in this method the Kubernetes volumes are backed up by taking the CSI snapshots of the volumes. OADP uses Kopia as the uploader mechanism to move the CSI snapshots from the Red Hat OpenShift cluster to the backup storage location.

The blog has been split in two parts to cover the different solutions available for backup and restore using OADP. This blog is part 1 and covers the backup and restore using the File System method. Part 2 (https://community.ibm.com/community/user/ibmz-and-linuxone/blogs/maya-anilson/2024/04/03/securing-red-hat-openshift-apps-with-oadp-on-ibm-z) is covering the backup of persistent volumes with CSI snapshots.

Prerequisite

• ·      Install OADP operator on your Red Hat OpenShift cluster.

Deploy a stateful application and add some data.

This example uses a MySQL database as an example of the stateful application.  The screenshot below shows the deployment of a MySQL database. A new schema named ‘world’ is created with 3 tables in it. To verify that the restore has successfully restored the persistent volume on a recovery cluster, we will check if the schema world and its tables are available after the restore.

Back up application using OADP to the S3 bucket created on Amazon Web Services (AWS)

In this example, AWS S3 bucket is used as the backup storage location, however, similar steps can be used for any other supported backup storage location such as Red Hat OpenShift Data Foundation, or Google Cloud Platform, or IBM Cloud Object Storage.

Step: 1

Create a default secret

Create a bucket either using AWS cli or from the AWS console.

Refer:  https://docs.openshift.com/container-platform/4.15/backup_and_restore/application_backup_and_restore/installing/installing-oadp-aws.html

Obtain AWS_SECRET_ACCESS_KEY and AWS_ACCESS_KEY_ID which is used for creating a Secret to access the bucket from the OpenShift Cluster.

[default]

aws_access_key_id = ZIVTSN5YN2GW8S842

aws_secret_access_key = FYXEWCtMdEPLnUehi7eObg3P27hQGXToII

Create a secret with a default name cloud-credentials using the above AWS credentials.

Step: 2

Configure Data Protection Application

The below yaml definition for the Data Protection Application (DPA) uses uploader type as Kopia. If you are using File System Backup method, then this can be done with Restic or Kopia.

‘cloud-credential’ is the secret that was created in step 1.

Verify if the BackupStorageLocation resource is created, wait until it is in ‘Available’ phase.

Step: 3

Backup MySQL application using File System Backup method

To back up a backup custom resource is created, which contains the information of which application namespace is being backed up.

Example:

  includedNamespaces:

  - mysql-persistent

BackupStorageLocation name created by configuring the DPA in Step 2 is specified in

  storageLocation: dpa-csi-1

If persistent volume needs to be backed up as File System Volume, then specify this using

  defaultVolumesToFsBackup: true

An example backup custom resource

Apply the above yaml to create the backup custom resource and verify the status of the backup. The backup phase is marked as completed if the backup completes without any failure.

Login to AWS S3 console to view the backup data

Step: 4

Restore the application

In the event of a disaster, the application can be restored on another cluster by the following steps.

Repeat step 1 and 2 on the recovery cluster by creating the secret and the backup storage location. Ensure the backup storage location is in ‘Available’ phase.

Create restore custom resource

The example below shows a restore custom resource yaml that specifies the backup name that you wish to use for the restore and an option to specify if the persistent volume also needs to be restored.

The snapshot below shows the restore custom resource is being created and the status of the restore is being verified. Wait for the restore status to show ‘Completed’ if the restore completes successfully. Otherwise, the status is either ‘Failed’ or ‘PartiallyFailed’ in case of failure.

oc apply -f restore.yaml

oc get restore -n openshift-adp restore-mysql -o jsonpath='{.status.phase}{"\n"}'

The MySQL-persistent application is successfully restored along with its data on the cluster a3e27001.