Support

Salve,

non ho effettuato nessun cambiamento.
Mi sono solo limitato a guardare la lista dei plugin installati e a diagnosticare il problema relativo all'estensione che effettua l'ottimizzazione.

Akeeba Backup viene eseguito solamente nel momento in cui si effettua l'accesso nella pagina specifica o quando un backup viene lanciato. In questo caso il problema è generato da un'altra estensione non da Akeeba Backup.

Sinceramente non saprei, comunque le lascio aperto questo ticket.

Può allegare il log del backup fallito eseguito dal backend?

credo che il processo di backup venga terminato direttamente dal server dopo circa 3 minuti di attività o quando vengono utilizzate troppe risorse (CPU, RAM ...).

Per ovviare a questo problema utilizzi le seguenti impostazioni:

• Spunti l'opzione Client-side implementation of minimum execution time (in Configuration Base)
• Tempo di esecuzione minimo: 5
  Temp di esecuzione massimo: 3
  Tempo di esecuzione stimato: 75
  
  Esatto, il tempo minimo è maggiore di quello massimo, non è un errore di battitura

Il processo di backup sarà molto più lungo, ma in questo modo non dovrebbe sforare nell'utilizzo di risorse.

Applichi la soluzione suggerita e provi di nuovo.

Allora abbiamo trovato il colpevole :)
Deve parlare con il suo hosting: molto probabilmente hanno impostato una regola per cui se il solito indirizzo IP accede alla solita pagina più frequentemente di X secondi, la richiesta viene bloccato.
Se tale intervallo è maggiore del tempo impiegato da ogni step del backup, l'IP viene bloccato, da qui l'errore 403.

Per esempio, se l'intervallo minimo è 4 secondi e ogni step impiega 2-3 secondi, accedendo nuovamente il webserver blocca la richiesta.
Purtroppo noi non possiamo fare nulla, deve parlare con l'hosting.

Hello Germani,

I don't understand Italian, but Davide provided me with a summary of your conversation. I was gobsmacked by the answer you got from your host, considering that it's completely uninformed and misleading.

Akeeba Backup 3.6 was released over two years ago. Any claim that its documentation is still relevant(!!!) must be met with unmoderated skepticism towards the professionalism and intelligence of the person who tells you to consult it. Not to mention that we never mentioned that our software has any problems with mod_security2. That was an arbitrary conclusion from the person reading the ancient version of our documentation.

Furthermore, Akeeba Backup has absolutely NO PROBLEM with a properly configured mod_security2 installation on the server as it is evident from our own site, both in our current host (SiteGround) and our former host (Rochen). It should also be noted that mod_security2 BY ITSELF does nothing more than parse rules defined BY THE HOST to block requests. It is entirely up to the competence of THE HOST to create mod_security2 rules which do not kill legitimate applications and only block malicious request. Both our former (Rochen) and current (SiteGround) host are more than competent and were able to do that over many years.

Our suggestion in our documentation to reduce the maximum time of the backup to 10 seconds only has to do with the maximum execution time imposed in php.ini. When you filed your ticket Davide asked me to take a look at the log file, I understood that your host was doing something really bad, hence his suggestion to tweak the time settings. Our conclusion that your host has misconfigured their server was further corroborated by your next log files. Your host seems to be blocking the IP addresses which call similar URLs more often than X seconds using a mod_security2 rule. I cannot be sure of the value of X, but my educated guess (based on what I read in your log file) is around 10 seconds. This is a bad rule. It is TRIVIAL for your host to add an exception for the VERY PREDICTABLE AJAX endpoint URL (/administrator/index.php?option=com_akeeba&view=backup) in their mod_security2 rules.

These three facts (referring to ancient documentation, not knowing what mod_security2 does, having no idea how to add mod_security2 exception rules) only point to one thing: your host's staff lacks competence in configuring live servers. When we had a similar issue with Rochen some 5 years ago it took exactly 3 minutes for them to fix it. Three minutes. I think that says everything there is to be said about your host. Maybe it's time to move to another host, one whose staff actually knows how to configure their servers?

Germani, I already know what is going on. It's not the first time we've seen this. In fact, I can tell you exactly what happened without reading your host's reply. Your host installed mod_security2 on their server and they're using a pre-packaged set of rules for it, most likely Atomic ModSecurity Rules.

One of these rules tells the server to block the IP address of the remote party who's trying to connect to the same URL within a specific period of time. Considering that you are running a backup which does EXACTLY THAT it is fairly reasonable that this rule kills your backup. A good host doesn't need this rule. A so-and-so host will have the time limit on that rule very low, e.g. 3 requests in 1 second. A crappy host has a high time limit, e.g. 2 requests in 10 seconds. Your host sits squarely in the crappy category. We CAN work around this rule on so-and-so hosts. That's what the time settings given to you by Davide do. We CANNOT work around crappy hosts without making your backup stupidly slow. If you want, though, you can try the following:
- Client-side implementation of minimum execution time: checked. THIS IS VERY IMPORTANT!
- Minimum execution time: Custom... then set to 30 seconds
- Maximum execution time: 5 seconds
- Execution Time Bias: 75%

Your backup will run, but it will be eight times slower. Is this practical? I don't know.

For your information, disabling mod_security2 itself or specific rules per domain (virtual host) is trivial and very well-documented. I don't understand why your host insists that they can't do that. It doesn't take a genius, it only takes reading the fine documentation for, like, 5 minutes! I am a developer, not a system administrator, and I already know that stuff. Keep in mind that it's their job to know this, this is why they are being paid for. It's not my job knowing system administration procedures. It should tell you something when I know what's not my job better than them, the people who's their job to know this stuff!

If I were you, I'd move that site to a decent host today. If you're looking for a good host, try SiteGround. They even give 3 months of free hosting to Akeeba Backup users. If you do try their hosting please come backup and tell me if you noticed the profound difference in the load time and if you're now wondering why you were hosted with that awful Netsons host until now.

It's exactly the issue we've already described.

Look. This is an issue caused by bad server setup inflicted to you by your host. You and us have spent over 10 man hours discussing this. The completely crazy thing is that your host needs LESS than 5 MINUTES to fix it. If they refuse to fix that the only solution is to take your site and move it to a decent host, asking for a refund for the amount of time you couldn't stay with them because of their denial to fix an obvious and DEAD SIMPLE TO FIX issue with their servers.

No matter how many more times you ask us, there's absolutely nothing more we can do. We have identified the problem, we have multiply verified it, we have explained the problem to you along with the ways we have verified it, we have told you what your host can do to fix it and that if they don't want to do it you have to find a different host. We can't do anything else and, in fact, you've agreed that we are not to do anything more (it's in our Terms of Service, under Support Policy). For this reason I'll have to close this ticket reminding you of the only two courses of action available to you:

1. Ask your host to spend all of five minutes to fix their mod_security2 rules.
or
2. Move to a decent host.