postgres-shared had no consistent backup. The only thing that copied it was
config_backup_executor, which tars /data/docker-data -- including the live
data directory -- while the server runs, without pg_backup_start: a file
copy of a running cluster, with no per-database restore. config_backup_executor
is left untouched; retiring it is a separate decision.
Dumps each database with `docker exec postgres-shared pg_dump -Fc <db>`,
server-side inside the PG16 container rather than through this image's own
client. Confirmed live: postgres-shared runs pg_dump 16.15, this image carries
pg_restore/pg_dump 17.10 -- a 17 custom archive would not read back on a 16
pg_restore, and 17's plain SQL emits SET transaction_timeout, which 16 rejects.
Dumping inside the 16 container is version-matched by construction; the
mismatch runs the other way for verification, so pg_restore --list runs
directly against the finished archive with no docker exec needed.
Every archive is written to a .partial file, verified with pg_restore --list
(zero TOC entries counts as a failed dump, not a kept one), then renamed and
chmod 0600 -- the dump contains table data and the globals-only dump contains
role password hashes. One database failing does not stop the others; their
files are kept, every failure is named in the result string, and the run is
still reported CRITICAL to check_history (D-33).
Not yet registered as a scheduled task, and nothing about config_backup_executor
or the deploy surface changes here (T-7).
tests/test_pg_dump_executor.py: 32 new tests, all subprocess calls mocked --
hermetic per D-26, no live services touched by `make test`. Mutation-checked:
dropping the chmod(0o600) fails the mode test; relaxing the TOC check to accept
zero entries fails test_verify_archive_raises_on_zero_entries.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
