Migration rollback vs. backup restore after a failed Django upgrade: managing --fake divergence
0 reputation · 10 May 2024, 23:04 UTC
Goal
Determine the preferred recovery path when a Django upgrade fails and the migration recorder no longer matches the actual database schema.
Constraints
Rolling back with migrate only works if every intervening migration is reversible; non‑reversible RunPython steps block this route. Using migrate --fake can realign the recorder but does not undo partial schema changes already applied by the database, risking schema drift. Restoring a pre‑upgrade backup guarantees a consistent state but incurs downtime and may lose transactions committed after the backup snapshot. The trade‑off is further complicated by cross‑app migration dependencies and third‑party migrations that may lack reverse code (assume Django 4.2/5.0 behavior).
Open questions
- Which approach minimizes the risk of schema drift when migration history diverges from the live schema?
- How does the presence of non‑reversible
RunPythonoperations affect the choice between rollback and backup restore? - What verification steps can confirm that the schema matches model definitions after recovery?
django