We've received reports that the restore process gets stuck and continues to loop indefinitely. A stuck restore normally indicates that the background cron is not running or cannot run. While increasing the PHP memory limit in the JBWP settings can resolve this issue, it may also cause the process to be unable to reload once it's closed/killed and the restore may continue to be stuck. To troubleshoot this, ensure that the manual Cron Job has been added to your hosting control panel. You may find the manual cron in JBWP >> Schedules. It will look like the following line below.
* * * * * php /home/test/public_html/wordpress/wp-content/plugins/backup-guard-platinum/public/cron/cron.php > /dev/null 2>&1 &
If the restore continues to be stuck, it could be possible that the hosting provider is enforcing heavy caching on WordPress AJAX calls. JBWP calls will be cached and will not trigger reloads during the restore, causing the process to be stuck. To work around this issue, open the browser dev tools on the bg_restore.php page then enable "Disable Cache" in the Network tab. This allows the file and DB restore to complete ( basically the AJAX awake calls are fetched without caching, allowing the restore to progress).
Once the restore is complete but the "Migration" step fails, it could likely be related to security software or the heavy caching described above.
2024-02-15 19:06:17 Inside Migration, checking license
2024-02-15 19:06:17 License backupGuardGetCapabilities: 4
2024-02-15 19:06:17 Start migration
2024-02-15 19:06:17 After importing class SGMigrate
2024-02-15 19:06:17 After setDelegate
2024-02-15 19:06:17 After getTables
2024-02-15 19:06:17 Old site url: http://test.com/
2024-02-15 19:06:17 Current site url: https://test2.com
2024-02-15 19:06:17 Site URL Mismatch, entering migration
2024-02-15 19:08:21 Inside getActionId . 28
2024-02-15 19:08:21 Backtrace doRestore
2024-02-15 19:08:21 Inside Migration, checking license
2024-02-15 19:08:21 License backupGuardGetCapabilities: 4
2024-02-15 19:08:21 Start migration
2024-02-15 19:08:21 After importing class SGMigrate
2024-02-15 19:08:21 After setDelegate
2024-02-15 19:08:21 After getTables
2024-02-15 19:08:21 Old site url: http://test.com/
2024-02-15 19:08:21 Current site url: https:/test2.com
2024-02-15 19:08:21 Site URL Mismatch, entering migration To perform the migration manually (which is essentially a find and replace), kindly use the "WP Migrate Lite" plugin with its "Find & Replace in Tables" feature to replace the Old Site URL with the new Site URL in ALL of the restored jbv4_ tables. (and updated this db prefix in wp-config.php)
2024-02-15 19:10:22 Old site url: http:/test.com/
2024-02-15 19:10:22 Current site url: https://test2.com
//$table_prefix = 'wp_'; $table_prefix = 'jbv4_';
