Akeeba Backup for Joomla!

Tuesday, 13 April 2010 10:41 CDT

user9160

I have three backups that I use for our website.

Backup 1 - Daily backup of all databases
Backup 2 - Daily backup of all site files (no databases)
Backup 3 - Weekly backup of entire site (databases and site files)

I can successfully run all backups using the Backup Now from the back-end. Here's the duration and size of each:

Backup 1 - 2 minutes and 52 seconds (66.78 MB)
Backup 2 - 10 minutes and 8 seconds (1.98 GB)
Backup 3 - 1 hour and 26 minutes (28.22 GB)

Backup 1 runs fine as a CRON job. However, Backup 2 and 3 always fail to complete when run as a CRON job. Any idea why? Is there some setting I need to change to make these job run to completion as a CRON job?

I'm using the following syntax for bot the CRON jobs.

Backup 2 (/usr/local/bin/php -q /home/mysite/public_html/administrator/components/com_akeeba/backup.php --profile 2
Backup 3 (/usr/local/bin/php -q /home/mysite/public_html/administrator/components/com_akeeba/backup.php --profile 3)

Thanks.

Tuesday, 13 April 2010 16:22 CDT

dlb

Please zip and post one (or both) of the failed backup logs. That will give a clue as to what is happening.

Dale L. Brackin
Support Specialist

English: 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)

Wednesday, 14 April 2010 05:17 CDT

user9160

Ha ha! There's no log because the job fails!

Wednesday, 14 April 2010 05:24 CDT

dlb

There should still be a log file, the log is started before the backup job starts. If would fail faster than that if it couldn't write the log file and it would fail on a back end backup if it couldn't write the log. Only the log from the last backup would be available, previous logs would be overwritten.

Dale L. Brackin
Support Specialist

English: 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)

Wednesday, 14 April 2010 05:25 CDT

user9160

The log file I have in the target directory is the same date and time as the previous successful backup. So, apparently, the CRON job started the backup and then failed even before it had a chance to create a log file.

Wednesday, 14 April 2010 05:33 CDT

dlb

OK, I'll flag this for Nicholas to look at.

Dale L. Brackin
Support Specialist

English: 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)

Wednesday, 14 April 2010 05:38 CDT

user9160

OK.

What's really strange is the fact that there is an entry in "Administer Backup Files" but no files in the target location. I didn't think that was possible.

Apparently the database record for the backup job gets created first, then the job just fails.

Wednesday, 14 April 2010 06:07 CDT

nicholas

Indeed, at the very start of the backup run a log entry is created, so that you can track a backup which started but failed. When you visit the Akeeba Backup Control Panel any files from pending and failed backups get removed to avoid hogging your disk space and pending backups are then marked as failed. However, the log file should be available at the output directory defined in the respective backup profile's Configuration.

Anyway, given the length of the backup runs, I'd say that you are hitting a host limit. Some hosts allow CRON scripts to run for a limited amount of time, usually in the range of 3-10 minutes. Both your failing backup runs require much more time, therefore they fail. Please consult your host for a possible workaround.

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, 14 April 2010 06:11 CDT

user9160

Sorry...I'm not going to let you shift the blame to my provider. We use SiteGround, but we are using a dedicated server, so there aren't any limits that I know of, but I will ask them.

However, this backup used to function just fine when it was part of JoomlaPack. Plus, if the CRON job has a run limit of 3 minutes, we should see at least see some kind of truncated log file or truncated backup file. Right?

Wednesday, 14 April 2010 06:36 CDT

nicholas

The first paragraph of my last post details what happens with the backup run. As soon as the backup starts, it begins writing the log and the initial backup record. Combined with your reported issue it may mean:
1. You use the wrong CRON command line, therefore the backup never runs. Please report the exact command line you use (obscure the account name) if you want help with that part. I consider this unlikely as you say that the failed backup shows on the Administer Backup Files page.
2. You are using a different output directory for each profile, therefore you are looking inside the wrong directory. You can PM me Super Administrator access rights so that I can log in your site and check this out myself. This would explain why you see the backup record but not the log file.
3. Your output directory may be unwritable. This would explain why there is no log file, but wouldn't explain being able to backup from the back-end.
4. The timeout issue I already mentioned.
5. On severel shared hosting accounts there is a CPU usage cap. If you go over it, they kill your CRON script.

