Support

Dear Akeeba Support,

This issue is almost identical in symptoms to a ticket posted last August:-

https://www.akeebabackup.com/support/akeeba-backup-3x/17041-configuration-wizard-failure-and-backup-failed.html

It's not clear from that thread how the OP's issues were resolved. Plus, the difference between that and our circumstances is that our cPanel log doesn't report errors for non-existant Akeeba plugins.

Problem description

Any attempt to run the configuration wizard yields:-

Configuration Wizard Failure



Akeeba Backup could not find a writable output and temporary directory. Please give write permissions to the administrator/components/com_akeeba/backup directory and run this wizard again.

Manual configuration appears to work just fine.

Any attempt to run a backup yields:-

AJAX Loading Error

HTTP Status: 403 (Forbidden)

Internal status: error

XHR ReadyState: 4

Raw server response:

Forbidden

The 'percentage done' varies from attempt to attempt, suggesting a timing/server load issue rather than anything with the file system.

Diagnostics performed - filesystem

I coded a PHP script that writes a test file to the administrator/components/com_akeeba/backup directory. I can confirm that this succeeded.

I coded another PHP script that recurses through the entire file system, and flags up messages for any file that has permissions other than 644, or any directory that has permissions other than 755. I confirm that no directories were flagged up (and the script was tested by manually altering a directory picked at random). A small number of files were flagged up; I can list these if required.

As yet I've not completed an exhaustive analysis of .htaccess. I'm not an expert in the format of this file, so this area of fault-finding is on-going.

Disk space usage is currently just under 95Mb of 75Gb. I have purposely uploaded (via the cPanel file manager) approx 40Mb of test files, and I can confirm that these file were correct when downloaded again via HTTP URLs.

Other than any .htaccess weirdness, I don't have any explanation as to why the configuration wizard would object to not having a writeable output and temporary directory.

Diagnostics performed - timing

I coded a PHP script with a couple of nested for () constructs to create a tight loop of CPU time wasting.

I can confirm that via set_time_limit() I can easily run for 60 seconds or more. No apparent Zen server constraints interfering with heavy script load.

I have manually experimented with the execution-related config options as discussed here:-

https://www.akeebabackup.com/support/akeeba-backup-3x/14800-configuration-wizard-failurefailed-backup.html

to no avail. Backups still fail.

One last clue?

As a test I did change the backup type to 'database only'. This consistently works, and only when I change back to 'full backup' do backups then consistently fail.

This could be symptomatic of either a file system issue or a timing issue of course.

I'm currently out of ideas. Suggestions welcome.

Well you sure didn't leave me much in the way of easy answers! It could be a host limit on maximum file size created by a script. The Config Wizard would be testing that, but should trap the error and use the information, not crash. When you hit the max file size in the backup, you get the 403 because it can't write to the backup archive. It's a good theory, but not without its share of quirky little things that don't fit.

Let's try to reduce the part size of the backup. You can find that under Configuration, in the Archiver Engine configuration. We want to set it to something pretty small, 50 or 100 Mb. We're testing at this point, not fixing.

Hi Dale,

I'm a techie - I know how irritating "it doesn't work" (with no other clues) can be :)

I've selected 49.99 for "part size for split archives". Chunk size and big file threshold are left as they were - both 1.00.

Testing now...

Sadly that didn't work, nor did reducing the part size to 5.00.

OK, please upload the new log file. I'll see if there is any new information in it.

New log attached. This is from a backup attempt a few minutes ago, with the JPA part size still set to 5.00.

It is possible that your server thinks the backup is an attack. It can kinda look like an attack, lots of database activity and it hits every file on the site, all very fast.

Please edit your backup configuration and use these timing settings:

min execution time 15 seconds
max execution time 10 seconds
runtime bias 75%

This will slow the backup down and make it look more like normal activity. We're trying to fool your host's security settings.

Done, and hurrah - it worked!

Took an age though, as one might expect. Log from that run attached for your inspection should you need it.

As I type I'm trying a second run with min = 10 secs, max = 5 secs, bias = 75%. These are bit plucked from the air I confess, and I'd welcome suggestions on how to arrive at the best compromise between speed of backup, and backup actually working :)

I tried the configuration wizard again, and this still fails. Similar issue - server security measures getting in the way?

I don't think you want to reduce your max setting, just reduce the min setting until it fails again. I don't have any insight on where it will fail.

You might discuss the problem with your host, they may be able to white list the backup and fix it that way. Note that a back end backup, CRON backup and front end backup would all use different php programs.

If you set the backup as a CRON job and run it overnight, the length of time it takes doesn't matter as much.

OK - I shall fiddle and report back. (And are we keeping the JPA part size small - currently 5.00, or restoring that setting to default?)

With regard to the wizard, that query was just an aside out of interest. If we can get backups completing within a reasonable time frame via manual configuration, the wizard becomes a bit academic.

I'm sorry, no we don't need to keep the small part size for the archive. That was not the problem.

The Wizard is running into the same problem as the backup is. It is trying to test your site to see where the limits are and that activity looks suspicious to your host's security setup. The Wizard is designed to set optimal settings, but optimal won't work for you so the fact that the Wizard won't run is not too important.

OK, part size reset to 0.00, and I've experimented with various min settings.

8.0 seems to be the threshold. At this setting a backup takes approx 1 hour 10 mins; anything less than 8 and the backup will fail fairly early on.

This will suffice as an interim solution - especially if I cronify it. I may speak to Zen about what can be done to speed things up, but that's no longer a priority.

Thanks very much for your help with this Dale. Two remarks in particular were appreciated - "We're testing at this point, not fixing" and " We're trying to fool your host's security settings." - showing your thought processes.

May I suggest that the that the thread mentioned in my opening post:-

https://www.akeebabackup.com/support/akeeba-backup-3x/17041-configuration-wizard-failure-and-backup-failed.html

is modified to link to this discussion, such that others having this problem might resolve their issues quickly.

Feel free to consider this ticket closed at your convenience.

Thanks again,

Andrew
http://www.barefoot-software.co.uk

Andrew,

You are welcome! I'm glad we got it worked out.

I'm not going to link the threads because this is an unusual solution. Various host restrictions are pretty common, but security settings are not high on the list. You really had eliminated a bunch of easy answers before you asked. Most folks having a similar problem would have to start a little farther back. :-)