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.

Backing up and restoring 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.

Backing 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.

Restoring the Persistent Volume

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

Backing up by accessing the 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.

Backing up the engine pod file 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

    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

Restoring engine pod file 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 --delete=true

Backing up and restoring MongoDB

Backing 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:

    a. Use your user credentials:

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

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

    b. Optional: If the backup command with user credentials does not work, use the following admin credentials:

    /usr/bin/mongodump --host localhost --username admin --password <THE PASSWORD> --authenticationDatabase admin --db processmining --archive=/tmp/backup.archive

    To acquire <THE PASSWORD> for admin credentials, use the following command:

    echo $MONGODB_ADMIN_PASS

Restoring 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.*" --drop

Re-creating MonetDB data

MonetDB content cannot be backed up. You can recreate tables using the Visualize button.

To re-create tables, do the following instruction:

  1. In your project, enter the Manage tab.
  2. Open the Data source.
  3. Click Visualize to re-create the lost data.

MonetDB visualization

Backing up and restoring 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.

Backing up the 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.

Restoring the Persistent Volume

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

Backing up the engine pod file system

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.

Backing up the engine pod file 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

    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

Restoring the engine pod file 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 taskbuilder POD>:/data --delete=true

Backing 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.

Backing up Db2

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