SailPoint Restore
Restoring IdentityIQ from backup after data loss or a failed change.
Restore the database from a known-good backup and re-import any configuration, then verify schema version, connectivity and login.
- Prerequisites for Restore
- Step-by-step install path
- Common pitfalls and fixes
- Verification after install
Restore is the other half of backup, and the half that is too often untested until it is needed. Restoring IdentityIQ means bringing back the database from a known-good backup, re-applying configuration and secrets as needed, and validating the environment before returning it to service. A restore procedure that has been rehearsed is the difference between a controlled recovery and a crisis.
When you restore
Restore is invoked after data loss, corruption, a failed change or a disaster. The scope varies, from rolling back a single bad change to rebuilding an entire environment, but the disciplined steps are the same.
Step by step
- 1. Identify a known-good backup that meets your recovery point.
- 2. Restore the database from that backup (or fail over to a replica).
- 3. Re-import configuration from source control if the config layer also needs rebuilding.
- 4. Restore secrets and certificates so connectors can reconnect.
- 5. Verify schema version and connectivity, confirm the schema matches the application and the database is reachable.
- 6. Validate, log in, run a test aggregation, and confirm core functions before returning to production.
Rehearsing the restore
The single most valuable practice is to actually perform a restore in a test environment on a schedule. This proves the backups are valid, uncovers missing pieces (a forgotten secret, an out-of-date config export), and turns recovery from an untested hope into a known quantity. Pair this with your disaster-recovery runbook.
Verify
After restore, confirm the schema version, successful login, working connectors via a test aggregation, and that recent expected data is present up to the recovery point.
Common pitfalls
- Restoring the database but lacking secrets/certificates to reconnect.
- Schema/application version mismatch after restore.
- First real restore attempted during an actual outage, never rehearsed.