As you see, we can rule out 1 and 3. I trust that you have already checked #2 (if not, do so). Hence, it leaves me with #4 and #5. I didn't know which host you were on, so I proposed the most common cause of them two, the timeout.

Do note that JoomlaPack's CRON jobs worked entirely differently than Akeeba Backup Professional's command-line backup script. In JoomlaPack Plus the CRON scripts would simply call the front-end backup URL. It wasn't a new feature, it was simply what was described in our manual's "Front-end Backups" section. You can have the same thing with Akeeba Backup Core or Professional if you'd like. The difference this made was that the backup job was shared between many script runs, working around issue #5 and partially #4. Of course, I am not your host and I can't know if the script cancels because of a timeout or a CPU cap. It would really help contacting your host.

I recently had another SiteGround user email me details about a similar issue with the command-line backup tool. He did contact his host and all three of us figured out it was issue #5. The solution would be a (slower, less secure) CRON script which would access the front-end URL. I do plan on providing such a backup script in Akeeba Backup 3.0 Stable.

Does this still look like "shifting responsibility" or like a rational analysis to you?

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, 14 April 2010 06:50 CDT

user9160

Sorry about the "shifting responsibility" comment I made, but it just seems like I'm constantly battling all of the various Joomla component providers I deal with and when they can't figure out what's wrong, they go with the "Check with your provider." comment so I'm very defensive when I see that comment. And hopefully you can feel my pain a little bit because this backup used to work in Joomlapack. I understand you made changes to how this works for Akeeba, but it's hard for the end-user to understand sometimes why somebody would want to change something that was working just fine. Know what I mean?

Anyway, it looks like you may be right about the host limit. Here's what SiteGround had to say:

[indent]We do have a server checker daemon which monitors all processes running on the server and kills them if they are overloading the server. The CRON is running with your username and in order to resolve the issue I have inserted it in a list with protected users. Now all processes running with your username including the cron will not be killed unless the server load goes over 20 (which is critical value).

Please retest the issue and update this ticket if needed.[/indent]

So, I will fire the CRON script in a few minutes, and let you know what happens.

Wednesday, 14 April 2010 07:10 CDT

nicholas

I certainly feel your pain, as I've been in your shoes. I just wanted to point out that, unlike other component developers, I try to gather as much information as possible regarding a problem and analyze the situation before replying. I do this for everybody, paying or non-paying users.

Your host's response is consistent with the previous email communication we had through the other user I mentioned in my last post. In that communication, they tried helping us to set up the CRON job to run as soon as the server load reached 8. Unfortunately, this never seemed to happen and we were stuck. This was about 2 weeks ago. I will try to add the extra backup script to the beta release, even though it's a bit tight.

As a side note, I should mention that a server load of 20 is extremely high. Given that most servers have two quad-core CPUs, a server load of 20 translates to 250% over-utilization of server resources. This qualifies as "overcrowded". In comparison, our server's load (shared hosting on Rochen) is 1.91 with 8 CPU cores or a mere 25% utilization of server resources. You should keep this information in mind when choosing hosts for big sites with a lot of traffic.

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, 14 April 2010 07:20 CDT

user9160

I appreciate how hard you are trying to help me with this, and for the most part, Akeeba is really cool. The fact that I can at least run all these backups manually, is better than nothing.

So, there's good news and bad news.

The good news is that the change SiteGround made seemed to help. As the CRON job ran, I refreshed my FTP session and saw the log and backup file size grow until it hit the point where I thought it would finish (1.98 GB).

The bad news is that when it hit the expected file size and duration, the file disappeared and it looked like the backup "restarted" because the backup file returned to 0 bytes and then started growing again. I thought maybe the CRON job was stuck in a loop, but then it just stopped at 34.57 MB. I tried to attach the log file, but I got an error:

