> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dfns.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Disaster recovery

> Backup and recovery options across all DFNS deployment models, including signer failover, Layer 4 independent recovery, and manual key backup via key export.

export const SupportLink = ({children}) => {
  const url = "https://support.dfns.co";
  return <a href={url} target="_blank">{children || url}</a>;
};

Backup and disaster recovery responsibilities depend on your [deployment model](/advanced/deployment-models). With fully-managed DFNS Cloud (SaaS), DFNS operates the signers and handles all backup and disaster recovery for you. With hybrid or on-premise deployments, you operate one or more signers yourself and are responsible for backing up and recovering the components in your environment. This page covers what to protect and how to recover in each case.

For MPC signers, recovery is layered: standard database backups (Layers 1 and 2), an encrypted key-share backup you can rebuild a signer from (Layer 3), and a fully independent backup encrypted with your own key (Layer 4). You can also export a wallet's key on demand as a manual backup. Each is covered below, alongside HSM backups.

## MPC signer backups

When hosting MPC signers, the following assets must be backed up:

| Asset | Impact of loss | Backup approach |
| - | - | - |
| **Core Keys Pack** | Encrypts every key share at rest. If lost, all key shares become permanently unusable, meaning loss of all wallets and assets. | Store in a secrets manager with backup/replication enabled. |
| **Key share databases** | Loss of a database means losing that signer's key shares created since the last backup. | Standard database backup procedures (pg\_dump, continuous archiving, replicas). |
| **mTLS certificates and private keys** | Required for signer authentication to DFNS APIs and delivery server. | Store in a vault or secrets manager. |
| **Signer configuration** | Needed to redeploy signers. | Store in version control or a configuration management system. |

### Key shares backup layers

MPC key shares are protected at four layers. Recover in order: start with Layer 1, then each following layer is the fallback when the previous one is unavailable.

| Layer | What it is | When you use it |
| - | - | - |
| **Layer 1** | Database replication and point-in-time recovery (PITR) | First-line recovery of a signer's key-share database, to any point in time. |
| **Layer 2** | Database snapshots | Restore the database from a periodic snapshot when PITR is unavailable. |
| **Layer 3** | An encrypted copy of every key share in an S3 bucket, written at key creation | Rebuild a signer when its database and Layers 1 and 2 are gone. |
| **Layer 4** | Key shares re-encrypted with your own key, in a bucket you own | Recover independently of DFNS. |

Layers 1 and 2 are standard database backups you configure. Layers 3 and 4 are key-share backups the signer writes automatically.

### Recovery scenarios

