Support

Akeeba Backup for Joomla!

#14278 Frontend backup fails, component parms reset to default

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 Wednesday, 05 December 2012 12:46 CST

user357

Mandatory information about my setup:

Have I read the related troubleshooter articles above before posting (which pages?)? Yes
Have I searched the tickets before posting? Yes
Have I read the documentation before posting (which pages?)? Yes
Joomla! version: 2.5.8
PHP version: 5.3.16
MySQL version: 5.5.27
Host: Media Temple
Akeeba Backup version:3.6.9
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: Frontend backup fails.

I have just started to use the cron job for backing up my sites and then moving the backups to Amazon S3.  It works fine for 3 of the sites, but for some reason, it is failing on one site.  Backing up the site from the backend works fine.

One very weird thing is that the Component Paramters keep being reset to the default (Enable front-end and remote backup, Secret Word, etc.).  I noticed this yesterday and not matter how often I set the parameters, they would be reset when I opened the parameter dialog.  I even manually set the JSON string in the database with the correct values, but when I brought the dialog up, the parameters would be reset!

So I ended up just setting the parameters and leaving them.  Accoridng to the log, the cron job ran overnight but the control panel indicates that the backup failed.

I've attached the frontend log, I can also send the backend log if that would help.

nicholas
Akeeba Staff
Manager

First try uninstalling and reinstalling the component. The fact that the settings are not being retained tells me that something strange is going on.

Regarding the scheduled backup, I don't see any error in the log. After about an hour the process simply stops. This is most likely because of the CRON daemon doesn't allow CRON jobs to run over an hour.

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!

user357

Ok. I just uninstalled and installed 3.6.10.  Now when I try to save the components parameters, I get the message: Could not save data. Error: The database row is empty.

On the CRON daemon running out of time, I was able to run the job successfully via the cron in my initial testing.  I've now excluded the .git directory as well as some database tables that are not needed so hopefully that will reduce the time it takes to backup the site.

One of the main critical tables is over 1gig.  I'm running a backup now, and it is taking much longer than I expected.  I'll post the log file when/if it completes!

 

 

 

nicholas
Akeeba Staff
Manager

Huh? The SQL error doesn't make any sense. Do you have any records in your #__ak_profiles table? There should be at least one record with an id = 1.

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!

user357

yes, there is the one record in the ak_profiles_table.

I went through the troubleshooting steps and was able to make some progress. After saving the result of the configuration, the 'Could not save data...' message does not appear when saving the component parameters.  Unfortunately, the parameters are still not saved???

I just got back from lunch and noticed that the last backup attempt from the backend failed with:

 

AJAX Loading Error
HTTP Status: 0 (timeout)
Internal status: timeout
XHR ReadyState: 0
Raw server response:
undefined

I've attached the log file from that run.

One thing that may be causing the problem is that we at 90% of our alotted disk space on our server.  That is one of the reasons we are trying to move as much stuff as possible to S3.

nicholas
Akeeba Staff
Manager

If you are tight on disk space try setting the Part size for split archives to something low (I suggest 10Mb) and set the Process each part immediately option. I also recommend checking the "Disable multipart uploads" checkbox.

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!