Restore fails about 50% every time

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.

Hi @timelimited

My apologies for delayed reply, but the thing you described sound like charset incompatibility which is quite possible in your case.

It looks like you’re trying to restore your backup on Windows machine, these does not have all common charsets installed by default (MySQL Server), our plugin will try to resolve such issues on its own, but sometimes it can’t detect correct charset.

In such case, I would recommend you to check if the MySQL version is the same as on source server and if yes, you can also seach & replace all SQL files inside backups by search for charset e.g. “utf8mb4” and replace it to supported charset, hint: you can use existing tables to find right one. Do the same thing for charset collate.

Let me know if I can help you any further ??
Thank you!

”?the thing you described sound like charset incompatibility?” – That would be incorrect. This wordpress site has been backed-up and restored between these two machines multiple times without issues and have never changed the MySQL character sets on any of the databases. This is an issue that I had with the newest version, but as said in the above posts, I found the errors in the program and corrected them and was able to restore the system.

Hi @timelimited

Charset issue was my first thought, it’s rare but possible.

Could you please let us know what was the issue, so we can resolve the issue in future versions of our plugin?

Thank you!