| Scenario | Recovery |
| - | - |
| **Core Keys Pack loss** | **Unrecoverable without Layer 4.** Layers 1 to 3 all depend on the Core Keys Pack. With [Layer 4](#layer-4-disaster-recovery), you can recover independently. |
| **Database loss** | Restore from a database backup (Layer 1 or 2). If the database and its backups are gone, rebuild the signer from the [Layer 3](#layer-3-disaster-recovery) key-share backup. [Layer 4](#layer-4-disaster-recovery) additionally lets you recover independently of DFNS. |
| **Single signer failure** | Deploy a replacement signer, restore its configuration, certificates, and database access. If the threshold is still met by remaining signers, signing continues uninterrupted during recovery. |
| **Too many signers lost to meet the threshold** | If you lose more signers than your scheme tolerates (for example, more than 2 in a 3-of-5 setup), signing is unavailable until enough signers are restored to meet the threshold again. |

<Warning>
  Losing the Core Keys Pack without Layer 4 backup set up means losing access to all wallets and the assets they hold.
</Warning>

### Layer 3 disaster recovery

Every time a signer creates a key share, it writes the same encrypted bytes to a write-only S3 bucket, in addition to its database. Layer 3 is that copy: identical ciphertext to the database, encrypted with the signer's own key.

<Frame>
  ```mermaid theme={null}
  flowchart LR
      S[Signer] --> K[KMS\nSigner Key Pack]
      K -->|encrypted key share| DB[(Database)]
      K -->|same encrypted copy| B[(Layer 3 backup bucket)]
  ```
</Frame>

Use it to rebuild a signer's key-share database when the database and its standard backups (Layers 1 and 2) are gone. Recovery needs the signer's Core Keys Pack to be intact, so Layer 3 is not independent of DFNS. If the Core Keys Pack itself is lost, use Layer 4.

For the recovery procedure, contact our <SupportLink>Support Team</SupportLink>.

### Layer 4 disaster recovery

Layer 4 works like Layer 3 — each signer writes its encrypted share to a write-only S3 bucket you own, at key creation — except the share is encrypted with your own Ed25519 public key, not the signer's. DFNS never has your private key, so only you can decrypt these backups.

<Frame>
  ```mermaid theme={null}
  flowchart LR
      S[Signer] --> K[KMS\nSigner Key Pack]
      S --> P[KMS\nL4 Backup Key]
      K -->|encrypted key share| DB[(Database)]
      K -->|same encrypted copy| B1[(Layer 3 backup bucket)]
      P -->|re-encrypted with your key| B2[(Layer 4 backup bucket)]
  ```
</Frame>

That makes Layer 4 a fully independent recovery path: you can reconstruct your keys from only your private key and the backup files, even if DFNS is unavailable or the signer's Core Keys Pack is lost. It requires a dedicated MPC cluster and works with any [MPC deployment option](/advanced/deployment-models/mpc); without one, use [manual key backup](#manual-key-backup-key-export) instead.

To enable Layer 4, or for the setup or recovery procedure, contact our <SupportLink>Support Team</SupportLink>.

### Manual key backup (key export)

You can export a copy of any MPC wallet's key on demand, giving you a backup you hold outside DFNS. It is the fallback available to most customers, whatever their deployment model. As with Layer 4, DFNS never handles a plaintext key ([how export works](/advanced/key-import-and-export#export)).

<Warning>
  A reconstituted key is a full, standalone private key — a single point of failure. Anyone who obtains it controls the wallet and its assets, and DFNS cannot guarantee the security of transactions signed with it. Once it leaves DFNS, its security is entirely your responsibility: storage, encryption at rest and in transit, access controls, usage restrictions, and protection against theft or misuse.
</Warning>

Manual export is a point-in-time backup: you can only recover keys you exported before a loss. To have every key covered automatically, use Layer 4. Treat the exported key as break-glass: store it offline with tightly restricted access.

For the step-by-step export and recovery procedure, including an offline signing test, see the [export keys guide](/guides/developers/export-keys).

## HSM backups

When using an HSM integration, the following assets must be backed up:

| Asset | Impact of loss | Backup approach |
| - | - | - |
| **HSM master key** | All wrapped keys become permanently unusable. Loss means loss of all wallets and assets. | Use your HSM vendor's key backup mechanism (e.g. Thales Luna Backup HSM, cloning domain). Store backups in a physically separate, secure location. |
| **Wrapped-key database** | Loss means losing all wallets and assets created since the last backup. | Standard database backup procedures (pg\_dump, continuous archiving, replicas). Data is encrypted at rest but should still be treated as sensitive. |
| **mTLS certificates and private keys** | Required for HSM Driver authentication to DFNS APIs. | Store in a vault or secrets manager. The intermediate certificate private key is especially critical. |
| **HSM Driver configuration** | Needed to redeploy the Driver. | Store in version control or a configuration management system. |

### Recovery scenarios

| Scenario | Recovery |
| - | - |
| **HSM Driver host failure** | Deploy a new host, install the HSM client library and HSM Driver, restore configuration and mTLS certificates. The Driver resumes signing automatically. |
| **HSM failure** | Provision a replacement HSM with the same master key (restored from backup). The HSM Driver resumes without further changes. |
| **Database loss** | Restore from backup. Wallets created after the last backup, and the assets they hold, are lost. |
| **Master key loss** | **Unrecoverable.** All wallet keys encrypted with that master key are permanently inaccessible. |

<Warning>
  Losing the HSM master key means losing access to all wallets and the assets they hold. Back it up immediately after generation.
</Warning>

## Proving you can recover

You can demonstrate — to yourself, an auditor, or a regulator — that your backups actually reconstitute working keys, without moving any real assets. Run this as a periodic **recovery drill**. The proof comes at two levels:

1. **Cryptographic verification (always performed).** When you reconstruct keys during [Layer 4 recovery](/advanced/deployment-models/L4-disaster-recovery) or [manual key export](/guides/developers/export-keys), the recovery tool reassembles each private key from its shares and checks it against the known public key. A match proves the backup reconstitutes the exact key that controls your wallet's address.
2. **End-to-end signing test (optional, strongest).** For proof that a recovered key can authorize a transaction, sign a **zero-value transaction on a testnet** with the recovered key and broadcast it. A recovered key controls the same address on every chain, so a successful testnet signature demonstrates control of the real address without touching mainnet funds. Signing stays on your offline computer; only the signed transaction goes online. See [Verify a recovered key](/advanced/deployment-models/L4-disaster-recovery#verify-a-recovered-key) (Layer 4) or the offline signing test in the [export keys guide](/guides/developers/export-keys).

<Tip>
  Run the drill on a schedule (for example quarterly) and whenever your recovery setup changes — a new recovery key, a new bucket, or a deployment migration — and keep a record of each run (date, keys tested, outcome) as audit evidence.
</Tip>

Because the drill runs on a testnet and the private key never goes online, you can prove that the recovery process is functional at any time without exposing key material or moving assets.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.