Skip to content
IT Canvass
Installation · Lesson

Backup

Quick answer

Back up the database on a schedule and keep IdentityIQ configuration (XML objects) exported to source control so you can restore both state and setup.

Key takeaways

  • Prerequisites for Backup
  • Step-by-step install path
  • Common pitfalls and fixes
  • Verification after install

Backing up IdentityIQ means two complementary things: backing up the database (which holds all state) and keeping the configuration (XML objects) in source control (so the setup is reproducible). Together they let you restore both what the system knew and how it was built. Because all runtime state lives in the database, database backups are non-negotiable.

What to back up, and why

  • The database, identities, accounts, roles, policies, certifications and audit history. This is the irreplaceable state.
  • Configuration as XML, roles, rules, workflows, application definitions, exported and version-controlled, so the application layer can be rebuilt exactly.
  • Secrets and certificates needed to reconnect to sources and targets.

Step by step

  • 1. Schedule regular database backups at a frequency that meets your recovery-point objective.
  • 2. Export configuration XML and commit it to source control as part of your release process.
  • 3. Store backups off-site and encrypted, protecting confidentiality and surviving a site loss.
  • 4. Document each backup's contents and retention.
  • 5. Test restores periodically, a backup you have never restored is only a hopeful assumption.

Backup and the recovery-point objective

Backup frequency is driven by your RPO, how much data loss is acceptable. A one-hour RPO means backups (or replication) no more than an hour behind. Align the schedule with the business's agreed tolerance rather than a default.

Verify

Confirm backups complete successfully on schedule, are stored securely off-site, and, crucially, can actually be restored in a test.

Common pitfalls

  • Backing up the database but not configuration/secrets, leaving you unable to fully rebuild.
  • Never testing a restore.
  • Backups stored only on-site, lost with the site.

Want to learn this properly?

Our live, instructor-led SailPoint Training covers this hands-on, with real projects and a certification path.

Check your understanding

  1. What are the prerequisites for Backup?

    • A. The application and app-server logs, which usually point to database, Java or permission issues.
    • B. Confirm the app server starts, the schema is present, and login works.
    • C. A supported Java runtime, a reachable database, and the IdentityIQ files with correct permissions.
    Show answer

    C. A supported Java runtime, a reachable database, and the IdentityIQ files with correct permissions.

    A supported Java runtime, a reachable database, and the IdentityIQ files with correct permissions.

  2. How do you verify the install?

    • A. The application and app-server logs, which usually point to database, Java or permission issues.
    • B. Confirm the app server starts, the schema is present, and login works.
    • C. A supported Java runtime, a reachable database, and the IdentityIQ files with correct permissions.
    Show answer

    B. Confirm the app server starts, the schema is present, and login works.

    Confirm the app server starts, the schema is present, and login works.

  3. Where do you look first on failure?

    • A. A supported Java runtime, a reachable database, and the IdentityIQ files with correct permissions.
    • B. Confirm the app server starts, the schema is present, and login works.
    • C. The application and app-server logs, which usually point to database, Java or permission issues.
    Show answer

    C. The application and app-server logs, which usually point to database, Java or permission issues.

    The application and app-server logs, which usually point to database, Java or permission issues.

Frequently asked questions

What does the term Backup refer to in SailPoint?

Backing up IdentityIQ means two complementary things: backing up the database (which holds all state) and keeping the configuration (XML objects) in source control (so the setup is reproducible). Together they let you restore both what the system knew and how it was built.

Where do rules or workflows touch Backup?

The database, identities, accounts, roles, policies, certifications and audit history. This is the irreplaceable state. Configuration as XML, roles, rules, workflows, application definitions, exported and version-controlled, so the application layer can be rebuilt exactly.

What is the practical takeaway on Backup?

Backup frequency is driven by your RPO, how much data loss is acceptable.

What tends to go wrong with Backup?

Backing up the database but not configuration/secrets, leaving you unable to fully rebuild. Never testing a restore. Backups stored only on-site, lost with the site.
CallWhatsAppEnquire