demarcDocs

Backup and recovery#

Back up the database, private configuration and any operator-managed experience data. Use PostgreSQL tools for the production Compose deployment and the SQLite-safe backup path for local SQLite installations. Recover provider credentials from the secret manager independently of the application host.

Before you start#

  • Confirm the runtime's active database backend and database name.
  • Prepare an encrypted off-host backup destination.
  • Record the deployed revision and database schema version.
  • Choose a disposable restore target with outbound telephony disabled.

Back up PostgreSQL#

The deployment backup job creates PostgreSQL custom-format dumps, checks that they can be listed by pg_restore, and retains fourteen days of local dumps. The daily timer runs at 08:00 UTC with up to five minutes of delay. A local dump does not survive loss of the host: configure independent off-host copies.

For an adapted Compose installation, set POSTGRES_USER, POSTGRES_DB and BACKUP_FILE to your database role, database name and protected output path:

umask 077
docker compose exec -T postgres pg_dump -U "$POSTGRES_USER" -d "$POSTGRES_DB" -Fc > "$BACKUP_FILE"
test -s "$BACKUP_FILE"
docker compose exec -T postgres pg_restore --list < "$BACKUP_FILE" > /dev/null

Keep private environment files and the application revision beside the backup in separately protected storage. A successful list check proves a readable dump catalog; complete a restore drill to verify the application data.

Back up SQLite#

For a local SQLite installation, use the repository's SQLite backup tool or a SQLite online-backup operation. Do not copy an actively changing database with a generic file copy. Save configuration separately and transfer an encrypted copy off the host. PostgreSQL dumps and SQLite backups are not interchangeable.

Verify recovery#

Stop application writers on the isolated restore target. Restore the selected PostgreSQL dump into an empty PostgreSQL database with pg_restore, or use the SQLite restore path for a SQLite backup. Start a compatible application revision and verify calls, messages, number routing and operator settings. Confirm that /api/ready reports the expected schema and that no live webhook URL targets the recovery environment.

After recovery, rotate any credentials that may have been exposed during the incident. Preserve the original failed database and logs until diagnosis is complete. Never run docker compose down -v as a backup or restore step.

If it does not work#

Stop before a migration or restore overwrites the only usable copy. Retain the original database, source revision, environment names, dump and error output, then repeat recovery against a fresh isolated target.