Columbia Games · CCM v2 / August 2026 26.
The database backup belongs immediately before the migration, not sometime that day
The production migration runner gained a database backup taken at migration time, plus retention rules. A nightly backup can be far too old to serve as the recovery point for a release that changes live data.
Situation
A system can have an excellent daily backup routine and still have the wrong recovery point for an afternoon migration. If orders or user data have changed for hours before the deployment, restoring the general backup may imply unacceptable data loss. A migration rollback therefore needed a snapshot taken close to the release itself.
Approach
The migration runner started taking a dedicated database backup immediately before the actual data-changing step. The backup was associated with that release, and retention rules prevented migration snapshots from accumulating without bound. Larger backfill-style operations were made opt-in so they could not begin automatically merely because the corresponding code happened to be present in a release.
Outcome
Each migration release gained a concrete recovery point, while high-impact historical backfills required a deliberate decision. Backup stopped being generic infrastructure in the background and became an explicit part of the deployment transaction.