Skip to content
Documentation menu · version 0.1.0-alpha.4

Backup and disaster recovery

What to protect

Data Where Protection
Tenants, users, devices, sessions, jobs, audit log, settings PostgreSQL scripts/backup.sh (logical dumps) plus continuous WAL archiving / PITR from your PostgreSQL operator or provider
Transferred files, session recordings S3-compatible bucket Bucket versioning and cross-region replication; object lock for recordings if policy requires
Agent CA and service certificate (agents.pki_dir) Secret Secrets manager with versioning. Losing the agent CA key means re-enrolling every device.
Token signing key, cookie key, files master key Secret Secrets manager. Files and notification secrets are unreadable without the master key.
License and license public key Secret / License Center Re-download from the customer portal
Configuration Git / Helm values Version control

Redis (rate limits) and NATS (relay, short-lived events) hold no state that needs restoring.

Targets

Target How
RPO ≤ 5 minutes WAL archiving / PITR (logical dumps alone give the dump interval)
RTO ≤ 1 hour Restore PITR or the latest dump, run migrate up and verify, redeploy

Routine backups

PGHOST=db.internal PGUSER=yarma_backup PGPASSWORD=… PGDATABASE=yarma \
[email protected] RETENTION_DAYS=30 \
  scripts/backup.sh /backups

Dumps are custom-format, compressed, optionally GPG-encrypted and accompanied by a SHA-256 file. Run at least daily (Kubernetes CronJob or system timer) and copy the dumps off-site.

Restore

  1. Provision an empty database (and cluster, for a regional failure).
  2. Restore:
    PGHOST=… PGUSER=… PGPASSWORD=… scripts/restore.sh /backups/yarma-yarma-<stamp>.dump yarma
    The script verifies the checksum, decrypts .gpg dumps, creates the yarma_app role used by row level security if the cluster lacks it, and restores in one transaction.
  3. Bring the schema up to date and verify integrity:
    yarma-api -config-dir /etc/yarma migrate up
yarma-api -config-dir /etc/yarma verify
    verify fails unless the schema is at the latest migration and every tenant's audit hash chain is intact, so tampering or a partial restore is detected before go-live.
  4. Restore secrets (PKI, keys) from the secrets manager, point the API at the database and redeploy. Agents reconnect automatically; their certificates remain valid as long as the agent CA was restored.

Drills

scripts/dr-drill.sh backs up the live database, restores it into a scratch database, runs verify, compares row counts of the core tables and drops the scratch database. CI runs it on every push; run it quarterly against production (read-only for the source) and record the restore time against the RTO.

Documentation for Yarma 0.1.0-alpha.4. Something unclear? .