mirror of
https://github.com/jhd3197/ServerKit.git
synced 2026-11-09 05:24:49 +09:00
Juan DenisandClaude Opus 5
6d2f71d789
A backup retention cap already existed (SERVERKIT_BACKUP_RETENTION, default 5), yet a box was found holding six snapshots and 0 bytes free. Three separate defects, each sufficient on its own: 1. cleanup() is the LAST phase of the update, so retention never ran on a run that died earlier -- including the run that died BECAUSE the disk was full. Retention that only executes on success cannot bound a failure loop. backup_current now trims BEFORE writing, which also makes peak usage `keep` snapshots rather than `keep + 1`. 2. The preflight required a flat 2 GiB, but the update is about to write two full copies of the database. With an 800 MB database a box at 2.1 GiB free passed the check and then filled mid-update. The requirement is now 2 GiB + 2x the database, it trims stale snapshots and re-checks before giving up, and the halt message points at `serverkit disk`. 3. A count cap is not a disk guarantee: five snapshots of an 800 MB database is 8 GB, a third of a 25 GB droplet. The default drops to 3 and enforce_backup_budget caps backups at a share of the filesystem (SERVERKIT_BACKUP_MAX_PERCENT, default 15), dropping oldest-first and always keeping at least one restore point -- an update with no way back is worse than a full disk. BACKUP_DIR also becomes SERVERKIT_BACKUP_DIR-overridable so it can agree with the reclaim service, which scans the same directory. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>