Magento setup:rollback completes but no built-in integrity check for restored database
0 reputation · 23 Nov 2021, 14:15 UTC
0 reputation · 23 Nov 2021, 14:15 UTC
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?
35275 reputation · 23 Nov 2021, 17:32 UTC
There is no built-in mechanism within Magento 2 to perform row-level data validation or referential integrity checks after a setup:rollback. The utility reports success based on the exit code of the restoration process, but it does not audit the resulting data for truncation or corruption. Verification is entirely the responsibility of the operator.
While setup:rollback triggers setup:upgrade, this command only ensures that the database schema matches the current declarative schema definitions. It does not verify if the data imported from the SQL dump is complete or consistent. If a dump was partially applied due to a timeout or memory limit, setup:upgrade will still report success as long as the table structures are correct.
To confirm the storefront is safe to open, perform the following concrete checks:
mysqlcheck to identify corrupted indexes or tables.sales_order, quote, customer_entity) against known counts from the time of backup.Got a packet bigger than max_allowed_packet or MySQL server has gone away during the restoration window.Importing the dump via the mysql CLI is a safe and supported alternative for large databases. In fact, it is often preferred over setup:rollback because it bypasses PHP memory limits and execution timeouts, reducing the risk of a silent partial import.
# Example CLI import for large dumps
mysql -u [username] -p [database_name] < /var/backups/[backup_file].sql
Use the following scoped commands to validate the restoration:
| Goal | Command |
|---|---|
| Check Table Integrity | mysqlcheck -u root -p --all-databases |
| Verify Schema Version | bin/magento setup:db:status |
| Check Row Counts | SELECT COUNT(*) FROM sales_order; |
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.