Akeeba Backup for Joomla!

Wednesday, 04 May 2011 13:16 CDT

kkevents

Mandatory information about my setup:

Have I searched the forum before posting? yes
Have I read the Troubleshooting Wizard before posting? yes
Have I read the documentation before posting? yes
Joomla! version: 1.5.23
PHP version: 5.2.17
MySQL version: 5.1.52
Host: Hostgator.com
Akeeba Backup Professional version: 3.2.7

EXTREMELY IMPORTANT: Please attach your Akeeba Backup log file in order for us to help you with any backup or restoration issue.

Description of my issue:

I am getting the could not detect live site url error using altbackup.php on a shared server. I have attached a backend backup log. I have tried going into the config and saving as stated in a previous thread, I also ran the config wizard, and enabled the front end backup and secert word.

Edited by kkevents on 2011-05-23 18:49 CDT

Wednesday, 04 May 2011 13:37 CDT

kkevents

It just occured to me that I am using ACEsef and that may be the problem. I disababled ACEsef for Akeeba and the frontend feature seems to work fine, the cron is due to start in the next 30 min. so I will see if it works now

Wednesday, 04 May 2011 14:09 CDT

kkevents

The front end backback via putting it into the browser works, but frontend from the cron still gives me the livesite error:

Akeeba Backup Alternate CRON Helper Script version 3.2.7 (2011-04-17) Copyright (C) 2010 Nicholas K. Dionysopoulos
-------------------------------------------------------------------------------
Akeeba Backup is Free Software, distributed under the terms of the GNU General Public License version 3 or, at your option, any later version.
This program comes with ABSOLUTELY NO WARRANTY as per sections 15 & 16 of the license. See http://www.gnu.org/licenses/gpl-3.0.html for details.
-------------------------------------------------------------------------------

Unsetting time limit restrictions.

ERROR:
This script could not detect your live site's URL. Please visit Akeeba
Backup's Control Panel page at least once before running this script, so
that this information can be stored for use by this script.

BACKUP ABORTED DUE TO CONFIGURATION ERRORS

Wednesday, 04 May 2011 20:00 CDT

nicholas

Please try logging out of your back-end, logging back in, goint to Akeeba Backup's main page, click on Administer Backup Files, click the Back button in Joomla!'s toolbar, try a hard browser refresh (SHIFT + click on the Refresh icon in your browser) and retry taking a backup.

As far as I can see, some servers refuse to save the necessary live site URL parameter the first time you visit Akeeba Backup's main page. Every time I tried to debug this, doing the above nonsensical procedure worked. The funny thing is that the code which stores the live site value to the component's configuration parameters is always the same and always executed every time you visit Akeeba Backup's main page. Ugh!

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!

Wednesday, 04 May 2011 21:14 CDT

kkevents

I tried that and that also did not work still getting the same error with the altbackup.php cron

Thursday, 05 May 2011 16:52 CDT

nicholas

I will have to take a look at the way component configuration parameters are stored as soon as I get back from the J and Beyond conference.

Right now, the only workaround is to manually edit your database with phpMyAdmin, find the jos_components table, find the com_akeeba row and edit the contents of the params field. It's in INI format (lines separated by newlines, each line in the format key=value). Find the one starting with siteurl and edit it so that it reads

siteurl=http://www.mysite.com/

where www.mysite.com is your site's domain name.

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!

Friday, 06 May 2011 15:51 CDT

kkevents

Well I tried your instrctions again and it worked! Perhaps I didn't do it quite right the first time. I know when it has finally taken hold as on six of my sites when I did properly the site takes forever to load and eventually comes back with a JFTP error, then I know it has finally taken hold of the live site. Strange, but it seems to work....Thanks for your time. I will let you know if I encounter any further issues.

Friday, 06 May 2011 19:22 CDT

nicholas

Yes, that's a really strange one. It doesn't make any more sense to me than it does to you. It's always the same code running, with different results (and it doesn't even do anything funky).

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!

Sunday, 08 May 2011 00:33 CDT

kkevents

I tried again on my other sites and the cron runs according the cron notification email:

Unsetting time limit restrictions.

Starting a new backup with the following parameters:
Profile ID : 1
Backup Method : curl

[2011-05-08 00:00:03] Beginning backing up

But it does not complete, I have it set every halfhour to test, but so far nothing I have done seems to work to get it to complete.

