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;
  • every referenced external-storage object at its exact provider version/generation, with size and SHA-256;
  • 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.
Legacy app/db installations may store attachments in miniodata and the license key in casebender_secret, while the signed bundle stores local files in casebender_data only for historical/single-node layouts and the license key in .env. New production installations require external storage. Back up the legacy source layout before changing it. See Migrate a Legacy Docker Compose Installation. 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. Create the database-linked object manifest and test an isolated exact-version restore with scripts/storage/verify-backup-restore.ts. Follow Storage Backup and Restore; a database dump and an eventually consistent bucket copy taken at unrelated times are not a valid recovery point.

​
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.