Silent restore failure on large databases — PHP execution time limit

Restoring large database backups without visibility into failure

Magento's built-in backup tool creates database archives that can exceed practical PHP execution limits during restoration. The bin/magento setup:backup --restore command and admin UI restoration process do not surface a timeout error when the PHP max_execution_time is reached; the operation appears to complete while leaving the database in a partially restored state.

No automated checksum or integrity verification runs after restore, so merchants must manually compare table row counts, foreign key constraints, and media file counts against pre-backup records. This gap is compounded when restoring to a different Magento version or with mismatched extensions, where schema mismatches require additional setup:upgrade runs that may themselves time out.

Questions

1. What is the recommended approach to detect and prevent silent partial restores when the database archive size approaches the PHP execution limit?
2. How can integrity verification be automated as part of the restore workflow without relying on manual CHECKSUM TABLE comparisons?