I'm not sure if it is due to me moving all my sites from bluehost to hostgator or if something else is going on. But so far only the one site is working, the others are as above. Not sure what is differnt on the others, I will see if I can figure out any differnces between all of them.

Sunday, 08 May 2011 19:04 CDT

nicholas

Can you please also post the log file from the "Front-end" origin? Without it I can't really know what is going on.

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!

Monday, 09 May 2011 11:26 CDT

kkevents

Here is the frontend log that I ran via the browser front end

Tuesday, 10 May 2011 06:43 CDT

nicholas

The log file didn't make it through :( Please try to put it in a ZIP file and attach the ZIP file with your next post. If you still do not see the log file after attaching it, please upload it to DropBox or Windows Live SkyDrive and paste the link here so that I can take a look at it.

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!

Tuesday, 10 May 2011 17:49 CDT

kkevents

let see if it comes through this time

Wednesday, 11 May 2011 11:13 CDT

nicholas

According to this log file, the backup finished in 15 minutes and 47 seconds (from 10:30:10 to 10:45:57). It is, indeed, the backup log file from your front-end backup as it says on this log line:

Saving Kettenrad instance frontend

(the "frontend" part means that it is using the front-end backup URL which is exactly what altbackup.php does). I also see that post processing took place and an email was sent to you (or, at least, whoever cs at your domain is). So, according to the log, everything works all right.

Do note that the date I see on the log is May 9th. If you tried on a later date and it didn't work, it is because the script could not establish reliable communications with your server, maybe because the live site URL recorded wasn't correct. In that case, please try using the latest developer's release which fixes this issue.

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!

Wednesday, 11 May 2011 11:30 CDT

nicholas

One thing I forgot to mention... You can always try using backup.php instead of altbackup.php. That one is doing a fully native backup job, without calling Joomla! and should work much more stable.

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!

Thursday, 12 May 2011 01:23 CDT

kkevents

I originally tried the backup.php which works for backup, but the host restrictions prevent it from running long enough to transfer via FTP. So I tried using the altbackup.php which works on one site but not the rest. They are all on the same server. That's why I can't figure out why they don't work on the others. If I run the front end backup my self it also works fine. Just not from the albackup.php cron.

Thursday, 12 May 2011 02:33 CDT

nicholas

When you are using backup.php and altbackup.php you are bound by the restrictions imposed by your host:
- How long a CRON script is allowed to run. Most shared hosts restrict that time limit to 3 minutes. Anything taking longer will be killed, so no backup can be taken. In this case you can ask your host to put your account in the "safe list" so that you can run longer CRON jobs.
- PHP setup. The CLI version of PHP has a different configuration file than the one used by the web server to serve PHP pages. This may mean that certain features are not available, making it impossible to perform a backup.
- Networking setup. On some servers it is not possible to do a "loopback" connection, e.g. you can't access a URL of www.example.com from the server that hosts www.example.com. This can be caused a myriad of things, DNS address resolution being the common issue. The only thing you can do is to ask your host if such a thing is possible.

If all else fails, you can try creating a CRON job with wget/curl and the front-end backup URL as outlined in the documentation. Do note that, even in this case, it is still possible for your host to kill the CRON job if it exceeds 3 minutes. When that happens the only way to work around it is to ask your host.

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!

Thursday, 19 May 2011 22:30 CDT

kkevents

I spoke with my host and they looked at the cron job and script and they said it was being killed automatically due to that is was consuming more than 30 seconds of CPU time with the altbackup.php, I am sure it is due to the size of the site as the smaller sites backup more quickly and complete just fine even with FTP to my off site server. Is there a setting that would breakup the backup in way to prevent this time out?

If not is the desktop feature viable for a workaround? I always leave it on.

Friday, 20 May 2011 03:38 CDT

nicholas

altbackup.php acts as a supervisor. It calls the front-end backup URL repeatedly until the backup is complete. The backup is split to many steps, but you have to somehow have them run! The only alternative that I can give you is to use the front-end backup URL with wget to achieve the same result, as documented in this section of our documentation. The idea is that instead of having a PHP script to step through the backup, we use wget or curl to do that, as they are both not bound by time limitations.

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!

Monday, 23 May 2011 18:48 CDT

kkevents

The wget seems to be working and solved my problem! Thanks!

Tuesday, 24 May 2011 02:37 CDT

nicholas

You're welcome!

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