Documentation  /  Operations

Backup & restore

Backing up and restoring Dream-Genie itself — and the rule that a backup you have not restored is not a backup.

COMES BACK the database agreements and tickets documentation and the vault findings and audit trail configuration DOES NOT anything written after the backup in-flight agent work the signing key, if you did not keep it sessions a restore you have not performed is a backup you have not got

What to back up

  • The database — schema and data, including the audit log
  • Named volumes for artifacts and evidence
  • Configuration and the licence file
  • Encryption keys, held separately from everything above

Taking a backup

dg backup create --out /path/to/backup

Runs consistently against a live platform. The audit log is append-only and is captured whole — never truncated to fit.

Restoring

dg backup restore /path/to/backup --verify

--verify restores to a scratch schema and confirms the result rather than assuming it. Use it.

Test the restore

A backup you have never restored is not a backup. The platform holds itself to the same rule it holds your clients' backups to.

Restore rehearsals are scheduled and recorded, per class, with the date each was last proven. A backup that exists but has never been put back is captured, not verified — and the difference is the whole point.

What a restore does not bring back

Anything outside the backup: the encryption keys if you did not capture them separately, and any state held only in a running container. Both are documented rather than discovered.

← Client portal  ·  Users & access →

Not running it yet? Start a thirty-day evaluation — read-only, on your own estate, no card.

Thirty days · read-only · no card

Run it beside what you already have, against your real clients. It tells you what your tools are reporting that is not true.

Start an evaluation