Warning: Smarty error: unable to read resource: ".tpl" in /home/jpack/public_html/components/com_agora/include/smarty/Smarty.class.php on line 1092

I don't have a PM account anywhere. Is there some other way I can deliver the log file?

Wednesday, 14 April 2010 08:13 CDT

nicholas

Did you visit the Control Panel while the backup was in progress? This would cause the "size reset" you describe. The other cause would be going over the 2Gb limit on a 32-bit machine, but since you told me that the backup completes from the back-end this can't be the case.

The easiest way for delivering the log file is using a free file hosting service, for example Windows Live Skydrive and share its URL with us. Please don't use RapidShare. I hate having to wait forever befire RapidShare will let me download the log file, if it doesn't throw some stupid pretext error, like its servers exceeding the free users cap.

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, 14 April 2010 08:19 CDT

user9160

After the backup looked like it restarted the file, I did visit the Control Panel, which is why the backup probably stopped. I'll try running the CRON job again, and I'll stay out of the Control Panel.

Wednesday, 14 April 2010 08:28 CDT

user9160

Here's the log file. After you download it, let me know so I can remove the folder.

http://cid-fdd93b2e49db36ff.skydrive.live.com/self.aspx/.Public/Akeeba/akeeba.log

Thursday, 15 April 2010 02:48 CDT

nicholas

Peter,

I just reviewed your log file. The backup is complete and finalized. This is very good, as it indicates that SiteGround adding you on their safe list really worked! Do you see the backup file in the Administer Backup files as complete?

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, 15 April 2010 05:20 CDT

user9160

In the Administer Backup Files page, the backup is still listed as "Failed". No duration is listed either.

Thursday, 15 April 2010 09:41 CDT

nicholas

Ah, this was a known bug in previous releases. I have fixed it in the latest developer release. You can download and use it. It is almost what we are going to publish on Sunday as our 3.0.b1 (beta) release.

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, 15 April 2010 10:21 CDT

user9160

OK, I'll check it out.

Also, you might want to disable your site pop-up (JoomlaPack has become Akeeba) now or at least configure it so it doesn't display for logged in users.

: )

Thursday, 15 April 2010 10:38 CDT

user9160

I installed Akeeba Backup Professional svn112 (2010-04-10).

1. The backup failed about 25% into the job (based on looking at the file size on the server). The date-time stamp on the log file was not updated and there's no duration listed.
2. I'm still seeing this error at the Control Panel: Notice: Undefined variable: origin in /home/decadeso/public_html/administrator/components/com_akeeba/models/statistics.php on line 174
3. I'm still seeing this error at the Administer Backup Files page: Notice: Undefined variable: origin in /home/decadeso/public_html/administrator/components/com_akeeba/views/buadmin/tmpl/default.php on line 186

Friday, 16 April 2010 04:00 CDT

nicholas

The popup will only show once on each of your first three visits. Remember that there are still some registered forum users who may not have logged in to the new site yet :) For logged in users, the popup display information is stored in the database, along with your user profile. For unregistered users - or before you log in - this information is stored in a browser cookie. If you browser doesn't accept cookies or if you switch browsers/computers, you'll end up seeing the pop-up as soon as you access any page of the site. Do you see the popup more than once per session or even after your third visit?

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, 16 April 2010 04:07 CDT

nicholas

And I just saw your other message. Ugh... I always miss the extra pages in the topics display, sorry.

Regarding the CRON job failure, be patient for 48 hours. I'll have the other CRON backup script (altbackup.php) which uses the front-end backup mode a la JoomlaPack Plus ready for release with the beta version. This should work correctly with your host.

The other two issues are the result of a single cosmetic bug. It will also be resolved in the beta. However, you should really set the error reporting level to E_NONE on your production site. You don't want everyone to see absolute paths to your site's files upon hitting a PHP notice.

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, 16 April 2010 05:40 CDT

user9160

Regarding the pop-up, I've seen it EVERY time I've been to your site, and I've been here probably 100 times.

How do you change the error reporting level?

And finally, after installing the developer version you recommended, ALL my daily CRON backup jobs failed. Even the small one that usually passes no problem.

