Data directory and backups

Export the master key, once, right away

On first boot PEART generates the master key at master_key_path. Everything encrypted, evidence and backups, depends on it, and losing it means losing all evidence with no recovery. As soon as the first administrator exists, export a readable copy and store it somewhere separate from the data backup:

peart export-key -key /etc/peart/master.key -confirm

Keep that copy away from the data. The whole point of the key living outside /var/lib/peart is that a backup of the data never carries it; a copy stored next to the data backup throws that away.

Backups

peart backup writes a single artifact containing a consistent snapshot of the database, the evidence and the renditions:

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

The artifact is encrypted to the installation's master identity, and the command 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 include the master key in the artifact. The database snapshot is taken with VACUUM INTO for consistency, and the artifact carries a manifest with the schema version, the PEART version, and a hash of each file.

peart backup-roundtrip verifies a full backup-and-restore cycle, so you can confirm your backups are recoverable rather than assuming it.

Restore

Restore is separate for the database and for the files, and it takes the same master identity to decrypt, passed in rather than loaded on its own. Restoring into a running installation is an operations task; the Operations section covers the full cycle.

Full-disk encryption for the database

The database itself is cleartext by design (see Encryption). The compensating control is full-disk encryption on the host, and it is the operator's responsibility because PEART cannot impose it. Host hardening is where that control is described, including what changes when the volume unlocks over the network instead of at the console.