A CP4BA workflow deployment is fully described by four things; back them up together:
- Databases - BAW's BPMDB / PDW (and CMNDB where present), Workflow Center's repository database, the case / content databases (GCD, object stores), the Zen / IAM metastore (the platform's own database, covered by the foundational services' backup procedure), BAI's storage. Use the database's online backup with logs as before - the databases usually run outside the cluster (Db2 / PostgreSQL / Oracle) or in operators with their own backup CRs.
- Persistent volumes - PFS / OpenSearch indexes (rebuildable but slow), file storage areas of Content, JMS message stores, logs are not needed. Storage snapshots (CSI) or Velero with restic.
- Kubernetes objects - the CR (ICP4ACluster), every secret it references (database credentials, LDAP bind, custom XML, certificates), ConfigMaps, the operator subscription; keep them in Git (sealed / encrypted secrets) - this is the equivalent of the profile backup.
- Design-time sources - twx exports of every snapshot (Operations REST or Workflow Center export) in Git, like before.
# minimum object backup (run from a pipeline; secrets encrypted at rest in Git)
oc get icp4acluster icp4adeploy -n cp4ba -o yaml > backup/cr.yaml
for s in $(oc get icp4acluster icp4adeploy -n cp4ba -o json | jq -r '.. | .secret_name? // empty, .lombardi_custom_xml_secret_name? // empty' | sort -u); do
oc get secret $s -n cp4ba -o yaml > backup/secret-$s.yaml; done
oc get configmap -n cp4ba -l app.kubernetes.io/managed-by=ibm-cp4a-operator -o yaml > backup/configmaps.yaml
Restore = install the same operator version in the new cluster, recreate the secrets, point the CR at the restored databases and volumes, apply the CR and let the operator rebuild the pods; PFS re-indexes if its volumes were not restored. Test it: the CP4BA documentation has a dedicated backup-and-restore procedure per version, and it changes between versions - follow the one for yours.
References