Restoring IBM Business Automation Workflow on Containers

To restore your IBM Business Automation Workflow deployment on containers, it is essential to thoroughly prepare the target environment in advance. This preparatory step is critical to ensuring that the restored deployment functions reliably and remains consistent with the original configuration.

Before you begin

The disaster recovery process requires backing up and restoring both IBM Business Automation Workflow components and Cloud Pak foundational services. This content applies to only the IBM Business Automation Workflow components. For foundational services (example - IAM, cert-manager), see IBM Cloud Pak® foundational services External link opens a new window or tab.

Procedure

  1. Prepare the target cluster.
    • Set up a new Kubernetes cluster with the same version and configuration as the source cluster.
    • Reinstall the Business Automation Workflow operator. You can use the baw-cluster-admin script to deploy the operator and any capability-specific operators (example - Business Automation Studio).
    • Ensure all required namespaces (example - baw) are created.
  2. Restore secrets.
    To restore all required secrets for each namespace:
    • You can use the provided script to automate the restoration process.
    • Before you run the script, ensure that any environment-specific values, such as client-ids or tokens are updated to match the new environment.
    • If you are unable to modify these values in the script, manually apply the secrets to avoid configuration issues.
    for ns in $(ls -d k8s-backup-secret*/ | cut -d'/' -f2); do
      kubectl get ns $ns >/dev/null 2>&1 || kubectl create ns $ns
      if [ -f k8s-backup-secret*/$ns/secrets.yaml ]; then
        kubectl apply -f k8s-backup-secret*/$ns/secrets.yaml -n $ns
      else
        echo "Missing secrets.yaml for namespace $ns"
      fi
    done
    

    Ensure that the following critical secrets are restored before you apply the custom resource (CR):

    • ibm-fncm-secret
    • ibm-ban-secret
    • ibm-baw-wfs-server-db-secret
    • ibm-icc-secret
    • ldap-bind-secret
    • Any other application-specific secrets
  3. Restore Configmaps.
    Your application relies on specific key value pairs that are stored in Configmap. To restore them:
    • You can use the provided script to restore all Configmap.
    • Before you run the script, ensure that any environment-specific values such as client-ids or tokens are updated to match the new environment.
    • If you are unable to update these values:
      • Either manually apply the backed-up Configmap, or
      • Skip this step and allow the CR to re-create the necessary Configmap automatically.
    for ns in $(ls k8s-backup-configmap*/); do
      kubectl apply -f k8s-backup-configmap*/$ns/configmaps.yaml -n $ns
    done
  4. Restore persistent volume claim (PVC) definitions.
    If your application uses volume mounts, you must restore the corresponding PVC definitions. Ensure that you are in the correct namespace, then apply the PVC definition YAML file:
    kubectl apply -f pvc.yaml -n your-namespace
    Note: Do not restore PVCs marked to be skipped (example - ibm-bts-cnpg, user-home-pvc).
  5. Restore PVC content (NFS or local volume).
    PVC content includes the actual data that is stored in the volumes. You can restore this content manually or use the example script provided.
    NS=your-namespace
    BACKUP_DIR=backups-pvc-content
    TARGET_DIR=<target-storage-class-path>
    
    kubectl get pvc -n $NS --no-headers=true | while read line; do
      pvc=$(echo $line | awk '{print $1}')
      pv=$(echo $line | awk '{print $3}')
      [[ "$pvc" == ibm-bts-cnpg* ]] && continue
      src="$BACKUP_DIR/$pvc"
      dst="$TARGET_DIR/$NS-$pvc-$pv"
    
      if [ -d "$src" ]; then
        echo "Restoring $pvc"
        mkdir -p "$dst"
        cp -r "$src/." "$dst/"
      else
        echo "Missing backup content for $pvc"
      fi
    done
    
  6. Optional: Restore the Lightweight Directory Access Protocol (LDAP) server.
  7. Restore databases.
    Restore all required databases by using the appropriate back up images.
    • For PostgreSQL, use the pg_restore command to restore the data.
    • For Oracle DB, use the Recovery Manager tool (RMAN).
    • For Db2®with online backups, use the following commands to restore your databases.

    Use the following commands to restore Db2 databases:

    db2 restore database UMSDB from '/path/to/backup' taken at <timestamp> into UMSDB replace existing
    ...
    db2 rollforward db UMSDB to end of logs and stop
    
    Repeat for all required databases (for example, TOSDB, GCDDB, AEDB, ICNDB, BAWDB, DOCSDB, DOSDB).
  8. Restore JDBC drivers and custom files.
    • Copy JDBC drivers to the appropriate runtime paths.
    • Restore any custom fonts or configuration files that are used in component PVCs.
  9. Restore Elasticsearch or OpenSearch snapshots.
  10. Reapply the final IBM Business Automation Workflow CR.
    Update the CR with the correct hostname, domain, and database details. Set the following fields:
    shared_configuration:
      sc_content_initialization: false
      sc_content_verification: false
    

    Then apply the CR:

    kubectl apply -f icp4a-cr-backup.yaml -n your-namespace
  11. Restore ingress and network policies.
    If your platform is not Red Hat® OpenShift®, reapply ingress and network policies to enable communication between components. If your application includes custom network policies, ensure those are also restored.

    To generate ingress resources, run the following command.

    
    ./baw-deployment.sh -m generateIngress -n <your-namespace> --ingress rancher/tanzu
    

    To restore all ingress and network policies across namespaces, use the following script. Review and update parameters such as the client ID before you apply the changes.

    
    for ns in $(ls k8s-backup-network*/); do
      for kind in ingress networkpolicy; do
        kubectl apply -f k8s-backup-network*/$ns/${kind}.yaml -n $ns
      done
    done
    
    For Gateway API configurations, generate a new Gateway API template and customize it for your environment by running the following command:
    ./baw-deployment.sh -m generateGatewayAPITemplate -n <your namespace> --platform <gke|aks>

Results

Your Business Automation Workflow on containers environment is now restored.