> For the complete documentation index, see [llms.txt](https://docs.openiam.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openiam.com/solution-architecture/deployment/availability-and-recovery.md). # Availability and recovery What each topology survives, what it does not, and what a recoverable backup has to cover — including the one component holding state that a database restore will not bring back. ## What this is, and when you need it Availability and recovery are two different decisions that get discussed as one. Availability is what the deployment survives without anyone doing anything; recovery is what you can get back after something is genuinely lost, and how long it takes. This page separates them, states what each topology buys on the first, and sets out the scope a backup has to cover on the second. You need it when a recovery time objective and a recovery point objective have to be committed to, and when someone senior asks what happens if a data centre goes away. Both answers are better than most component lists suggest, and one of them has an exception that must not be missed. ## The decision | Decision | Options | What it costs | What it buys | | ----------------------------------------- | ------------------------------------------------------ | -------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | | Node redundancy | One node, or three | Three times the compute plus a load balancer | Survival of a node loss, and patching without an outage | | Database availability | Single instance, or a highly available service | The managed tier's cost, or a second database node | The only component holding state with no rebuild path stops being a single point of failure | | Infrastructure clustering | Broker, cache, search tier and graph clustered, or not | Each is a separate cluster with its own quorum | Node redundancy that actually holds when a node is lost | | Backup scope | Database only, or database plus secrets plus audit | Storage, and a quiesce window for a consistent set | The difference between a recoverable platform and a recovered database with no working platform around it | | Rebuild versus restore for derived stores | Restore the search indices and graph, or rebuild them | Rebuild costs time in the recovery window; restore costs backup complexity | A materially simpler backup, if you can afford the rebuild time | ## What each topology survives | Topology | Loss of one node | Loss of the database | Loss of the site | | ------------------------------------------------------ | ------------------------------------------------------------------ | ------------------------------------------------------------------- | -------------------------------------------------- | | Single instance, with or without platform services | Total outage | Total outage | Total outage | | Small HA | Survives, if every infrastructure component is genuinely clustered | Total outage unless the database service is itself highly available | Total outage | | Medium and large HA, with or without platform services | Survives, on both clusters | As above | Total outage unless the whole design is replicated | | Kubernetes, one worker | Total outage | Total outage | Total outage | | Kubernetes, three workers | Survives; workloads reschedule | Depends on the managed database's configuration | Total outage unless the cluster spans zones | Three points follow that are worth making explicitly in a design review. **Three OpenIAM nodes are not three of everything.** The broker, the cache, the search tier, the graph store and the secrets store are each clustered on their own terms. A three-node deployment with a single-instance broker survives the loss of two of its three nodes and none of the loss of the broker. Part 1, *The OpenIAM architecture* sets out which components are hard dependencies; the relational database, the broker and the cache are the three whose loss stops the platform outright. **"Managed" does not imply "highly available".** The shipped modules expose the high-availability setting on a managed database rather than assuming it, and one platform's managed cache module provisions a single node. Check the setting; do not infer availability from the word. **The shipped topology catalogue in this release is single-site.** All nine shapes are a single deployment in a single location. Cross-site resilience is achievable — the database service replicates, the images and manifests are portable, and everything else is rebuildable — but it is a design you construct, not a topology you select, and it should be presented that way. ## What a recoverable backup must cover Part 1, *The OpenIAM architecture* makes the point that settles most evaluator objections: **most of OpenIAM's data stores hold derived data that can be rebuilt.** The cache repopulates. The search indices are rebuilt from the database. The entitlement graph is rebuilt from the database, and the authorization service will rebuild it automatically if it finds it empty at startup. The broker holds work in flight, which is re-runnable rather than recoverable. That is right, and it is the strongest thing in OpenIAM's recovery story. It needs one correction and one elaboration before you turn it into a backup plan. ### The correction: the audit trail is not rebuildable **The audit trail lives in the search tier and has no source in the relational database.** The database schema that carries the word "audit" in its name holds the configuration for exporting audit events to an external destination, not the events themselves; the tables that once held audit records were removed several releases ago. Audit events are search documents and nothing else. So the accurate statement of the recovery scope is: **three things hold state that cannot be regenerated — the relational database, the secrets store, and the audit indices in the search tier.** Every other index and the entitlement graph can be rebuilt. That has a direct consequence for a design with a retention obligation. If you must be able to produce audit history for a regulator after a loss, a database backup will not do it. Either snapshot the search tier as well, or — better — export audit continuously to a security information platform and treat that platform as the system of record for audit history. The second is the better answer for most regulated estates anyway, because it puts audit somewhere that is not administered by the people being audited. ### The elaboration: the database is not one database OpenIAM's relational state is spread across several independently versioned schemas — the core schema plus separate schemas for workflow, stored scripts, audit export configuration, batch tasks, certification and policy-based access. Container deployments provision a further one for the privacy service. Each carries its own migration history and each is migrated independently. Two design consequences: **Nothing in OpenIAM coordinates a snapshot across them.** Consistency across the set is yours to arrange, and a serial hot dump of several independent databases is several different points in time. Whether that matters depends on your recovery point objective; if it does, the backup design needs a quiesce window or a replica taken at a known position. **A partial restore is worse than it looks.** Restoring the core schema alone leaves in-flight approvals orphaned, stored scripts referenced by managed systems missing, campaigns broken and batch history gone. The set is restored together or not at all. The Administration Guide's *Promote configuration between environments* gives the administrator's procedure for all of this, including the order and the verification. This page is only concerned with what your recovery design has to commit to. ### What else is on disk Beyond the databases, a recoverable deployment needs the configuration that is not in them: the property files, the workflow definitions, any scripts still resolved from disk, the secrets store's data volumes, and the deployment manifests. On a container deployment the manifests are normally in version control already, which is one of the better arguments for the GitOps path. ## Reading the recovery objectives back Putting those together gives a defensible pair of objectives rather than an aspirational one. **Recovery point** is set by the database backup frequency and, separately, by the audit export. If audit is exported continuously, its recovery point is near zero regardless of the database's. **Recovery time** is the database restore plus the secrets store plus **the rebuild of the search indices and the entitlement graph** — and the rebuild is the part people forget. On a large estate, reindexing and rebuilding the graph is not instant, and users should not be let back in before it completes, because until it does the consoles cannot find anything and entitlement answers are wrong. Either measure the rebuild time in a non-production environment and put the real number in the plan, or back the derived stores up so you can restore them instead. That is exactly the trade in the decision table above, and it is a genuine choice: simpler backups and a longer recovery, or the reverse. A backup tooling option ships for container deployments, licensed separately and off by default. It is worth knowing about if you take the restore-rather-than-rebuild path on Kubernetes. ## What we recommend **Design the three hard dependencies as one availability decision.** A highly available database in front of a single-node broker buys nothing. Where the topology says three nodes, make sure the broker, the cache and the search tier are genuinely clustered across them. **Take a managed database and enable its high-availability option.** This is the highest-value single decision on this page. It is the one component with no rebuild path, and handing its failover and point-in-time recovery to a platform removes more risk than any other change. **Export audit continuously to an external platform, and stop treating the search tier as a backup problem.** It resolves the one exception to the rebuildable story, it satisfies most retention obligations better than a snapshot would, and it lets you size the search tier for working set rather than for history. **Plan the rebuild into the recovery time, and measure it.** Do not let a recovery plan imply that the platform is usable the moment the database is back. **Do not put a maintenance-window requirement on the graph store or the search tier.** Both can be lost and rebuilt. Spend the availability budget on the database and the broker. The circumstance that changes this advice is a regulatory requirement for a specific recovery point on audit data held in a specific location. There, external export may not be permitted, and the search tier becomes a backup target with its own snapshot schedule — which should be stated as a cost of that requirement rather than absorbed silently. ## What OpenIAM does not do here * **Nothing coordinates a consistent snapshot across the schemas.** Cross-schema consistency is the backup design's responsibility. * **The audit trail is not recoverable from a database backup.** It exists only in the search tier unless it has been exported. * **This release ships no multi-site or active-active topology.** Every shape in the 2026.8.1 catalogue is single-site, so a cross-site design is one you construct rather than one you select. * **The platform does not queue work through an outage of the database, the broker or the cache.** Operations fail in front of the user; they are not deferred and replayed. * **A restored deployment is not immediately usable.** The search indices and the entitlement graph have to be rebuilt before users return. * **There is no shipped backup tooling for the packaged Linux distribution.** Backing up the databases, the secrets store and the configuration is done with your own tooling. ## Related * Part 1, *The OpenIAM architecture* — what stops, what degrades, and which components hold a system of record. * [Choosing a topology](/solution-architecture/deployment/choosing-a-topology.md) — the node-count decision that sets the availability floor. * [Platform support matrix](/solution-architecture/deployment/platform-support-matrix.md) — which components can be handed to a platform that operates their availability for you. * [Taking a new release](/solution-architecture/deployment/upgrade-strategy.md) — the planned outage, and why the backup before it is the only rollback you have. * *Promote configuration between environments* in the Administration Guide — the backup and restore procedure, and its order. * *Search indexes and the authorization graph* in the Administration Guide — the rebuild paths this page depends on. * *Audit export to a SIEM* in the Administration Guide — configuring continuous export of the one non-rebuildable store. * The [Installation Guide](/installation/installation.md) — clustering each component, and executing a restore. *Applies to OpenIAM 2026.8.1. Last reviewed 13 August 2026.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.openiam.com/solution-architecture/deployment/availability-and-recovery.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.