Disaster recovery
Recovering IdentityIQ after a major failure: backups, replication, RPO/RTO and a tested runbook.
Disaster recovery relies on database backups/replication to a secondary site, defined RPO/RTO targets, and a regularly tested recovery runbook.
- Back up and replicate the database
- Define RPO (data loss) and RTO (downtime) targets
- Maintain a standby environment
- Test the recovery runbook regularly
Disaster recovery is the plan for bringing IdentityIQ back after the loss of an entire site or a catastrophic failure, as opposed to high availability, which handles the failure of individual components. Because all of IdentityIQ's state lives in its database, DR is fundamentally about protecting and restoring that database, backed by a documented, tested recovery procedure and clear targets for how much data loss and downtime the business will tolerate.
What DR must protect
- The database, the authoritative state: identities, accounts, roles, policies, certifications and audit history.
- Configuration, ideally already captured as XML in source control, so the application layer can be rebuilt repeatably.
- Integration secrets and certificates, needed to reconnect to source and target systems after recovery.
RPO and RTO: the two numbers that drive everything
Two targets shape the entire DR design:
- RPO (Recovery Point Objective): how much data loss is acceptable, expressed as time. An RPO of one hour means backups or replication must be no more than an hour behind.
- RTO (Recovery Time Objective): how quickly the service must be restored after a disaster.
Tight RPO/RTO targets justify continuous replication to a standby site; looser targets may be met with regular backups and a rebuild. Agree these numbers with the business first, because they determine cost.
Backup and replication strategy
Practically, DR combines:
- Regular, tested database backups, stored off-site and encrypted.
- For demanding RPOs, replication of the database to a secondary site or region.
- Configuration kept in source control so the application tier is reproducible.
- A documented inventory of connectors, credentials and certificates required to reconnect.
The runbook, and testing it
A DR plan is only real if the recovery steps are written down and rehearsed. The runbook should cover: restore or fail over the database, stand up the application nodes, reconcile configuration, restore secrets and certificates, verify schema version and connectivity, and validate with a test aggregation before returning to service. An untested plan usually fails at the exact moment you need it, so schedule DR exercises rather than trusting the document.
Common pitfalls
- Backing up the database but not the configuration and secrets, leaving you unable to reconnect.
- RPO/RTO assumed rather than agreed with the business.
- A runbook that has never been executed end to end.