vps-health-api/agent/pg-backup-pull
le king fu 5208957ce9
All checks were successful
CI / verification (pull_request) Successful in 31s
CI / verification (push) Successful in 32s
fix(agent): nothing the VPS sends deletes or alters a pulled backup
Anchoring the rotation on the newest directory name let the VPS steer
it: one future-dated directory (VPS clock off, or a VPS gone rogue)
pushed the window forward and deleted every real backup, with exit 0
and an ok report. Two more inputs from the outbox could do harm: rsync
-rt rewrote an already pulled .age whenever the VPS served another
version, and an impossible dated name (2026-13-45) failed `date -d`
under set -e, stopping every later pass for good.

- latest is the newest valid dated directory not after today; the
  rotation keeps it and the 29 days before it;
- a name is dated only if `date` gives it back unchanged (busybox turns
  2026-02-30 into 2026-03-02); an invalid or future name is logged,
  never counted, never removed, and the pass goes on;
- --ignore-existing: a pulled file is never rewritten. The VPS writes a
  .tmp and renames it, and the filter drops the .tmp.

Refs maximus/la-compagnie-maximus#220

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-10 19:13:27 -04:00
..
maximus-pg-backup-pull.service feat(agent): daily pull of the encrypted PostgreSQL backups 2026-10-10 16:18:17 -04:00
maximus-pg-backup-pull.timer feat(agent): daily pull of the encrypted PostgreSQL backups 2026-10-10 16:18:17 -04:00
run-pg-backup-pull.sh fix(agent): nothing the VPS sends deletes or alters a pulled backup 2026-10-10 19:13:27 -04:00