Support

Description of my issue:

Hi there,

I run a cron job to perform a backup every night, with the intention to upload the archive to Google Drive.  The problem I have is that despite splitting the archive into 512MB parts (of which there are usually 5), only the first two or three parts get transferred to remote storage.  This leaves the .JPA, .J01 and J02 files on Google Drive, with .J03/4/5 still on the server.

The log is set only to record Errors and Warnings, and is empty.  The job completes without any issue, but the transfer to Google Drive seems to be timing out.

Should I reduce the size of the archive parts to 100MB - or smaller?  Or there is an option to "Process each part immediately" - perhaps I should tick this?

I have checked your documentation - and there doesn't appear to be a lot relating to this issue.  I apologise if I'm missing something, but any advice would be appreciated.

Best regards,

Ben

Ben,

The first thing we need to do is get a full backup log.  That will tell us what is really happening to the upload.  Change your log level to "All information and debug" and let your CRON job run overnight.  Then zip and post the log.

My guess is that the host is killing the CRON job after x number of seconds.  That's not uncommon.  But there are other things that could be happening, we need the full log.

Thanks, Dale.  I'll generate the log tonight and upload the copy when done.

Morning Dale,

I've attached the log file from last night's backup.

It shows the successful transfer of the first split-archive file (JPA), but the remaining files (01-05) have stayed on the server. Processing seems to stop part of the way through the second transfer (.j01).

One of the options in the profile's configuration is "Disable step break in finalisation" - which is ticked.  Would it make enough of a difference to un-tick this?

... this time, an attachment without spaces ... :-)

Let's untick "Disable step break in finalisation".  I'm not sure that's going to fix it, but let's try it.

The backup is going along, happy as a clam, then it abruptly stops.  When there's no error in the log that usually means that something outside the backup killed the job - "The host did it."  It is very common for the host to kill a CRON job after x number of seconds.  That is to keep runaway jobs from hogging server resources.  But in this case, the job stops after 3:38, which is an odd elapsed time for the host to kill it.

In the Fine Tuning section of the backup Configuration, make sure the "Resume backup after an AJAX error has occurred" is checked.  That will retry the backup after an Ajax error.  I think we should get an error in the log if that was it.  I'm using the fact that it doesn't resume as a clue, we'd better make sure that resume is turned on.

Hi Dale,

Sadly, the process still borks after the second transfer, so I'm left with the 4 remaining archive parts of the server.  I think you're right about the server killing the process.  I found this article (albeit, written for a Wordpress plugin) on the Siteground knowledgebase:

https://www.siteground.com/kb/why-backup-budy-can-fail-send-backups-remote-server/

It explains that a server will kill a backup process when attempting to transfer files via FTP.  I think it's safe to assume that they do the same with transfers using other remote storage.

Thanks very much for your help.  I think I'll have to resort to transferring the files manually.

Many thanks,

Ben

Ben,

Yes, that's exactly what I was thinking.  Siteground absolutely kills CRON jobs.  Depending on the hosting plan you have, they may extend the limit for the job.

Even if they won't, you still have options.  You need to go to a front end backup, which can be triggered from a third party service like Webcron.org.  They are not a free service, but they are pretty cheap.  There are others out there, Webcron.org is the one I've used personally.

You don't really need an outside service, any computer powered on when you want to trigger the backup can do it.  In Windows, it is a Scheduled Task.  In Linux the CRON service is native.  You can even use a Raspberry Pi to trigger the job.

Excellent - thank you.  That's really helpful.  I'll try and get this up and running over the next day or two and let you know how it goes.

Thanks again.

You're welcome!

Hi Dale,

I tested with webcron.org - and it worked, from start to finish, without an issue!

I then tested the 'alt' backup CRON script too - from a CRON job - and that worked too.  So all sorted - thanks!

You're welcome!