Backing up and restoring data in Red Hat OpenShift Container Platform environments

This section describes the procedure for backing up and restoring data that is related to the processes analyzed by the IBM Process Mining and IBM Task Mining components.

Both IBM Process Mining and IBM Task Mining use persistent volumes to store the process events and analysis.

Procedure to back up and restore IBM Process Mining

The IBM Process Mining component stores information in two places.

  1. Raw events and process analysis by directly accessing the file system, by using a persistent volume.
  2. More meta-information on processes, organizations, user-profiling on MongoDB. The MongoDB instance can be external or hosted in a cluster Pod. In the latter case, it stores the information on a persistent volume.

The next section describes the alternative options for backing up the data that is managed by IBM Process Mining.

Back up Persistent Volumes

To back up the persistent volumes directly, follow these steps:

  1. Look for the Persistent Volume having the following Persistent Volume Claims: processmining-repository and processmining-mongo (processmining-mongo is present only if the embedded MongoDB is used).
  2. Perform the backup of the Persistent Volume following the policy that is related to the storageClass.

Restore Persistent Volume

To restore, follow the restore policy that is related to the storageClass and re-create the PVC with the original name.

Back up Accessing to Pods

As an alternative solution to the back up of persistent volumes, it's possible to back up the file system and MongoDB by directly accessing the Pods.

Back up of engine Podfile system

To back up the file system of engine pod, where raw events and process analysis are stored, perform the following steps:

  1. Open a terminal and log in to the cluster:

    oc login --token=<LOGIN TOKEN> --server=https://<SERVER URL >
    oc project mynamespace
    oc get pods
    
  2. Look for the IBM Process Mining engine pod, typically the name starts with <instance name>-engine.

  3. Create a local folder, for example, /temp/processmining.

  4. Copy the /data folder of the pod in a location of your local workstation (for example, /temp/processmining) by using the following command:

    oc rsync <NAME OF THE ENGINE POD>:/data /temp/processmining
    

    Note: If you get a failure as follows, it indicates that there was a write occurring when the rsync command is in progress. To resolve the failure, continuously run the command until you get no errors.

    tar: data/upload: file changed as we read it
    error: error creating remote tar of source directory: command terminated with exit code 1
    

Restore the Engine Podfile System

To restore, perform the same procedure to get access to the Pod, then run the following command:

oc rsync /temp/processmining <NAME OF THE ENGINE POD>:/data

Back up and restore MongoDB

Back up MongoDB

If an external database is used (which is expected in a production environment), contact the DB Administrator for the correct back up or restore procedure.

The section is valid only for the embedded instance of MongoDB installed into the IBM Process Mining component.

To back up the MongoDB instance, you are required to forward the 27017 port from the Mongo Pod to the workstation of the system administrator doing the back up.

  1. Open a terminal and log in to the cluster:

    oc login --token=<LOGIN TOKEN> --server=https://<SERVER URL >
    oc project mynamespace
    
  2. Run the following command to get the mongo pod name<processmining instancename>-mongo-db-NUMBER-HexNumber>, for example, pminstance-mongo-db-594987f848-7a7kg.

    oc get pods | grep mongo
    
  3. Use the mongo pod name to perform the following oc rsh command:

    oc rsh pminstance-mongo-db-594987f848-7a7kg
    sh-4.4$ echo $persistence_mongodb_database
    processmining
    sh-4.4$ echo $persistence_mongodb_user
    processmininguser
    sh-4.4$ echo $persistence_mongodb_password
    <persistence_mongodb_password>
    
  4. Run the backup command:

    mongodump --host localhost --username processmininguser --password <THE PASSWORD> --db processmining --archive=backupmongo.archive
    

    Note: If MongoDB is externally provided, you must use the values that are defined in the external section of the CRD.

Restore MongoDB

To restore the MongoDB instance, first follow the procedure to obtain the database connection, then run the following command:

mongorestore --host localhost --username processmininguser --password <THE PASSWORD> --db processmining --archive=backupmongo.archive --nsFrom "processmining.*" --nsTo "processmining.*" 

Procedure to back up and restore Task Mining

The IBM Task Mining component stores information in two places:

  1. Task events and activity logs by directly accessing the file system, by using a persistent volume.
  2. Process and workflow metadata in Db2 or MySQL database.

We describe two alternative options for backing up the data that is managed by the IBM Task Mining component.

Back up Persistent Volume

Following are the steps to back up the persistent volume directly:

  • Look for the Persistent Volume having the following Persistent Volume Claim: taskmining-data.
  • Run the back up of the Persistent Volume following the policy that is related to the storageClass.

Restore the Persistent Volume

  • To restore, follow the restore policy that is related to the storageClass and re-create the PCV with the original name.

Back up the Pod Access

As an alternative solution to the back up of persistent volumes, it is possible to back up the file system by directly accessing the application Pods.

Back up the Engine Podfile System

To back up the file system of engine pod, where task events and activity logs are stored, follow these steps:

  1. Open a terminal and login to the cluster:

    oc login --token=<LOGIN TOKEN> --server=https://<SERVER URL >
    oc project mynamespace
    oc get pods
    
  2. Look for the taskbuilder engine pod name, typically the name starts with <instance name>-taskbuilder.

  3. Copy the /data folder of the pod in a location of your local workstation (for example, /temp/processmining) by using the following command:

    oc rsync <NAME OF THE taskbuilder POD>:/data /temp/taskmining
    

    Note: If you get a failure as follows, it indicates that there was a write occurring when the rsync command is in progress. To resolve the failure, continuously run the command until you get no errors.

    tar: data/upload: file changed as we read it
    error: error creating remote tar of source directory: command terminated with exit code 1
    

Restore the Engine Podfile system

To restore, login to the target cluster, then run the following command:

oc rsync /temp/processmining <NAME OF THE taskbuilder POD>:/data

Back up MySQL DB

Since an external database is used, as should be in a production environment, contact the DB Administrator for the correct back up or restore procedure.

Back up Db2

Refer to the Db2 documentation for details. For more information, see back up restore.