A disaster recovery (DR) environment for BPM / BAW is a second, complete cell (or CP4BA cluster) in another data centre that can take over the databases and the traffic. What is installed and configured:
- Databases are the heart: BPMDB, PDWDB, CMNDB (and case / content object stores) replicated to the DR site - Db2 HADR (sync / near-sync), Oracle Data Guard, PostgreSQL streaming replication, SQL Server AlwaysOn. The DR databases are standby; failover promotes them.
- The DR cell: WebSphere ND + BAW installed identically (same version and fix level, same topology), created with the same BPMConfig properties but pointing at the DR database hostnames - or, better, at DNS aliases that switch with the databases. Cell name, node names and LTPA keys should match production (export / import LTPA keys) so that sessions and SSO behave the same; the messaging engine's file store on shared or replicated storage, or database-backed.
- Configuration sync: every change on production (100Custom.xml, resources, certificates, installed snapshots, environment variables) must reach DR - either by replaying the deployment pipeline against DR (recommended: the pipeline installs every snapshot on both) or by periodic profile backups restored on DR. Installed snapshots live in the database, so they arrive with the replication; the managed asset caches and server-specific settings do not.
- Front door: the load balancer / GSLB switches the public hostname to the DR IHS pair; certificates present on both sides; LDAP reachable from DR (or a replica).
- Process Center: usually not DR-critical (rebuild from twx exports in Git), but a replicated repository database allows the same standby pattern.
- Testing: a DR drill twice a year - stop production, promote databases, start the DR cell, run the smoke tests, switch DNS, then fail back; measure RTO (typically 30-60 minutes with warm standby) and RPO (seconds with synchronous replication).
# warm standby: the DR cell exists and is stopped; failover runbook
1. confirm production is down / decision taken 2. promote DR databases (db2 takeover hadr on db BPMDB ...)
3. update DNS aliases for the databases (or nothing if aliases were used) 4. startManager / startNode / startServer on the DR cell
5. verify: login, Process Admin > Event Manager running, a test instance 6. switch the public GSLB / DNS to the DR web tier
On CP4BA: the same idea with a second OpenShift cluster, database replication as above, the CR and secrets in Git (GitOps) applied to the DR cluster, persistent volumes replicated or rebuilt (PFS re-index), and a global load balancer in front of both routers; active-passive is the supported model for the workflow engine (one engine per database at a time).
References