Identity Dumps & Database Backups

Identity dumps, database backups, and what each one recovers.

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

State	Where it lives	Protected by
Node identity — the cryptographic identity the network knows this participant by	The participant's key store, or your KMS	An identity dump
Ledger state — contracts, transaction history, topology	The participant and validator PostgreSQL databases	Database backups

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 an identity dump

Open the validator's Identity tab and click Identity Dump. The file downloads as <validator-name>-identities.json.

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.

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.

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.

---

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
Wallet Gateway store and signing	Wallet Gateway state. See Wallet Gateway

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.

For more details on database backups, please refer the Canton guidelines:

Canton Node Backup and Restore - Canton Network DocsCanton Network Docs

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.

---

Recovery paths

In order of preference.

1

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.

2

Fail over to a standby region

Where a multi-region deployment is configured, workloads move to the secondary region. See Canton's own documentation for high-availability and disaster-recovery guidance for validators.

3

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.

Recovery objectives are defined per engagement in the applicable service agreement. Contact IntellectEU for the objectives that apply to your deployment.

---

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.

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.