Can a Doctrine Migrations rollback ever be safe after a destructive schema change in production?

In a Symfony application using Doctrine Migrations, I am planning a release that includes a destructive schema change (dropping a column that existing code still reads). I want a rollback plan I can actually trust, but the more I look at how migrations work, the less clear the safe path is.

My understanding is that doctrine:migrations:migrate with a target version simply executes the down() methods, and a down() that recreates a dropped column cannot restore the data that was in it. I also believe DDL behaves differently per platform: on MySQL/MariaDB a failed migration may leave the schema half-migrated because of implicit commits, while PostgreSQL can wrap DDL in a transaction. On top of that, the bundle tracks executed versions in a table, so reverting schema manually without rolling back the version row would leave state inconsistent.

Assume a current Symfony 6/7 application with doctrine/migrations 3.x on MariaDB, verified against my installed versions.

Given that, is the accepted practice to split destructive changes across two deploys (code tolerant of both schemas first, drop the column later) so rollback never needs to undo data loss? If a destructive migration has already shipped, is a database backup plus a compensating data migration the only real recovery option, since down() alone cannot restore rows? And does doctrine:migrations:diff pose a risk here, in that re-running it after a rollback could regenerate the same DROP statements while the mapping metadata still differs?