Reply Pilot Database Backup

reply-pilot-db-backup vytvari kompletni logicke zalohy PostgreSQL 17 bez systemoveho cronu. Samostatny kontejner vlastni DB credential i backup soubory; reply-pilot-worker zna jen interni HTTP URL a bearer token.

Tok a interval

Worker job database_backup vola kazdych WORKER_DATABASE_BACKUP_INTERVAL_SECONDS=7200 sekund POST http://reply-pilot-db-backup:8080/api/backups. V lokalnim i produkcnim secretu je zapnuto i WORKER_DATABASE_BACKUP_ON_START=true. Trigger je asynchronni a service nepovoli soubezne dva dumpy.

API neni publikovane na host:

  • GET /healthz je verejny jen uvnitr Docker site pro healthcheck;
  • GET /statusz a POST /api/backups vyzaduji Authorization: Bearer <BACKUP_API_TOKEN>;
  • DB host, user ani password worker nedostava.

Soubory a ownership

Lokalni backupy jsou v project rootu pod temp/reply-pilot-db-backup/backups/. Produkce pouziva:

/home/agent/docker_deployments/reply-pilot/reply-pilot-db-backup/data/backups

Kontejner bezi s HOST_UID:HOST_GID; na Mathboxu tedy soubory vlastni agent:agent, ne root. Start/deploy skonci chybou pri ownership mismatch. Backup directory ma mode 0700, .sql.gz, .sha256 a status soubor 0600.

Dump se nejprve zapisuje jako .partial, overi se gzip stream a SHA-256, a teprve potom se atomicky prejmenuje. Po uspesnem dumpu se mazou hotove backupy starsi nez BACKUP_RETENTION_DAYS=7.

Databazovy pristup

reply-pilot-db pri startu/migraci spravuje samostatny login reply_pilot_backup. Role nema superuser, create database ani create role opravneni; dostava CONNECT, PostgreSQL roli pg_read_all_data, read pristup k large objects a BYPASSRLS, aby kompletni dump nevynechal data chranena row-level security. Role nema zapisova opravneni. Heslo je separatni pro local/prod a je ulozene jen v SOPS secretech DB a backup modulu.

Obnova

Checksum over a obnov dump do prazdne databaze:

sha256sum -c reply-pilot-20260716T120000Z.sql.gz.sha256
gunzip -c reply-pilot-20260716T120000Z.sql.gz | psql -v ON_ERROR_STOP=1 -d restored_database

Obnova se ma pravidelne zkouset na separatni databazi. Backup na stejnem hostu chrani proti aplikacni nebo schema chybe, ale ne proti ztrate celeho serveru; pro disaster recovery je nutna dalsi off-host kopie.