Backups in Ripple Custody have two distinct scopes:
- Platform state backups protect operational state such as PostgreSQL data, configuration, request state, events, and recovery metadata.
- Vault and KMS backups protect the key material or key shares required to recover signing capability.
Do not treat one scope as a substitute for the other. Restore planning must account for both platform state and vault key material.
| Backup scope | What it protects | Where to go |
|---|---|---|
| PostgreSQL database | Platform source of truth, including state used by accounts, transactions, requests, and events. | Database planning, Resilience planning |
| Anti-rewind file and state review authority process | State recovery and rollback protection. | Recover anti-rewind file, Register a key |
| HSM-backed vault key material | HSM-protected master seed or wrapped seed material, depending on the KMS integration. | The relevant KMS integration guide under Integrate a KMS |
| MPC-backed vault key material | Customer-held encrypted MPC backups and validation artifacts. | MPC backups |
| Cold vault operation payloads | Offline cold-vault operation exchange files and signing workflow material. | Cold vaults, Cold vault API operations, Cold vault UI operations |
For vault-level key strategy context, see Vaults.
Use this section to route operators to the correct backup procedure. The exact runbook depends on the deployment model and KMS.
Back up PostgreSQL and platform state according to your deployment architecture. For on-premises deployments, your operations team owns database backup, replication, retention, and restore testing. For Ripple-managed environments, coordinate with your Ripple account team.
Review:
For HSM-backed vaults, follow the backup procedure for the specific HSM platform and deployment model. HSM backup requirements vary by vendor and by whether the deployment uses physical HSMs, cloud HSMs, or wrapped key material.
Start with the relevant KMS guide under Integrate a KMS.
For MPC-backed vaults, use the customer-held MPC backup workflow:
- Generate the backup encryption and decryption keys.
- Associate the backup encryption key with the vault.
- Submit the
v0_CreateBackupintent. - Check backup status.
- Download the trusted entity backup payload.
- Acknowledge receipt with
v0_AcknowledgeBackup. - Verify the downloaded backup.
For the full procedure, see MPC backups.
Use your database restore runbook together with the anti-rewind file recovery process. For source material, see:
For HSM-backed vaults, use the restore process for the specific KMS and vendor deployment. Requirements vary by HSM provider, cluster model, wrapping-key approach, and whether the HSM backup is managed by the cloud provider or by the customer.
Start with the relevant guide under Integrate a KMS.
For MPC-backed vaults, use the MPC backup material and the exit strategy process described in MPC backups.
Validate backups before you rely on them in production.
| Backup type | Validation activity |
|---|---|
| PostgreSQL and platform state | Run restore drills in a non-production environment and confirm that requests, events, accounts, and configuration state are usable. |
| Anti-rewind file recovery | Exercise the anti-rewind file recovery process and verify the state review authority key path. |
| HSM-backed vault material | Test the vendor-specific HSM restore procedure according to your KMS runbook. |
| MPC-backed vault material | Run the backup verification script against the downloaded backup JSON. |
For MPC-specific validation details, see Verify the backup.
| Need | Procedure |
|---|---|
| Register or rotate the state review authority key | Register the state review authority public key |
| Recover the anti-rewind file | Recover your anti-rewind file |
| Recover cold vault operations after workstation loss | Recover a cold vault |