Backup & recovery
There are two very different things called "backup" here. Keep them separate.
Operational backup (the database file)
Backing up the server is backing up the SQLite file(s), copy open-secret.db (and audit.db) consistently, e.g. with SQLite's online backup or a filesystem snapshot while the process is quiesced. This protects against disk loss. It does not let you read anyone's vault: the DB is ciphertext and public keys.
Vault recovery (getting a user's secrets back)
This is the one that matters to users, and it's constrained by the core invariant: the server can't recover a vault because it never had the keys. Recovery comes from one of three independent factors, a user needs only one. The first two need no operator involvement at all; the user-facing recovery guide covers them in full.
The factors below, especially the user's downloaded backup file, are the standalone deployment's recovery story. An IDP-mode deployment has no per-device backup file: the identity is escrowed server-side and unlocked via SSO, so recovery there is "sign in on another device" + the operator backup key, and losing IdP access (deprovisioning) is a lockout. The operator backup key below is mode-agnostic and is the recommended safety net for IDP deployments too.
The user's backup file
The primary, operator-independent path. At first setup the web app has the user download an encrypted file containing their device keypairs, protected by a passphrase only they know, the server never sees it. With the file and passphrase, they restore on a fresh install and their keys decrypt the ciphertext you're already storing. This works even if every device is lost.
Another device the user controls
As long as the user has one paired device that can unlock, they can pair more and keep going.
Operator backup key (optional)
The last-resort path, for a user who has lost every device and their backup file. The operator can configure a backup keypair:
Operator generates a backup keypair offline
An ML-KEM-768 keypair. The private key stays offline, never on the server. Only the public key is configured on the instance.
Users opt in
With backup enabled on the instance, a user can opt their entries in. From then on, each entry version is sealed a second time to the backup public key, alongside the per-device shares.
Recovery uses the offline private key
If a user loses every device, the operator can decrypt that user's backup-sealed ciphertext with the offline private key and help them re-establish access.
Even without an operator backup key, users are not one lost device away from disaster, their own backup file (set up at first run) recovers them independently of you. Operator backup exists for the user who has lost both every device and their backup file. A vault is only truly gone when every factor is lost at once: all devices, the backup file/passphrase, and operator backup.
Operating the backup key responsibly
The backup private key can decrypt opted-in users' vaults, so it is the single most sensitive secret in an open-secret deployment. Treat it like a root key: keep it offline, control access tightly, and understand that its existence shifts your threat model, it's the one thing whose compromise would expose opted-in plaintext. Operators who don't want that responsibility simply don't configure it, and recovery is device-only.