Backup and encryption

The appliance’s Settings Admin tab provides three related actions for moving data into or out of the appliance: a full encrypted Backup, a Restore from that backup, and a PII-redacted Export for sharing outside the appliance.

Backup

Downloads a complete, encrypted copy of the appliance’s storage as a single file. It’s the appliance’s disaster-recovery copy, ready to restore onto the same appliance if something goes wrong.

Take a Backup before any risky change (an upgrade, a bulk migration, a restore rehearsal) and on whatever schedule your recovery objectives call for. Because nothing is redacted, treat the file as sensitive: store it securely and never share it outside your organization; use Export below for that instead.

Configuration, secrets, private keys, credentials, and any PII in stored records are all included. logs and system_metrics are excluded, since both are ephemeral and regenerate at runtime rather than being part of the appliance’s durable state. The file is AES-256-GCM encrypted.

Restore

Uploads a previously downloaded backup file and replaces the appliance’s storage with it. This is how you actually use a Backup: turning that stored copy back into a running appliance after data loss, a bad change, or a planned rehearsal.

Only restore onto the same appliance the backup came from; a cross-domain restore is rejected outright (see below). Confirm you have the right file first, since restoring replaces whatever the appliance currently holds.

1. The upload is validated synchronously, before any storage is touched and before a restart is even scheduled. It must carry an authenticated manifest binding it to the appliance’s own did.domain. The restore is rejected outright, with no storage mutation, if the backup is cross-domain (taken from a different appliance), plaintext (not properly encrypted), malformed, oversized, an expansion bomb, or fails to decrypt with the configured key.
2. Once validated, the appliance archives its current storage automatically, as a safety net.
3. The uploaded backup is staged, then the appliance restarts to complete the restore.
4. On startup, the same validation runs again before the backup is actually extracted as the new storage.

Restoring a backup taken before this validation existed (a pre-hardening, old-format backup) requires an explicit legacy-key bootstrap entry to be configured first. Restoring replaces whatever is currently stored on the appliance, other than the automatic safety-net copy from step 2, including replacing or removing the logs and system_metrics directories to match what the backup contains.

Export

Downloads a PII-redacted snapshot for sharing outside the appliance (support, an auditor, a partner) without handing over the secrets, keys, and credentials a full Backup would include, encrypted to an Ed25519 public key you supply in PEM format.

Export suits a recipient outside your control. Backup only makes sense when moving a complete, working copy to somewhere just as trusted as the original, such as a restore.

The export uses hybrid encryption (X25519 ECDH + AES-256-GCM), so only the holder of the matching private key can decrypt it. Decryption happens outside the dashboard, using the appliance’s own command-line tool.

Encryption at rest

Encryption at rest for the appliance’s storage, including secrets and governance records, is off by default and turned on through the appliance’s own bootstrap configuration ([encryption] enabled = true) rather than through a dashboard control. It is set once when the appliance is provisioned, not something you toggle from the dashboard afterward.

Related

• Settings: Where the Backup, Restore, and Export actions live, alongside the appliance’s other administrative actions.
• Secrets: Credentials that are included in a full Backup but excluded from an Export.
• Governance records: Records covered by the same encryption-at-rest guarantee.
• Storage and Lifecycle: How the appliance’s storage backend and encryption-at-rest options work.