Friday, 16 April 2010 05:48 CDT

nicholas

If you do not tick the "Remember me" check-box, the popup will reappear. Once you log in to the site, the cookie used for unregistered users gets deleted. So the next time you visit the site and you need to login, the popup comes back. However, if you do have the "Remember me" check-box ticked, please check that your browser accepts cookies from this domain (so that Joomla! can keep track of your session).

Regarding changing the error reporting level, this depends on your host set up. There are at least three ways (using .htaccess, using a per-directory php.ini and using the Error Reporting option in Joomla!'s Global Configuration). Please consult your host to find out which method is fit for your site.

Regarding the CRON jobs, please try changing the tmp directory. Do note that the issue I think we have to deal with is timing-sensitive, which simply means that the small CRON job running was a coincidence. Please follow my advice and post back the logs if it doesn't work. We can talk theory all day long, but I prefer resolving issues in practice :)

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, 16 April 2010 06:19 CDT

user9160

I was able to change the error reporting in the Global Config. Thanks.

Right now, I'm using [SITETMP] as the temp directory. That's always worked OK. If I change it, what should the directory permissions be?

Saturday, 17 April 2010 10:28 CDT

nicholas

Regarding the CRON jobs, please try changing the tmp directory. Do note that the issue I think we have to deal with is timing-sensitive, which simply means that the small CRON job running was a coincidence.

It is NOT a permissions issue! The directory you are using gets cleaned up on a preset interval, which causes the error. Please, chose a different directory. Just find the tmp directory inside your Joomla! installation (alongside media, images, logs, libraries, ...) and not the one inside your account's root which you are currently using.

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, 19 April 2010 06:28 CDT

user9160

I created a directory (/home/decadeso/public_html/backup_tmp) and gave it 755 permissions like the site tmp folder.

The backup failed again. No duration. No files created.

Monday, 19 April 2010 07:44 CDT

nicholas

Please, first read this for a quick run down on ownership, users and permissions. Since you have created the directory through FTP, you should give it 0777 permissions. Reading the linked page should clear this up for you.

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, 19 April 2010 08:15 CDT

user9160

Changed directory to 0777.

Backup still listed as failed in the back-end, but it looks like the backup files exist in the target location.

Tuesday, 20 April 2010 03:18 CDT

nicholas

The backup listed as failed should be fixed in 3.0.b1 released on Sunday. Which version are you using?

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, 20 April 2010 07:05 CDT

user9160

I upgraded to 3.0.b1. Backup failed again in the Administer Backup Files.

The CRON log makes it look like the job passed. I've put a copy of the log here (http://cid-fdd93b2e49db36ff.skydrive.live.com/browse.aspx/.Public/Akeeba?uc=1) for you.

One thing I noticed. I'm splitting the backup file at 1 GB because the backup in total is almost 2 GB. When I look at the target files on the FTP site, there's no .jpa file for the set. There's only a .j01 and .j02 file.

Wednesday, 21 April 2010 03:11 CDT

nicholas

Are you sure this is the correct log file? I can see that a single file is created (daily_site_files_backup-www.decadesoftware.com-20100413-095802.jpa), there is no archive splitting occurring here. Do note that this file was created a week ago, on April 13th, using Akeeba Backup 3.0.a5.1. Can you please send me the correct log? :)

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, 21 April 2010 05:12 CDT

user9160

You are looking at the wrong file. You were supposed to look at the cron_log.txt file. I will delete the other file so there's no confusion.

Wednesday, 21 April 2010 05:25 CDT

nicholas

The cron_log.txt tells me that the CRON job has finished successfully. I also need the Akeeba Backup log file to see if the finalization of the backup process has really run.

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, 21 April 2010 05:33 CDT

user9160

I have uploaded the latest akeeba.log file. Grab it here.

http://cid-fdd93b2e49db36ff.skydrive.live.com/browse.aspx/.Public/Akeeba

Wednesday, 21 April 2010 05:34 CDT

user9160

FYI. Both my backup jobs failed last night using the latest version of Akeeba. Even the small one.

