Support

Akeeba Backup for Joomla!

#20003 Backup completes but "times out"!?

Posted in ‘Akeeba Backup for Joomla! 4 & 5’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

Joomla! version
n/a
PHP version
n/a
Akeeba Backup version
n/a

Latest post by nicholas on Thursday, 08 May 2014 11:08 CDT

user65904
EXTREMELY IMPORTANT: Please attach a ZIP file containing your Akeeba Backup log file in order for us to help you with any backup or restoration issue. If the file is over 2Mb, please upload it on your server and post a link to it.

Description of my issue:

Backup fails / times out during post processing. The backup file is actually transferred successfully (haven't yet tested a restore since this problem). The problem seems to affect both backend and command line backups. Zip archived logs are attached for both. Also attached is a screenshot of what appears after a backend-initiated backup times out. This hasn't been 100% consistent, but most of the time outs happen 120 seconds into post processing (120s since server's last response). A few times, the time out occurred at 240 (double 120) seconds, and a time or two, some other number.

I've already (unsuccessfully) tried your suggested settings.

Minimum Execution Time: 5 seconds
Maximum Execution Time: 3 seconds
Execution Time Bias: 50%

I've also tried various other Min/Max execution time settings, small split sizes, etc.

Here is an example of (the last of) what appears if I manually run the backup from the shell:

Last Tick : 2014-05-06 15:39:35 GMT-0700 (PDT)
Domain : finale
Step :
Substep :
Memory used : 7.02 Mb
Warnings : no warnings issued (good)

Backup job finished successfully after approximately 6 minutes

===============================================================================
!!!!! W A R N I N G !!!!!

Akeeba Backup issued warnings during the backup process. You have to review them
and make sure that your backup has completed successfully. Always test a backup with
warnings to make sure that it is working properly, by restoring it to a local server.
DO NOT IGNORE THIS MESSAGE! AN UNTESTED BACKUP IS AS GOOD AS NO BACKUP AT ALL.

===============================================================================
Peak memory usage: 9.03 Mb

dlb
It isn't the timing settings this time, it is the file size. You have a single 45.7 Mb backup archive. It is too big to transfer before you hit the php timeout limit. You need to adjust the configuration, Archiver engine, and split the archive into parts. Cut it down to 19.9 Mb and see if that allows you to finish. If so, you can try to increase it to give you a two part backup. If not, you need to go even smaller.


Dale L. Brackin
Support Specialist


us.gifEnglish: native


Please keep in mind my timezone and cultural differences when reading my replies. Thank you!


????
My time zone is EST (UTC -5) (click here to see my current time in Philadelphia, PA)

user65904
I don't think file size or max_execution_time (900s) are the problem. As indicated in my original post, I already tried splitting the archive. Attached is a log from a recent attempt with a split size of 2 MB. It still times out 120 seconds into post processing. With a low split size such as 2 MB, a single (2 MB) split file is transferred. If I leave the split size higher than the backup file size, the single ~44 MB backup archive is transferred, but post processing "times out" at 120 seconds. Here is what I see immediately before the screenshot included with my original post/attachment.



Thank you,

--
Ron

dlb
OK, I agree, not the part size. Has this ever worked? If it has never worked, then the next thing to look at is the upload path in the ftp setup. That can be really tricky. If it worked and quit, then we're looking for something that changed.


Dale L. Brackin
Support Specialist


us.gifEnglish: native


Please keep in mind my timezone and cultural differences when reading my replies. Thank you!


????
My time zone is EST (UTC -5) (click here to see my current time in Philadelphia, PA)

user65904
Hi Dale, did you see this from my previous post?

If I leave the split size higher than the backup file size, the single ~44 MB backup archive is transferred, but post processing "times out" at 120 seconds.


The archive is transferred successfully in post processing. To make sure the transferred archive isn't corrupted, yesterday I successfully tested a local (not to the live site) restore.

Concerning changes, the site was recently moved to DreamHost and SSL enabled for the Joomla control panel (backend). I tested a backup with SSL disabled and that made no difference.

dlb
I asked Nicholas to take a look at this.


Dale L. Brackin
Support Specialist


us.gifEnglish: native


Please keep in mind my timezone and cultural differences when reading my replies. Thank you!


????
My time zone is EST (UTC -5) (click here to see my current time in Philadelphia, PA)

nicholas
Akeeba Staff
Manager
Unfortunately nothing can be done about this particular case :( The remote FTP server doesn't signal the upload completion back to your server. As a result PHP never tells Akeeba Backup that the transfer is complete and Akeeba Backup sits there, waiting to be told the transfer is complete until a server timeout kills it.

PS: Using HTTPS on your web site is completely inconsequential to the FTP upload. The FTP and the web server are two entirely separate programmes.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!