Cerynix Support
Operations runbook

Backup & disaster recovery

Cerynix encrypts database and evidence backups with age before writing them. A usable recovery plan also requires off-box copies, an off-box private identity and regular restore tests.

1

Create and protect backups

backup
cd /opt/cerynix/app
scripts/backup.sh

Expect db.sql.gz.age and evidence.tar.age. Confirm both exist, monitor the scheduled job, and copy them off the VM. Store BACKUP_AGE_IDENTITY separately; losing it makes the encrypted backup unrecoverable.

2

Prove recovery

isolated drill
BACKUP_AGE_IDENTITY=/path/to/cerynix-backup.key \
  scripts/restore-drill.sh

Run drills on a schedule and record RPO, RTO and the application checks performed. Never use production as the first restore test.

3

Recover production

  1. Declare the incident, select the recovery point and preserve failed-system logs and disks.
  2. Stop user writes and isolate the target. Verify the chosen backup and matching application release in a recovery environment.
  3. Restore only during an approved maintenance window:
    BACKUP_AGE_IDENTITY=/path/to/cerynix-backup.key \
  scripts/restore.sh backups/<timestamp>
  4. Start the matching application version; verify health, login, critical records, evidence objects, reports and integrations before reopening access.
Destructive operationrestore.sh overlays database content. Do not run it against an active production service. Take a safety copy first and keep the incident rollback point.
4

After recovery

Record data-loss bounds, timings and validation evidence; rotate exposed credentials; resume off-box backup replication; and update the runbook from the incident review.

← SupportSafe upgrades →