From ec8971a16a00d236c047b4320f32fd5662ad3c50 Mon Sep 17 00:00:00 2001 From: fireshaper Date: Tue, 6 Oct 2026 17:54:04 -0400 Subject: [PATCH] DECISIONS: clarify backup retention wording Co-Authored-By: Claude Opus 5.5 --- DECISIONS.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/DECISIONS.md b/DECISIONS.md index c8c9a3a..0645f2f 100644 --- a/DECISIONS.md +++ b/DECISIONS.md @@ -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.