Wednesday, 21 April 2010 05:40 CDT

user9160

Even though Administer Backup Files says the job failed, there are two files:

daily_site_files_backup--20100420-230004.j01
daily_site_files_backup--20100420-230004.j02

Thursday, 22 April 2010 06:58 CDT

user9160

Status?

Friday, 23 April 2010 03:15 CDT

nicholas

I did reply to you yesterday, but it looks like the post hit a black hole or something :(

The log file you have sent me is dated April 13th and it's made with 3.0.a5.1. I need the log file from the backup run which displays the problem in order for me to conclude what is wrong.

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, 23 April 2010 05:00 CDT

user9160

OK, I'll try to break this into small bites for you.

1. I have a scheduled backup that runs at 1 AM. The backup is of all the files on my site excluding one or two directories that contain a bunch of .wmv files.
2. Last night the scheduled backup ran and created two files: daily_site_files_backup--20100422-230004.j01 and daily_site_files_backup--20100422-230004.j02.
3. There is a log file in the same directory (akeeba.log) that is dated 4-19-2010, so I don't think it was updated by last night's backup. This would be a bug of some sort in your product I think. However, I have posted it to the previously mentioned Skydrive location.
4. When checking the Administer Backup Files page in your product, here's what I see:
Command-line backup 22.04.10 - Failed Command-line Site files only 2 - —

I really don't know what else I can do or what information you need from me. Maybe I just need to wait for the front-end backup you were talking about.

This backup job runs just fine when started manually from the back-end.

Friday, 23 April 2010 05:37 CDT

user9160

I take that back. Now the manual backup is failing, even for my small DB only job.

Here's the back-end error:

Couldn't write to the SQL dump file /home/decadeso/public_html/backup_tmp/44829fa3.sql; check the temporary directory permissions and make sure you have enough disk space available.

Note: I have unlimited disk space and my directory permissions are set to 777.

I renamed and copied the .log file to my skydrive. The file is titled akeeba_daily_all_db.log.

There is also a partial backup file in the target directory: daily_all_databases_backup-www.decadesoftware.com-20100423-073432.jpa

Friday, 23 April 2010 06:13 CDT

user9160

Hang on! I tried to access my cPanel at Siteground, and I got this error:

Sorry for the inconvenience!
The filesystem mounted at / on this server is running out of disk space. cPanel operations have been temporarily suspended to prevent something bad from happening. Please ask your system admin to remove any files not in use on that partition.

I guess I don't have unlimited disk space! Damn them!

I'll get back to you...

Friday, 23 April 2010 06:52 CDT

user9160

OK. After clearing up the disk space issue, here's what I did.

1. Uninstalled Akeeba.
2. Reinstalled the latest version.
3. Created a very simple site DB only backup.
4. Ran it manually: success!
5. Ran it via CRON. Failure.
6. No backup file created in output directory. I've uploaded the .log file to Skydrive.

Saturday, 24 April 2010 01:02 CDT

nicholas

OK, the host's disk space issue explains the erratic behavior you described in your last posts. Now, back to the regular flow of issues :) I reviewed your log file and, still, SiteGround kills the script while it is backing up. However, I have a workaround for you.
[ol]
[li]First upgrade to the latest developer's release.[/li]
[li]Go to Akeeba Backup's Control Panel and click on the "Parameters" icon on the top right corner (in the toolbar below the Joomla! menu)[/li]
[li]Enable the front-end backup feature and type in a secret word of your liking. Then click on the Save button.[/li]
[li]Modify your CRON job and replace backup.php with altbackup.php[/li]
[/ol]

The altbackup.php script is using a completely different approach for CRON backups. Unlike backup.php, it doesn't call the backup engine directly. Instead, it uses the front-end backup feature. This causes your host to detect minimal CPU load caused by the CRON script (altbackup.php) - as the heavy lifting is performed by the front-end backup feature, running under a different process - so that it won't kill it. Remember, your host was killing backup.php before completion because it detects that it causes an increased CPU load! I have tried this with another SiteGround user with some success. Hopefully it will also work for you. If not, post back with the new log file and - if available - your host's CRON task log, which is usually emailed to you when the CRON job finishes.

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!

Saturday, 24 April 2010 01:04 CDT

nicholas

As a side note, regarding your comment "No backup file created in output directory" there are two causes:
1. When you do a DB only backup, the SQL dump is first written to the temporary directory and then copied to the output directory when the backup is finalizing.
2. When any type of backup fails, visiting the Control Panel will do a clean up. Part of the clean up is removing the failed backup's temporary and output files.

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, 28 April 2010 13:37 CDT

user9160

I did what you told me to do, and even the front-end backup fails. I've uploaded the backup log and CRON log to the Skydrive.

Wednesday, 28 April 2010 13:42 CDT

user9160

And just to let you know, the manual back-end backup works fine.

Wednesday, 28 April 2010 23:56 CDT

nicholas

Peter, have you upgraded to 3.0.b2? There was a critical bug in the front-end backup which I have fixed. See the release notes here. I think you are affected by this bug.

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, 29 April 2010 07:38 CDT

user9160

I upgraded to 3.0.b2 and everything is working OK with the frontend backup. Cool.

Just wondering...how come we have to provide a secret word, but then not use that in the parameters for the CRON job?

Thursday, 29 April 2010 11:23 CDT

nicholas

It is used, internally. Since the CRON script is on the same server as your site, it just reads your configuration.php, connects to the database, queries the component parameters, reads the secret word and uses it. It also reads your site's URL from the database. Whenever you visit Akeeba Backup's Control Panel, the site's URL is cached in the database so that the CRON script (which runs in CLI mode and can't know the URL to your site!) can figure out the front-end backup URL. It's my job to make all of this absolutely transparent to you. All you need to know is that it works (and that makes me very happy, too) :)

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, 29 April 2010 11:51 CDT

