> 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/architecture/high-availability-and-disaster-recovery.md).

# High Availability & Disaster Recovery

## Multi-zone and multi-region redundancy

The system is designed with redundancy at both the availability zone and the regional level.

<figure><img src="/files/6NODckVlE2gCQIsfYy7F" alt="Multi-zone and multi-region redundancy"><figcaption><p><strong>Figure 5.</strong> Multi-zone and multi-region redundancy</p></figcaption></figure>

In lower environments, deployment is typically limited to a single region with multiple availability zones, giving zone-level fault tolerance. In production, high availability can be extended to a multi-region active–passive or standby setup, with each region containing two availability zones and nodes arranged in an active–passive pattern for intra-region failover.

Kubernetes health checks and liveness probes trigger automatic restarts. If a node fails, workloads are rescheduled onto healthy nodes automatically.

Depending on requirements, the secondary region can operate in:

<table><thead><tr><th width="200">Mode</th><th>Behaviour</th></tr></thead><tbody><tr><td><strong>Active–passive</strong></td><td>Passive backup with minimal or no running workloads until failover.</td></tr><tr><td><strong>Standby</strong></td><td>Warm standby with ongoing data replication, for faster recovery.</td></tr></tbody></table>

Failover between regions can be configured to occur **automatically**, minimising downtime, or handled **manually**, giving operators full control over when and how the switchover happens — depending on business, compliance, and operational requirements.

## High availability for Canton nodes

<figure><img src="/files/ZAqppOQ7ehjmqAbI9exZ" alt="High availability implementation for Canton nodes"><figcaption><p><strong>Figure 6.</strong> High availability implementation for Canton nodes</p></figcaption></figure>

Canton nodes are deployed in high availability mode using Kubernetes custom resources and a dedicated operator. The custom resources define the desired state and configuration of Canton components, allowing declarative management within Kubernetes. The operator continuously monitors these resources and automates lifecycle management tasks, including deployment, scaling, upgrades, and failover handling.

This approach simplifies complex HA deployments by encapsulating operational logic, ensuring consistency across the cluster, and improving resilience by automatically responding to node or zone failures.

***

## Disaster recovery

We maintain a comprehensive Disaster Recovery (DR) plan and procedures covering Canton nodes, node identity keys, Kubernetes infrastructure, and supporting AWS services - to ensure rapid restoration of Canton node services in the event of catastrophic failure, data corruption, or infrastructure outage. Disaster recovery plans and procedures are reviewed and tested at least annually.

The disaster recovery strategy for Canton ensures continuity of operations through multiple recovery mechanisms:

<table><thead><tr><th width="250">Mechanism</th><th>When it applies</th></tr></thead><tbody><tr><td><strong>Database backup restoration</strong></td><td>In the event of a failure, Canton nodes can be restored from regular database backups to recover state and resume operation with minimal data loss.</td></tr><tr><td><strong>Regional failover</strong></td><td>Depending on requirements, workloads can be failed over to a secondary region operating in either passive mode (cold standby with minimal resources until activated) or standby mode (warm standby with ongoing data replication for faster recovery).</td></tr><tr><td><strong>Fallback from node identity dumps</strong></td><td>If database backups are unavailable or corrupted, Canton nodes can be reinitialized from node identity dumps, ensuring the network can be reconstructed and operations resumed.</td></tr></tbody></table>

{% hint style="warning" %}
Identity dumps are the last line of defence for a validator's identity. Download one for every validator and store it securely outside the cluster. See [Identity & Backups](/catalyx-blockchain-manager/canton-network/version-2.0/validator-management/identity-and-backups.md).
{% endhint %}

{% hint style="info" %}
Recovery time and recovery point objectives are defined per engagement in the applicable service agreement. Contact IntellectEU for the objectives that apply to your deployment.<br>
{% 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/architecture/high-availability-and-disaster-recovery.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.