Schema migration rollback gap in pfSense 2.7.x after config.xml restore

Evaluate rollback safety after a schema-changing upgrade in pfSense 2.7.x and later, where the configuration database schema version is tracked in /conf/version.xml and upgrades trigger migration scripts that rewrite tables.

The documented restore path only replaces config.xml. It does not revert the underlying schema changes, so the database can remain in a newer state after a restore. The safe-rollback procedure described for 2.6.x involving export, reinstall of the prior version and import does not apply cleanly to 2.7.x due to changes in the FreeBSD base and package set, making a simple version downgrade unsupported. A failed mid-migration leaves a partially migrated state with manual intervention required and no automated schema rollback.

There is an unresolved behavior around the pfSense-updater plugin and retention of pre-upgrade schema artifacts.

Can the updater be instructed to preserve a copy of pre-upgrade schema files under /var/db/pfSense-upgrade/*.sql for manual rollback, and is that retention documented? Is there a supported rollback path for schema changes in 2.7.x that keeps package databases such as pfBlockerNG or Snort consistent with a restored config.xml? What is the expected compatibility boundary when config.xml is restored to a prior version after a schema migration has completed?