Support

If you set the session timeout in your Global Configuration to 1400 minutes does it solve the issue?

When you load the backup page, we ask Joomla to give us the session token. This token is sent with every request made to the backup endpoint to prevent cross-site request forgeries. This is exactly what Joomla itself does when you are creating or editing anything in the backend such as users, articles, banners, and so on.

The message you get is essentially coming from Joomla. We ask it to check the anti-CSRF token in the request against the session token. If there is a mismatch, we ask it to show its standard "The security token did not match. The request was cancelled to prevent any security breach. Please try again." error message.

My thinking seeing your backup log file showing just under 5 minutes of backup going on is that despite the multiple requests made in that time the session expired which would explain the token mismatch. That wasn't the case.

I have follow-up questions to better understand what could possibly be happening.

1. Is your site behind a CDN?
2. Are you using any kind of caching on your site?
3. Can you create / edit articles using your site's backend? It is very important that you try that right before and right after you try a backup; don't respond from what you remember being able to do.
4. Were you trying to use other pages after displaying the Backup Now page, but before clicking the button to start the backup?

Thank you for checking those. Ruling out a CDN and caching narrows it down a lot.

I need to explain what this message really means, because it's misleading here. Akeeba Backup checks a security token at two points. The first check runs when the backup starts, against Joomla's own anti-CSRF token. That's what I was suspecting and having you check.

The second runs on every later backup step, against a separate token that Akeeba Backup creates when the backup starts and keeps in your Joomla session.

Both checks show the same Joomla message when they fail. Based on what you already checked, and the fact that the backup log you posted earlier shows the backup running, the first check very likely passes. Therefore, I am now operating under the assumption that it's the second one that fails. It would also explain why changing the session timeout made no difference: this isn't the Joomla session expiring.

There are two ways the second check can fail:

1. The server does not keep the token in your session between the first request and the next one. This depends on how your server stores sessions. It is the most likely explanation when the same site works on one server and not on another.
2. The very first backup request fails on the server, for example because IIS stops the PHP process when it hits its FastCGI time limits. Your browser then never receives the token. Akeeba Backup automatically retries the step a few times, and each retry fails the token check. By the time you see an error, the real error has been replaced by the token message.

To tell which one it is, please do the following.

1. Go to System, Global Configuration, Server and look at Session Handler (under Session Settings). Please tell me what it is set to on your production site and on your staging site. Also tell me if Shared Sessions is enabled on either one.
2. In Akeeba Backup, click Configuration and find the Fine tuning section. Set Resume backup after an AJAX error has occurred to No and save. Then try a backup again and tell me the exact error message you get. If the message is different now, that is the real error.
3. If you can, open your browser's developer tools (F12) and go to the Network tab before clicking Backup Now. When the error appears, find the first request with ajax=start in its URL and tell me its HTTP status code and what it returned. Please also tell me whether the request that failed contained ajax=start or ajax=step.
4. Go to View Log, choose the log of this latest attempt and zip it. Then attach the ZIP file to your reply.
5. Did backups work on this production server with Akeeba Backup 10.3.6 or earlier? If you upgraded straight to 10.4.0 from an older version, which version was it?

Once I have this I can tell you exactly what goes wrong and how to fix it.

Given that using a different browser worked, I am inclined to believe that this is a problem either with the browser itself, or with a browser extension you are using. If the same request to start the backup is sent twice but only the result of the first request is passed back to JavaScript we end up with a disparity between the backup token saved in the session, and the one communicated back to JavaScript.

I am solving that for the next version by not issuing a per-backup-session token, instead using Joomla's session token – and also giving you a control to disable the anti-CSRF token check on configurations much more broken than yours.