Skip to main content
Recovery must preserve tenant data, audit records, encryption material, activation state, and the credentials needed to read existing data.

​
Back up

Back up all of the following as one recovery set:
  • PostgreSQL, including deployment and audit tables;
  • MinIO attachment volumes;
  • the casebender_secret volume or externally managed license secret;
  • .env, externally managed encryption keys, and the exact AUDIT_INTEGRITY_SECRET used by the restored audit database;
  • custom TLS trust and integration configuration; and
  • the exact pinned image manifest and Compose release.
Encrypt recovery sets, restrict access, store a copy outside the Docker host, and record a checksum. Example PostgreSQL backup:
Do not include plaintext secrets in backup logs or ticket attachments. Restoring or rotating AUDIT_INTEGRITY_SECRET independently of PostgreSQL breaks verification of existing chained audit records.

​
Restore rehearsal

At least quarterly:
  1. provision an isolated recovery network;
  2. restore the database, object storage, .env, and encryption material;
  3. start the same pinned CaseBender version;
  4. run ./casebender preflight;
  5. verify users, organizations, cases, attachments, API-key status, and audit chain integrity;
  6. record actual recovery point and recovery time.
Never connect a recovery rehearsal to production integrations.

​
Lost administrator access

Do not delete deployment state, rerun production seeding, or enable shared default credentials. Use another authorized super administrator or the documented identity-provider recovery flow. If no administrator remains, restore through the approved break-glass procedure with two-person authorization and preserve an immutable audit record. Contact CaseBender support for the version-specific recovery command.

​
Lost activation code

For a new installation that is still activation-pending:
The replacement invalidates the previous code. This command cannot reset an active installation or change an existing administrator.

​
Rollback after an upgrade

Follow the target release’s migration compatibility notes. Do not run an older application against a newer unsupported schema. Restore the pre-upgrade database and matching volumes, then start the previous pinned image set. For releases explicitly documented as backward schema-compatible, use:
This restores only the previous immutable image pin. It does not reverse or restore database migrations. See Upgrading CaseBender for the complete sequence.