Starting the restore a second time, it starts at 49% and runs for a couple minutes until suddenly within a couple seconds the browsers memory usage goes from ~300MB to over 5GB of memory usage and then the restore fails with the same restore log. I’ve already used WP-Optimize on the database and checked for inconsistencies. The table that finishes successfully is only 332 rows and 224KB, with the next table listed in MySQL having 492 rows and 464KB’s of data. The entire database is only 268 MB, so definitely not a size issue.
I modified the php.ini to also increase the “memory_limit” to 4096M from 2048M, “post_max_size” to 1024M from 256M, “upload_max_filesize” to 1024M from 200M, and “post_max_size” to 1024M from 40M. All that did was allow the browser to stay at 5G memory usage longer, and Apache to go over 2G of memory useage before the restore process failed, though now the restore log ends in:
[STEP] [2023-06-20 23:13:48] Started restoration of finer_search_history 6/189 (3.17%) table[INFO] [2023-06-20 23:13:48] Progress of finer_search_history: 1/3 (33.33%)
The finer_search_history table has 492 rows at 464KB’s of data, so no reason for it to fail on that. When looking at the table through PHPMyAdmin, the finer_search_history table has been created, but contains no data. I am going to test clearing the data from the live search history table and doing a fresh backup to see if it will restore.
Even with that table emptied out completely, the restore log ends in:
[STEP] [2023-06-20 23:38:31] Started restoration of finer_search_history 6/189 (3.17%) table[INFO] [2023-06-20 23:38:31] Progress of finer_search_history: 1/2 (50.00%)
Nevermind…. I went through your code and found the CLI command: php cli-handler.php bmi_restore <backupfile.zip> Running that and fixing a couple issues with how it handles certain MySQL tables I was able to fix it and got the restore to run successfully at a command prompt.