Support

Akeeba Backup for WordPress

#28680 – Ajax error, backup fails to complete

Posted in ‘Akeeba Backup for WordPress’
This is a public ticket. Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.
Tuesday, 31 October 2017 00:48 CDT
webcoast
Hi, my Akeeba Backup is failing on my site, it is a new install and has never backed up successfully. I used the configuration wizard, and it is setup to copy the backup file to Amazon S3 on successful completion of the backup.

See attached screenshot.

I went to configuration and updated the maximum execution time to 5 seconds (minimum is 2), but it is still failing.

I have about 750meg of free disk space, so it shouldn't be that.

I tried to analyse the log file, but it never completes analysing - I have raised this as separate support ticket in the past, but it has been automatically closed without resolution. Attached is the log file too.

Thanks
Nicola

p.s. I looked at my last support ticket about the analyse log never completing, and saw that you suggested to adjust minimum execution time to 5seconds, maximum to 3 seconds, and execution time bias to 50%, so I made these changes on this site and the backup completed successfully. Now my question is... why isn't the configuration wizard picking up on this, and making these adjustments?

Custom Fields

WordPress version (in x.y.z format) 4.8.2
PHP version (in x.y.z format) 7.1.10
Akeeba Backup version (x.y.z format) 2.4.0Pro
 
Tuesday, 31 October 2017 03:37 CDT
nicholas
Hello Nicola,

First let me address your issue and question.

The log analyzer uses an engine similar to the backup engine. It tries to parse the log file by breaking the process in many steps, each one being a separate page load. I believe that in both cases the process is interrupted because the server is blocking requests from your IP address because it believes that you are using too many resources. There is no solution for that. In the end of the day there is an absolute minimum of work which has to be performed, an atom of work if you want. If your server cannot process this absolute minimum amount of work when we are parsing the log file there's nothing we can do on our end.

Regarding the Configuration Wizard, it is designed to detect hard, deterministic limits imposed by the server. Resource usage-based IP blocking, which is what you're experiencing, is stochastic in its nature. The non-deterministic way Linux kernel, the virtualization layer and automatic resource usage-based IP blocking works on your server makes it impossible to reliably identify the exact conditions that cause an automatic IP block. Moreover, the same non-deterministic processes involved in getting this result make it impossible to reliably reverse the problem to a set of time settings which will definitely work on your server. The best way to deal with that is trying three different sets of timing options (max/min/bias): 10/1/75 (fast), 5/3/50 (slow-ish) and 3/5/50 (snail pace, the one you used). If neither works then you need a very experienced developer with a system administration background (me) to take a look.

Even though I could go on and on about this, I don't think it makes sense. If you want a taste of how complicated things are, when you are using a virtualization layer (all modern servers do) the rate at which you read files may cause memory exhaustion despite having a hard limit of the filesystem cache size because the garbage collection process which clears the RAM used by filesystem cache doesn't have the time to run. Even though that sounds like something straight out of Simon's (the infamous, fictional Bastard Operator From Hell) calendar I can assure you that it's totally true and took me a good half day to debug two months ago. In the end of the day adding a half second delay between backup steps and shortening the backup step length to under 5 seconds gave the damned server enough time to clean the filesystem cache and not run out of RAM while taking a backup. It also improved the performance of the server during the backup. That's the level of non-determinism we are talking about.

Now, regarding your complaint about tickets. I am always alarmed when I hear that our clients think that they didn't get adequate assistance, so I went looking through all your tickets from the past year. I can't find one which is closed without resolution. Every ticket of yours I read from the last year ends up with you telling us that the solution is accepted, or us telling you that your suggestion will be discussed (it was not a ticket about a problem) or me telling you to contact Watchful about an issue that was on their end (and they subsequently told me they fixed). If you have a ticket which you believe was closed in error please tell us. All the tickets automatically closed after 30 days of inactivity send you an email reading "This ticket has been automatically closed. All tickets which have been inactive for a long time are automatically closed. If you believe that this ticket was closed in error, please contact us". Tell us which ticket you believe was closed in error so we can understand where the communication problem was.


Nicholas K. Dionysopoulos

Lead Developer and Director



🇬🇷Greek: native

🇬🇧English: excellent

🇫🇷French: basic



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



Tuesday, 31 October 2017 04:02 CDT
webcoast
Hi Nicholas,

