Not backing up to dropbox properly

[AlanParticipant]

Hi,

I’m having trouble trying to back up to dropbox for a client.

I get this error below, it just doesn’t finish.

“Dropbox chunked upload: 76.3 % uploaded (zWFYeN1tBeEUqQ8-Gb-Wqw, 19922944) (Sep 30 16:34:57)”

I’ve pasted the log below

https://pastebin.com/UKjBcLXm

The server is an SSD hardrive and a really good processor, I’ve split the chunks down to 25mb upped the execution time, but it just doesn’t back up the site.

I hope you can help.

[udadminKeymaster]

Hi Alan,

Is that what the log file has in now? If so, it suggests that the scheduler in your WP install is not working properly. UpdraftPlus should be picking up and resuming the backup from where it left off, but that doesn’t appear to be happening.

If you install the free plugin WP Crontrol and then visit Tools (not Settings) -> Crontrol, then what scheduled tasks does it show – are there lots of overdue ones that haven’t been running?

David

[AlanParticipant]

Hi David,

I installed the plugin and no there isn’t a bunch of tasks waiting from Updraft, just the two scheduled ones that were setup for every 2 weeks. Here is a screen shot of the list so you can see it.

https://www.4cdesign.co.uk/wp-content/uploads/2014/09/Cron.jpg

Alan

[udadminKeymaster]

Hi Alan,

That’s good. If the cron system is generally working, then it’s likely that there’s just some other task that has a scheduled task, which accidentally deletes UpdraftPlus’s resumption of the backup. (WP’s scheduled task system has a design flaw which can cause this – it’s very rare). If you move the UpdraftPlus task by half an hour or so, then the problem will probably disappear… if it is another task doing this, then a slight move in the time will be enough to avoid it.

Best wishes,
David

[AlanParticipant]

Hi David, I think we figured out why the backup, or more precisely the upload to Dropbox, didn’t finish. It seems that the resumption (1) started while the original backup (0) was still running, so I think that’s why the resumption didn’t do anything. We could see in the logs that the resumption interval was something like 550 seconds. PHP’s max_execution_time was set to 1000, so we reduced that to 450, to make sure that the backup process is no longer running when the resumption starts.

However, I did another test today, and the backup again didn’t finish, so I checked the log file and I could see that the resumption interval was only 300 this time (while I somehow assumed this would be a constant value). So my question is, are we on the right track with our conclusions, and if so, how can we make sure that the resumption doesn’t start while the backup is still running?

[udadminKeymaster]

Hi Alan,

UpdraftPlus has various strategies to try to detect overlapping runs – checking filestamps, last database access timestamps. To comment on what’s up in your particular case, I’d have to see the log file. If you paste it to pastebin.com, or somewhere like that, then I should be able to say something useful.

Best wishes,
David

[AlanParticipant]

Hi David, here is the link to the log file:

https://pastebin.com/B2EKPQAa

[udadminKeymaster]

Hi Alan,

That particular log does not appear to have any resumptions in it… do you have one that manifests the problem?

Actually, probably best to wait 36 hours, for the UpdraftPlus 1.9.30 update to be available in your dashboard, in case any of the tweaks in that affect your case – if that doesn’t cause a problem.

Best wishes,
David

[AlanParticipant]

Hi David, that’s actually the problem, that there are no resumptions. In the log file it says “Scheduling a resumption (1) after 300 seconds”, but the initial backup run (0) took 455 seconds. So I assume that the scheduled resumption process (1) kicks in, but then detects that the initial backup process (0) hasn’t finished yet, so (1) just terminates without any further action. Do you think this is plausible?

So what I thought would avoid the problem would be to make sure that the resume interval has a larger value than PHP’s max_execution_time (which is currently set to 450 on our server), either by forcing the resume interval to be higher than 450, or changing max_execution_time to a value lower than the resume interval. Are these conclusions correct?

As already mentioned it worked with a resume interval of 600, so I wonder why this time it was only 300. Is there a way to set the resume interval manually? You also mentioned the upcoming update, would this address our problem?

[udadminKeymaster]

Hi Alan,

It’s not easy to untangle your post, because it makes some assumptions about UD’s internals and what’s meant to happen that aren’t right.

The fault in the log is that the resumption apparently never happens. It was scheduled:

0000.024 (0) Scheduling a resumption (1) after 300 seconds (1413904905) in case this run gets aborted

If it never happened, but was scheduled, then this would indicate that the scheduled task got deleted. This can happen if another scheduled task is scheduled at a very similar time. WP’s scheduling code has a number of race conditions in it. Try moving the time of your backup by 30 minutes, and the problem may go away. If not, then please post a new log.

Best wishes,
David

[AlanParticipant]

Hi David, I did some more tests, by starting the backup manually, and also checking that there are no other tasks scheduled at the same time (using the WP Crontrol tool), but again some of the backups failed because the scheduled resumption didn’t happen. Here is another log file:

https://pastebin.com/AC0mzQvA

You wrote that a scheduled task can get deleted if another task is scheduled at a very similar time, which seems to be a shortcoming of WordPress iself, but it makes me wonder how reliable the WP cron system then actually is.

On your website you describe another method where the backup can be run from the shell, so I thought this might be a better way because it would bypass timeouts and scheduled resumptions.

However, the client still needs to be able to set up the backup schedule in the admin interface, and also needs to do one-off backups sometimes, so I’m not sure if all of this would still be possible with the shell method.

[udadminKeymaster]

Hi Alan,

If you’ve got shell access, then you can set up a shell cron job. Or alternatively, you can use a service such as easycron.com to automatically call your PHP script via the web.

Best wishes,
David

[KeithParticipant]

Did you get this issue fixed? My UD backups are failing in a similar fashion, getting stuck on the Dropbox upload.

[KeithParticipant]

Think I just found and fixed the issue. There were some entries in the error logs:

[Wed Nov 26 00:10:57.258984 2014] [fcgid:warn] [pid 11019] [client xxxxxxxxx] mod_fcgid: read data timeout in 45 seconds
[Wed Nov 26 00:10:57.259027 2014] [core:error] [pid 11019] [client xxxxxxxxx] End of script output before headers: wp-cron.php

I upped the fcgi timeout as per this article:

https://kb.sp.parallels.com/en/121251

And now the backups are running and saving to Dropbox as expected.

[udadminKeymaster]

Hi Keith,

Thanks for sharing with.

This means that you gave PHP processes more time to run – which gave your backup enough time to succeed in one go. This doesn’t fix the root problem which you’re probably having, which is either that your WordPress scheduler is not working at all, or that some other task is coded badly and is trampling on UD’s scheduler entry for resuming the job where it was left off. Probably the latter, if your task was a scheduled one rather than a “Backup Now” one. But, if it’s working for you now with that solution, then that’s as good as any other!

Best wishes,
David

[Author]

Posts