Backup and restore

Taking a backup

peart backup writes a single encrypted artifact containing a consistent snapshot of the database, the evidence and the renditions. The database snapshot is taken with VACUUM INTO, and the artifact carries a manifest with the schema version, the PEART version and a hash of each file. It is encrypted to the installation's master identity and refuses to run without the key, because an unencrypted backup of this data is exactly what the encryption exists to prevent. It also refuses to put the master key in the artifact.

peart backup -config /etc/peart/config.yaml -out /path/to/artifact

Verifying backups are recoverable

peart backup-roundtrip runs a full backup-and-restore cycle, so you confirm your backups restore rather than assuming it. Run it periodically; a backup you have never restored is a hope, not a control.

Restoring

Restore is separate for the database and for the files, and takes the same master identity to decrypt, passed in rather than loaded on its own. Restoring into a running installation is a deliberate operation: stop the services, restore, and start them again, the same shape as an upgrade.

The master key is the one thing you cannot restore

Losing the master identity means losing all encrypted evidence and every encrypted backup, with no recovery. Export a readable copy right after first boot (peart export-key -key /etc/peart/master.key -confirm) and store it somewhere separate from the data backup. The whole point of the key living outside the data is that the data backup never carries it, so its safety is a separate task you own.

Moving an installation to another host is the case where this bites hardest, because the order of steps decides whether the restore works at all; Moving to another host is that procedure.

Retention and cryptographic erasure

Each engagement has its own key. Destroying an engagement's key renders its material illegible even in old backups you no longer control, which no row deletion can achieve. This is the basis of retention purge, and it is the honest answer to a right-to-erasure request: erasure by key destruction reaches copies a delete statement never could, and the purge itself is recorded in the audit trail.