Cody Schaefer
c99666796a
Asked whether there is an easy way to take a full backup before deploying, since this touches auth. There is - the backup sidecar is already running and scripts/db-backup.sh takes a one-shot dump - but three things about THIS deploy were not written down anywhere. Timing. The container starts with `alembic upgrade head && exec gunicorn`, so the migration runs seconds after redeploy and there is no window afterwards. The dump has to be taken before, not after. Retention. The scheduled job prunes to the newest BACKUP_KEEP (14) files matching wpsuite-*.sql.gz*, so on a daily cadence a pre-deploy dump is deleted in a fortnight - exactly when a slow-burning problem would surface. Copying it to a name outside the glob protects it. Rollback is not just the database. The new code has no password_hash in its model and the old code requires it, so restoring without also rolling the code back leaves schema and application disagreeing. Recorded as both steps in order, with a note to capture the current commit FIRST, since that is easy to forget and impossible to reconstruct afterwards. Also flagged what this particular dump is: the last copy of every password hash that will ever exist. BACKUP_ENC_PASSPHRASE must be set before taking it - the script warns and writes plaintext otherwise - and its retention deserves a deliberate decision rather than the default fortnight, because bcrypt is not plaintext but is crackable offline given a copy and time. And a step to prove the dump is readable before deploying, because an untested dump is not a backup. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>