Backups and restore

Everything Keel knows lives in one PostgreSQL database (schemas identity, sources, discovery, modeling, governance, quality, serving, audit, jobs, keel), plus the secret store. Redis holds only a cache and rate limit windows and needs no backup. Customer data is not stored, except failing-row keys and cached serving results.

What to back up

Item	Why	How
The PostgreSQL database	Models, proposals, governance, audit, jobs	Managed-service point-in-time recovery, or pg_dump -Fc as the owner role
The secret-store master key (Keel:Secrets:MasterKey, local provider)	Without it, every stored source password, webhook URL and Git token is unreadable	Keep it in your vault, versioned; never alongside the database backup
Azure Key Vault (keyvault provider)	Same	Soft delete + purge protection on the vault
IdP configuration	Users sign in there	Your IdP's own backup

A logical dump must be taken with the owner role: the runtime role only sees the rows of the tenant it is set to.

pg_dump -Fc -d "$KEEL_ADMIN_CONNECTION" -f keel-$(date +%F).dump
pg_restore --clean --if-exists -d "$KEEL_ADMIN_CONNECTION" keel-2026-09-29.dump

After a restore

1. Run migrate (idempotent) so the schema matches the deployed version.
2. Start the API, then the worker and scheduler. Jobs that were running when the backup was taken are retried when their lease expires.
3. Verify the audit chain (Settings › Audit log › Verify now, or POST /api/v1/audit/chain:verify). A restore to an earlier point is consistent; a chain that reports Missing or Rewritten means rows were lost or altered.
4. Re-test sources (the scheduler does it within 6 hours).

Drills

Restore into a staging environment at least quarterly and run the verification above. Keep the master key rotation history long enough to restore your oldest backup.