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.
- Raw events and process analysis by directly accessing the file system, by using a persistent volume.
- 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:
- Look for the Persistent Volume having the following Persistent Volume Claims:
processmining-repository
andprocessmining-mongo
(processmining-mongo is present only if the embedded MongoDB is used). - 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:
-
Open a terminal and log in to the cluster:
oc login --token=<LOGIN TOKEN> --server=https://<SERVER URL > oc project mynamespace oc get pods
-
Look for the IBM Process Mining engine pod, typically the name starts with
<instance name>-engine
. -
Create a local folder, for example,
/temp/processmining
. -
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.
-
Open a terminal and log in to the cluster:
oc login --token=<LOGIN TOKEN> --server=https://<SERVER URL > oc project mynamespace
-
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
-
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>
-
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:
- Task events and activity logs by directly accessing the file system, by using a persistent volume.
- 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:
-
Open a terminal and login to the cluster:
oc login --token=<LOGIN TOKEN> --server=https://<SERVER URL > oc project mynamespace oc get pods
-
Look for the taskbuilder engine pod name, typically the name starts with
<instance name>-taskbuilder
. -
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.