Silent restore failure on large databases — PHP execution time limit

What causes silent partial restores?

The Magento backup/restore utility runs inside a PHP process. When the archive is large, the PHP runtime can hit max_execution_time (or a proxy‑level timeout). The process stops immediately, but any SQL statements that have already been committed remain in the database. Because the Magento CLI does not roll back on timeout, the command exits with a success exit code, giving the illusion that the restore finished.

How to detect a silent failure

1. Check the PHP CLI timeout. Run php -r "echo ini_get('max_execution_time');" on the server where the restore is executed. A value other than 0 indicates a hard limit that may be reached during a large import.
2. Monitor MySQL logs. While the restore is running, tail error.log for entries such as Aborted connection or Got a packet bigger than max_allowed_packet. A connection close that occurs before the dump ends signals a premature stop.
3. Compare table counts and sizes. Capture a baseline before backup:

   SELECT table_name, data_length, index_length FROM information_schema.tables WHERE table_schema='your_db';
   

   After restore, run the same query and look for missing tables or reduced sizes.

Recommended approach to avoid silent partial restores

• Use the native MySQL client for large dumps. Extract the SQL file from the Magento archive and import it with mysql -u user -p dbname < dump.sql. The MySQL client is not subject to PHP execution limits and will abort only on a real database error.
• Break the dump into smaller chunks. If you must use the Magento CLI, split the SQL file into parts (e.g., 100 MB each) and restore them sequentially. Each part will finish before hitting the timeout.
• Run setup:upgrade only after a complete restore. A partial restore can leave the schema in an inconsistent state; verify table counts before upgrading.

Automating integrity verification

Instead of manual CHECKSUM TABLE runs, you can automate a lightweight verification step:

1. Store a checksum snapshot. Before backup, compute a simple hash of the data size:

   SELECT SUM(data_length + index_length) AS total_bytes FROM information_schema.tables WHERE table_schema='your_db';
   

   Save the value.
2. Recompute after restore. Run the same query and compare the result. A mismatch indicates a partial restore.

This method is fast, requires no extra tools, and works for any Magento version or set of extensions.

Missing diagnostic detail

Does the restore run via the Magento CLI or through the admin UI?

If it is the admin UI, additional web server timeouts (Apache, Nginx, or a reverse proxy) may be the root cause, and increasing max_execution_time alone will not help. In that case, the native MySQL import remains the safest path.