> For the complete documentation index, see [llms.txt](https://docs.catalyx.solutions/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.catalyx.solutions/catalyx-blockchain-manager/canton-network/version-2.0/validator-management/identity-and-backups.md).

# Identity & Backups

A validator has two kinds of state, and they need different protection.

<table><thead><tr><th width="230">State</th><th width="230">Where it lives</th><th>Protected by</th></tr></thead><tbody><tr><td><strong>Node identity</strong> — the cryptographic identity the network knows this participant by</td><td>The participant's key store, or your KMS</td><td>An <strong>identity dump</strong></td></tr><tr><td><strong>Ledger state</strong> — contracts, transaction history, topology</td><td>The participant and validator PostgreSQL databases</td><td><strong>Database backups</strong></td></tr></tbody></table>

You need both. A database backup without the identity cannot be restored onto a node the network recognises; an identity without a database gives you a recognised node with no history.

***

## Identity dumps

An identity dump exports the participant's identity so the node can be reconstructed if its database is lost beyond recovery.

### Downloading one

Open the validator's [Identity](/catalyx-blockchain-manager/canton-network/version-2.0/console-guide-canton/validators/identity-and-endpoints.md) tab and click **Identity Dump**. The file downloads as `<validator-name>-identities.json`.

{% hint style="danger" %}
**An identity dump is equivalent to the validator's private key material.** Anyone holding it can reconstruct your node's identity on the network.

* Store it in a secrets manager or an encrypted vault — never in a shared drive, a ticket, a wiki page, or a chat message.
* Never commit it to a repository.
* Transfer it only over encrypted channels.
* Keep access to it as tightly held as your production credentials.

There is no confirmation dialog. Clicking the button downloads the file immediately.
{% endhint %}

### When to take one

* **After onboarding**, once the validator is initialised and connected. This is the dump you cannot do without.
* **Before any migration or major upgrade.**
* **Periodically**, on whatever cadence your change-management process requires.

{% hint style="info" %}
An identity dump reflects the identity at the moment it was taken. It does not need to be refreshed as ledger state changes — but retake it if the node's identity or keys change.
{% endhint %}

***

## Database backups

Each validator has at least two databases, and more when optional components are enabled:

| Database                         | Contains                                                                                                                                                                      |
| -------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Participant                      | The ledger — contracts, transaction history, topology state, and the key store unless a KMS holds the keys                                                                    |
| Validator app                    | Validator app state, including wallet and onboarding data                                                                                                                     |
| PQS                              | A rebuildable projection of the ledger. See [Participant Query Store](/catalyx-blockchain-manager/canton-network/version-2.0/validator-management/participant-query-store.md) |
| Wallet Gateway store and signing | Wallet Gateway state. See [Wallet Gateway](/catalyx-blockchain-manager/canton-network/version-2.0/validator-management/wallet-gateway.md)                                     |

Back these up with your standard PostgreSQL tooling — managed service snapshots, or your own `pg_basebackup` and WAL archiving. CAT-BM does not manage database backups, deliberately: this is the layer where your organisation's existing backup, retention, and testing policy should apply.

{% hint style="warning" %}
**Deleting a `Validator` resource does not delete its databases.** That is what makes it possible to recreate a validator against its existing state — but it also means decommissioning is a two-step job: delete the resource, then drop the databases.
{% endhint %}

***

## Recovery paths

In order of preference.

{% stepper %}
{% step %}
**Restore from a database backup**

The normal path. Restore the participant and validator databases, and the node resumes with the state in the backup. Some transaction loss is possible, bounded by your backup frequency.
{% endstep %}

{% step %}
**Fail over to a standby region**

Where a multi-region deployment is configured, workloads move to the secondary region. See [High Availability & Disaster Recovery](/catalyx-blockchain-manager/canton-network/version-2.0/architecture/high-availability-and-disaster-recovery.md).
{% endstep %}

{% step %}
**Reinitialise from an identity dump**

The last resort, for when database backups are unavailable or corrupted. The node is recreated with its original network identity, but without its ledger history. Coordinate this with IntellectEU support and with your sponsoring Super Validator.
{% endstep %}
{% endstepper %}

{% hint style="info" %}
Recovery objectives are defined per engagement in the applicable service agreement. Contact IntellectEU for the objectives that apply to your deployment.
{% endhint %}

***

## What else to keep alongside the backups

A restore also needs the surrounding configuration. Keep these under version control or in your secrets manager:

* The **`Validator` resource** for each validator — ideally in Git, which is the main argument for managing them through GitOps.
* The **Helm values** used to install the platform.
* The **database credentials secret** for each validator.
* The **identity provider configuration** — realm, clients, and scopes. With managed authentication the operator can recreate the clients, but the realm and the admin client are yours.
* For an external identity provider, the **backend client secret**.
* For KMS-backed validators, access to the **key vault** itself. Without it the keys are unrecoverable, whatever else you have.

{% hint style="danger" %}
If you use a KMS, the KMS becomes part of your recovery path. Losing access to the key vault is unrecoverable — an identity dump will not substitute for keys the node no longer has permission to use. Make sure your KMS has its own backup, replication, and access-recovery plan.
{% endhint %}


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.catalyx.solutions/catalyx-blockchain-manager/canton-network/version-2.0/validator-management/identity-and-backups.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.