Disaster recovery and backup

The Virtual Signer writes sensitive data such as key shares to the disk where it runs, and other sensitive data are kept in files that must be accessible by the app at all times, even after system restarts. These files are encrypted, but it is important to persist these files in between container restarts, so that the data is not deleted.

Storage backends

The Virtual Signer supports multiple storage backends for persisting encrypted keys and shares:

Backend	Configuration	Use Case
Filesystem	(default)	Self-hosted deployments
AWS S3	`IOSIGN_SIGNER_BROKER_STORAGE_BUCKET_URL=s3://bucket?region=us-east-1`	AWS deployments
Azure Blob	`IOSIGN_SIGNER_BROKER_STORAGE_BUCKET_URL=azblob://container`	Azure deployments

Data organisation

Data is organised into subdirectories:

Data Type	Path
Private Keys	`private-keys/`
Private Shares	`private-shares/`
Key Chain Data	`private-keychain-general/`
Disaster Recovery Files	`private-dr/`

The root of this layout is set by IOSIGN_SIGNER_BROKER_STORAGE_BASE_PATH and defaults to /var/vsigner.

private-dr/ holds the encrypted .dr files the signer writes at every key generation and reshare. These are protected by their own ML-KEM-768 envelope and are the input to an offline vault recovery. They are never deleted, so this directory grows by two files per operation and should be included in your volume backups. See Virtual Signer disaster recovery.

Azure SKR encryption

For Azure deployments, Secure Key Release (SKR) provides hardware-attested encryption of stored data using keys released only to verified confidential containers.

Recovery bundles

Backing up the storage volume protects the running signer. Recovering a vault offline uses a separate artifact: a recovery bundle exported with signerctl share backup, which collects the signer's .dr files together with an integrity manifest into a single ZIP.

docker compose exec vs-broker signerctl share backup

Bundles are written to the directory set by IOSIGN_SIGNER_BROKER_BACKUP_BASE_PATH. Export one after the signer joins a new vault, after every reshare, and on a regular schedule — a bundle taken before the most recent reshare may not hold enough current shares to recover the vault.

A bundle contains .dr files only. It is not a complete signer backup and there is no path that restores a running Virtual Signer from one. The two mechanisms are complementary: volume backups restore service, bundles recover vaults. Full details are in Virtual Signer disaster recovery.

❗️
Important: disaster recovery
Plan an alternative signing set whose combined weight can meet the vault threshold if a Virtual Signer is unavailable. It can use Mobile Signers, independent Virtual Signers, or both. Test that path and retain the material required for offline recovery.
Backing up this volume is not sufficient on its own. The .dr files it contains can only be decrypted with the ML-KEM-768 private key generated before the signer was first deployed, which is held offline by your Product Owner (Business User). Confirm that key is retrievable as part of your backup strategy.
Perform drills and air-gapped Disaster recovery process tests with your mobile signers to make sure that your team are familiar with the process of recovering access to a vault for if in the unlikely case this is ever needed, they are able to do it.