Magento setup:rollback completes but no built-in integrity check for restored database

Magento 2's native backup and rollback flow (bin/magento setup:backup / setup:rollback) restores code, media, and database archives from var/backups, then runs setup:upgrade and cache:flush. However, the rollback itself appears to perform no verification that the restored database is actually consistent.

The concern is a silent-failure scenario: a rollback that completes without errors but leaves truncated tables, orphaned rows, or violated foreign keys, because the SQL dump import is not followed by any CHECK TABLE, ANALYZE TABLE, or referential-integrity validation. setup:upgrade only applies declarative schema patches; it does not audit row-level data. On large databases the import can also hit PHP memory or time limits, raising the risk of a partially applied dump that still reports success.

Assume Magento Open Source / Adobe Commerce 2.4.x on MySQL 8, with the crypt key in app/etc/env.php unchanged between backup and target.

Is there any supported mechanism or documented post-rollback checklist in Magento itself for confirming database integrity, or is verification entirely the operator's responsibility? Which concrete checks (row-count baselines, setup:db:status, mysqlcheck, test checkout) are considered sufficient before reopening a storefront? For very large databases, is importing the dump via the mysql CLI instead of setup:rollback a safe and supported alternative?