Hi Brian,
We’ve been communicating by email, but I’ll put the results in here so that it’s searchable by others who may have the same problem.
This answer is definitive – I spent a looong time getting to the bottom of this, and eventually did…
Your web hosting company is using LiteSpeed as a web server. Not wrong in itself. But LiteSpeed has an issue with killing off PHP processes when the other end (usually the browser – but in the case of WordPress’s scheduling engine, it is WordPress itself doing a “loop back”) closes the connection. This is leading to the backup jobs being killed prematurely – after a maximum of 15 seconds on your setup.
Googling shows that this, as expected, affects all backup plugins – because all backup plugins run via the scheduler and get killed by LiteSpeed.
We have a workaround here, which worked for someone else as recently as yesterday:
https://updraftplus.com/faqs/i-am-having-trouble-backing-up-and-my-web-hosting-company-uses-the-litespeed-webserver/
Sadly the first work-around didn’t work in your case. I’m not expert enough in LiteSpeed configuration (and don’t have access to your LiteSpeed configuration anyway) to know why not. But if you can communicate with your web hosting company, they may know.
The second work-around is the “WordPress alternative cron (scheduler)” system, mentioned in the same article. This got some extra time, but only up to 30 seconds maximum. This 30 seconds cut-off is coming from your use of CloudFlare as a reverse proxy, which cuts the connection after a maximum of 30 seconds, and apparently usually less – and then LiteSpeed, seeing the connection cut, kills the process.
The third factor is that your site is enormous. The fourth is that your web hosting server is underpowered – by our tests, it’s only giving about 40% of the performance that we typically see. (This is talking about CPU power, not memory usage or maximum run-time which your hosting company mentioned).
Putting those factors all together you get a toxic combination. When UpdraftPlus wakes up to resume the backup job, which it has to do many times given the short run times + low resources it gets, eventually it gets to a state where it requires 15 seconds to scan the existing half-a-gigabyte zip file to see how far it got, finding 8,000 files inside it. Then in the few seconds remaining, it finds some new files to put inside to continue the backup. Then it issues the command to add them to the zip file; but time runs out before this can occur. This “deadlock” is being reached inevitably because the time taken to scan the existing zip file takes up an increasing amount of the few seconds available until it is taking so much time that nothing else can be achieved.
Technically there are only 3 ways to resolve this:
1) Re-configure LiteSpeed to not kill connections when the other end goes away. Only your web hosting company has control over this. If you do this, then remote the ALTERNATE_CRON line from your wp-config.php
or:
2) Re-configure CloudFlare to keep the connection open for more than 30 seconds when they fetch a resource. I don’t know if they even have a setting for this.
or:
3) Move to a web hosting company that either doesn’t use LiteSpeed (which is about 99.9% of them, not that that’s because of the technical merits – it’s just the market share for historical reasons), or if it does, has more powerful CPUs. If you email me I can make a recommendation.
If you’re totally loathe to move your hosting and if they can’t fix it, then you could fund some changes to UpdraftPlus to more aggressively cache some things that would allow us to get more out of the 15 seconds… but we’re not likely to get around to that by ourselves any time soon because large site/underpowered server/web server that kills connections prematurely is a toxic combination and the problem really needs addressing there if it can be.
David
