Jobs won’t run after returning to 4.1.7

Thanks for your reply. The site is not in maintenance mode, the host is not blocking wp-config.php, and alternate cron produced the same error. Version 4.1.7 of BackWPup was working perfectly through the last successful backup on 5/20/25. Later that day, the plugin was updated from 4.1.7 to 5.2.2. I reinstalled 4.1.7 the same day, and checked that all previously configured backup jobs were intact. However, the next scheduled job on 5/27/25 did not run, nor was I able to initiate a manual job successfully on that date, nor did the 6/3/25 job run. Since 4.1.7 had been working perfectly for many weeks before this happened, it seems pretty clear that something was changed by the update to 5.2.2 that was not hanged back when I reinstalled 4.1.7.

So what does 5.2.2 change that would not be overwritten back to its pre-update state by a 4.1.7 reinstall, and which would abort a job before it started?

1). I created a new backup job, but it didn’t run as scheduled

2). I had already changed both the time and day of the old backup job to no avail, but I tried it again – still nothing.

3). No logs are being generated, presumably because the jobs aren’t starting.

The new backup job completed as (re-)scheduled. However, it took twice as long (both times). I recreated the backup set in the old job to the best of my memory in the new job, and I appear to have gotten it right, as the backup file size from the new job is the same size as it was for the old job. So why is it taking so much longer?

Would the update/rollback have changed the maximum script execution time (currently 25 – what is default?), or the reduce server load setting (currently medium – pretty sure that’s what it was before)?

If not, what else could’ve lengthened the duration of the backup? It’s a large site with gigantic backup files on shared hosting, so I want to keep the server usage as modest as possible. I have rescheduled the new job to the same schedule as the old weekly backup time to test whether that simply might be a lower traffic time on the server, but double the duration seems like a pretty big difference for variations in server traffic.

The new job ran at the time the old job was previously scheduled, but again, as with all previous tests of the new job, it took more than twice as long to create a file that was exactly the same size. We prefer zip files, and that’s how the old job was compressed, so that can’t account for the difference.

I’ll reduce the Maximum Script Execution Time from 25 to 20, but it seems to me that breaking the job up into a larger number of smaller pieces would cause it to take more time, not less. Please let me know if there is a flaw in this reasoning. Also, you didn’t mention what the default setting for this is – 25? Or something else? Is 30 an option?