Airflow db restore completes but no built-in check confirms recovered metadata matches the backup

Apache Airflow ships airflow db backup and airflow db restore to export and reimport the metadata database (PostgreSQL, MySQL, or SQLite) for disaster recovery. The restore command finishes without error, but there is no documented validation step that compares the restored database against the backup file itself — no row-count or checksum comparison is built in.

The constraints here are practical. The metadata DB holds DAGs, connections, variables, and task instance history, but the Fernet key, task logs, plugins, and custom Python dependencies live outside it, so a clean restore does not prove the environment is whole. Application-level checks such as airflow db check and airflow dags list confirm connectivity and presence, yet they do not establish completeness against what was captured. Version alignment between the backup source and restore target also matters, since schema differences can silently change what gets recovered. Assume Airflow 2.x with a PostgreSQL backend.

Given this, what is a defensible verification strategy after airflow db restore?

1. Which metadata tables (e.g., dag, connection, variable, task_instance) are the minimum set worth row-count or checksum comparison between backup and restored database?
2. Can airflow dags list output be reliably diffed pre- and post-restore, or do serialization and parsing states make that comparison misleading?
3. How should undecryptable variables be detected when the Fernet key may have changed between backup and restore?