DECISIONS: clarify backup retention wording
CI / check (push) Successful in 7m15s Details

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
fireshaper 2026-10-06 17:54:04 -04:00
parent bd89c4cb58
commit ec8971a16a
1 changed files with 1 additions and 1 deletions

View File

@ -1320,7 +1320,7 @@ Implementation decisions not spelled out in `memory-bank/implementation-plan.md`
- **Backups run in the stack** as a `backup` service on the same Postgres image (so `pg_dump` matches the server version), with a small shell scheduler rather than cron: one process, logs in `docker compose logs backup`, nothing to install on the host.
- **Off-server storage is a host folder** (`BACKUP_DIR`), as chosen: a NAS share mounted on the server. The README warns that an unmounted share would put dumps on the server's own disk.
- **Retention is age-based**: dumps older than `BACKUP_KEEP_DAYS` (default 14) are deleted after each successful backup, so a failing backup never deletes the last good ones by itself running.
- **Retention is age-based**: dumps older than `BACKUP_KEEP_DAYS` (default 14) are deleted only after a successful dump (the script stops at the first error), so a run of failed backups never removes the last good ones.
- **Dumps use pg_dump's custom format** (compressed, restorable with `pg_restore --clean --if-exists --no-owner`), written under a `.partial` name and renamed when complete.
- **`restore.sh` defaults to a separate `deadhead_restore` database**, so the routine test restore never touches live data; recovering the live database is a documented, explicit command with the server stopped.
- **The step's test compares a player row by row**: after a guest's sign-up and tutorial run, the check backs up, restores into a fresh database and compares that player's rows across nine tables as JSON; they match exactly.