Contao Schema Rollback: Staging Clone vs. Pre-Update Dump

Our team is preparing a Contao update that will trigger the Install Tool's database update, and we need a rollback plan if the schema change fails midway. The Install Tool applies the SQL required to reach the code's expected version and records that version, but ships no reverse migration, so recovery is operational rather than a built-in undo.

The two approaches are updating a staging clone and cutting over, versus restoring a pre-update dump live. The clone gives a clean rollback by discarding the copy, but requires reconciling writes that reach production during the update window. The dump-and-restore path is cheaper, but writes after the dump are lost, and a partially applied schema change may not be reproducible from the dump. The matching Contao file version must be restored, because the dump does not capture file changes.

Because Contao supports multiple database engines, recoverability after a partial failure appears to differ by platform, and the exact SQL and existence guards used by the Install Tool vary across Contao releases and installed extensions. We have not confirmed this for our version.

Which approach is more defensible when the site cannot tolerate lost writes? Is there a reliable way to verify whether a failed migration has already committed DDL on our engine before choosing? How should extension-added schema changes alter the decision?