user9160

Unfortunately, I configured a more complex backup (All configured databases (archive file)) and it failed. The log is on my Skydrive.

Friday, 30 April 2010 23:43 CDT

nicholas

You have a very big database dump (around 73Mb). Adding such a big file to the backup archive may cause problems. I suggest turning on the database dump splitting option: go to the configuration, click the "Configure..." button next to the "Database dump engine" and set the part size for SQL dump splitting to 2Mb. This should split the database dump to many files (.sql, .s01, .s02, ....), adding one small file at a time in the archive, which should work around any issues.

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, 03 May 2010 05:48 CDT

user9160

OK. I'll give that a try.

However, I have a new problem. Over the weekend, my second backup (site files only) ran four times, and the .jpa file is in the target location, and everything seems to be fine. For some reason, though, each backup is listed as "Obsolete" in the Administer Backup Files page. It's as if the backup completes, but no record is written to the database. Any ideas?

Monday, 03 May 2010 06:01 CDT

user9160

I used the SQL dump splitting for my backup job. Here's what the CRON log reported.

[2010-05-03 11:00:01] Beginning backing up
[2010-05-03 11:00:02] Backup progress signal received
[2010-05-03 11:00:04] Backup progress signal received
[2010-05-03 11:00:15] Backup progress signal received
[2010-05-03 11:00:27] No message received
ERROR:
Your backup attempt has timed out, or a fatal PHP error has occurred.
Please check the backup log and your server's error log for more
information.

Backup failed.

Monday, 03 May 2010 11:41 CDT

nicholas

Regarding the obsolete status, it means that the backup ran, completed and the backup file is no longer on your site. If you are using one of the post processing engines (DropBox, Amazon S3, move to remote FTP) this is normal. By default, all those engines have the "delete after processing" option turned on, which will delete the server copy of the backup archive once it is post-processed (sent to the cloud service or uploaded to the remote FTP server).

Regarding the second issue, I will need the log file. There is a timeout, which isn't normal. Maybe you have to try using a lower maximum execution time setting (around 7 seconds should do it). If this still doesn't help, I will definitely need the log file to be of further assistance.

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

Akeeba Backup for Joomla!

#8406 Some CRON Backups Not Working

This is a public ticket

Environment Information

Support Information