Thanks for your excellent (once again) reply.

Based on your reply it seems like my current server has resource issues, it is a bit baffling to me, as I host with Rochen on a managed cloud server, and I only seem to have issues with Wordpress sites. Coming across from Joomla, which I much prefer I must say, I am finding Wordpress clunky and slow. I have lots of Joomla sites running on the same server and have never had any issues with resources affecting the backups. However clients seem to want Wordpress so I have to build in that these days. As you know I have been using Akeeba Backup for years and years and years, and love it. On Joomla it works out of the box, yet on Wordpress on my configuration I have to adjust those settings down to "snail pace" to get it to work. Oh well, maybe that's just how it is.

Regarding the tickets closed, I received 2 automatic closure emails recently. One was for #28509 – Analyse Log never completes, and yes you are right, the issue of the backup not completing was resolved, but until your response today I didn't really have any explanation of why the analyse log wasn't completing, so as far I was concerned that issue was still a fault. So your answer today answers that ticket too. The other ticket that I had an automatic closure for was #28484 — "New Version (Update Available) not showing in dashboard". That one wasn't really a support ticket though, it was more of a feature request, I think you were away at a Joomla conference at the time.

I am extremely happy with the support that I receive from you guys, and am usually totally blown away by the detailed reply that you give my tickets. I don't know whether you have a massive resource of standard replies, because otherwise it must take you ages to write each response, and I appreciate that.

With kind regards
Nicola
 
Tuesday, 31 October 2017 04:36 CDT
nicholas
Hi Nicola,

If you are on a Rochen shared host or if you have dozens of sites on a fairly standard managed virtual server (MVS) then you do have some very strict resource usage limits. All shared hosting / virtual server platforms do that by necessity. It doesn't help that WordPress lacks any kind of sensible caching, unlike the latest versions of Joomla! 3.

WordPress performance is, indeed, not very spectacular. Especially when compared with Joomla! 3.8 on a modern server (PHP 7.0 or later) I can see how WordPress is lagging behind. The myth that WordPress is faster mostly comes from the era of PHP 5.2 and Joomla! 1.5 where, indeed, WordPress was much faster owning to its much simpler internal architecture. However, as newer versions of PHP are optimized for running more complex code and Joomla! gets much more serious about its internal architecture the scales have tipped.

I would argue that as far as clients go, it's our job as technologists to guide them to what is best for their use case. If they have a blog and they want to own the comments WordPress is a must have. If they want a simple shop then maybe WordPress with WooCommerce is better than Joomla! and VirtueMart or HikaShop. If they want a simple business portfolio with no interactivity, no maintenance burden and seldom updates something like Grav or even an off-line static generator like Jekyll (with the site possibly hosted on Amazon CloudFront) would make more sense to them. If they want something more complex and extensible Joomla! is the right tool for the job. If they want a big, complex e-commerce site then PrestaShop or Magento are worth the hassle. If they want a forum and nothing but a forum phpBB3 is a much better fit than Joomla! and Kunena. It's all about specifications and expectations. If your clients demand WordPress remind them what Henry Ford (allegedly) said about faster horses.

Regarding the tickets it was not clear that on the log analyzer ticket you were expecting a reply about the log analyzer. Both me and Davide thought your goal was to get the backup running. Now it makes sense. Please accept our apologies. The other one is indeed a suggestion that's why there was no further reply :)

Now, regarding the backup. You could try some different settings and see if we can get it to run. Always talking about max/min/bias settings, I'd first try 10/2/50. If my suspicions are right it will die very fast. Then try 5/4/60. If that fails go for 5/5/50. If that still fails, sorry, you'll have to use the snail pace settings.


Nicholas K. Dionysopoulos

Lead Developer and Director



🇬🇷Greek: native

🇬🇧English: excellent

🇫🇷French: basic



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



Thursday, 30 November 2017 17:17 CST
system
This ticket has been automatically closed. All tickets which have been inactive for a long time are automatically closed. If you believe that this ticket was closed in error, please contact us.
This ticket is closed, therefore read-only. You can no longer reply to it. If you need to provide more information, please open a new ticket and mention this ticket's number.

Support Information

Working hours: Typically we work Monday to Friday, 9am to 7pm Cyprus timezone (EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets, but we cannot respond to them, outside of our working hours.

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!