Backing up and restoring data

Backing up data

Run the backup action to back up data. Replace instance_namespace with the namespace of the WebSphere Automation instance to back up.

oc ibm-pak launch $CASE_NAME \
 --version $CASE_VERSION \
 --inventory automationOperator \
 --action backup \
 --namespace instance_namespace

The backup action requires a persistent volume to store the backup information. By default, the action creates the volume dynamically. If dynamic storage provisioning is not supported or you want to use a different persistent volume, add the following arguments for an existing persistent volume claim (PVC).

--args "--claim persistent_volume_name"

The backup action starts a job that backs up the data and resources. The output of the backup action shows a separate command to run to obtain the logs of that job.

Each time the backup action runs, it creates a unique directory with the backup data on the persistent volume. The unique directory name has a timestamp that is based on the time and date when the command was run; for example, 20210528-120120. You use the directory name to restore the data from a backup.

Restoring data

You can recover an existing WebSphere Automation installation data from a backup. The recovery process involves deleting the existing data to put the installation in an initial state and then restoring the data from a backup. Recovering a WebSphere Automation installation to another namespace in the same or another Red Hat OpenShift cluster is not currently supported.

In WebSphere Automation 1.4.4 and later, custom resources are backed up and restored. Therefore, it is not necessary to scale the replicas back up for the various components (steps 7, 8, and 9 in the following list).

1. Find the backup timestamp from which you want to recover. To list the available backups, run the restore action without any arguments.

   oc ibm-pak launch $CASE_NAME \
    --version $CASE_VERSION \
    --inventory automationOperator \
    --action restore \
    --namespace instance_namespace

   The restore action starts a job that lists the available backups. The output of the restore action shows a separate command to run to obtain the logs of that job. The logs contain the list of available backups.

2. Scale the number of replicas for all WebSphere Automation to zero.

   You can do this by setting the spec.scaleToZero parameter in the WebSphereAutomation custom resource to true. For more information see WebSphereAutomation custom resource.

   WSA_INSTANCE_NAMESPACE=instance_namespace		
   WSA_AUTOMATION_CR=$(oc get websphereautomation -o name -n $WSA_INSTANCE_NAMESPACE | cut -d/ -f2) 
   oc patch websphereautomation $WSA_AUTOMATION_CR -p '{"spec":{"scaleToZero":true}}' --type merge -n $WSA_INSTANCE_NAMESPACE

   The scale to zero operation can take 1-2 minutes to complete. You get an empty result if the operation is completed.

   oc get pods -n $WSA_INSTANCE_NAMESPACE | grep Running | grep -v $WSA_AUTOMATION_CR-mongo | grep $WSA_AUTOMATION_CR-

3. Delete existing WebSphere Automation data.
   Warning: The delete commands in this step delete existing data! If you are unsure about this step, consider cloning all the WebSphere Automation persistent volumes first.
   1. Scale the data store replicas to zero.

      oc patch websphereautomation $WSA_AUTOMATION_CR -p '{"spec":{"dataStore":{"replicas":0}}}' --type merge -n $WSA_INSTANCE_NAMESPACE

      To validate that the data store is scaled down:

      oc get pods -n $WSA_INSTANCE_NAMESPACE | grep Running | grep $WSA_AUTOMATION_CR-mongo

   2. Delete persistent volume claims (PVC) associated with the data store.

      oc delete pvc -l app.kubernetes.io/instance=${WSA_AUTOMATION_CR}-mongo -n $WSA_INSTANCE_NAMESPACE 

   3. Scale the data store replicas back.

      oc patch websphereautomation $WSA_AUTOMATION_CR -p '{"spec":{"dataStore":{"replicas":3}}}' --type merge -n $WSA_INSTANCE_NAMESPACE

   4. Ensure that the WebSphere Automation operator re-created the PVCs and that the data store is ready. You want the command output to be True.

      oc get websphereautomation $WSA_AUTOMATION_CR -o jsonpath='{.status.conditions[?(@.type=="DataStoreReady")].status}' -n $WSA_INSTANCE_NAMESPACE && echo

4. To restore from a backup, run the restore action with the --timestamp argument. Replace timestamp with the timestamp of the backup directory that you want to restore.

   oc ibm-pak launch $CASE_NAME \
    --version $CASE_VERSION \
    --inventory automationOperator \
    --action restore \
    --namespace $WSA_INSTANCE_NAMESPACE \
    --args "--timestamp <timestamp>"

   The restore action starts a job that restores the data and resources. The output of the restore action shows a separate command to run to get the logs of that job.

   Note: If the restore action is not run immediately after the previous step, the log files might indicate that some documents failed to restore.

   continuing through error: E11000 duplicate key error collection: webspheresecuredb.bulletins index: _id_ dup key: { _id: "3d7329df-abec-377d-bf5e-1181947b6c0d" }

   You can ignore these log entries because the collection is automatically populated when a new instance is created or restored.

After restoration, confirm that the restored installation runs as wanted, and that the data is available.

oc get job -n $WSA_INSTANCE_NAMESPACE | grep wsa-restore

oc delete job job_name -n $WSA_INSTANCE_NAMESPACE