Backups

The gateway stores attestations, batches, and anchor proofs in a SQLite database. Use persistent local disk, not /tmp or a network filesystem. SQLite is configured for WAL mode, synchronous=NORMAL, and up to five connections.

Create a backup

Use SQLite's backup facility so WAL state is handled consistently:

sqlite3 /var/lib/witness/gateway.db ".backup '/backups/gateway-YYYYMMDD-HHMMSS.db'"

Back up the reviewed binary/version, database, and deployment configuration as an associated set. Configuration backups may contain witness and federation bearer tokens, external credentials, or private keys; access-control them as secrets. Retain backups according to the value of the records and test a restore rather than assuming that a copied file is usable.

Restore

Stop the gateway before replacing its database. Restore a known-compatible backup, ensure the service identity owns the database directory, and start the reviewed binary. The gateway runs embedded migrations at startup. Migrations are forward-only, so a downgrade requires a compatible pre-upgrade backup.

What a backup does not prove

A database backup protects against some process, host, and disk failures. It does not make gateway records tamper-evident, prove historical gateway honesty, or replace client verification of signatures and proofs. Preserve independent signed attestations, signed tree heads, consistency proofs, and auditor state when those are part of the deployment's evidence model.