Support

We could not reproduce this on a clean test site, so I think the cause is something specific to your site or server, but I cannot tell what it is yet. Both screenshots show a “500” error, and your server hides the actual error message by default. We need to see that message.

Please do the following:

1. Turn on full error reporting temporarily.
   • Go to System → Global Configuration → Server tab and set Error Reporting to Maximum.
   • Go to the System tab and set Debug System to Yes.
   • Save, then reload Akeeba Backup’s Control Panel, or start a backup, and wait for the error.
   • Copy the full error message and stack trace that now appears, or take a screenshot of it, and attach it to your next reply.
   • Afterwards, set both options back to what they were. They can show technical details to your visitors, so please don’t leave them on.
2. Check the server’s PHP error log. Look in your hosting control panel (the “Errors” page, if you have cPanel) or for files named error_log in your site’s root folder, in the administrator folder, and in administrator/components/com_akeebabackup. Send me the last few lines from the time you got the error. If you can’t find any, ask your host for the PHP error log entries for the exact time of the failure.
3. Tell me when the backup last worked, and what changed on the site or hosting since then. For example, a new or updated extension, a Joomla update, or a PHP version change.

Technical information

I tested with a clean, new install of Joomla 6.2.0, PHP 8.5.12 and MariaDB 11.4.13 (the same database version as in your log), and Akeeba Backup Professional 10.4.0. The Control Panel loaded normally and a full backup ran to completion through the same AJAX requests the Backup page uses, with no errors.

Our test setup differs from yours in ways that could matter. It uses Apache, while your log says LiteSpeed. It runs the default backup profile, with no third-party extensions installed and the interface in English.

Your backup log shows the first two backup steps worked: Akeeba Backup started and prepared the backup without problems. The log stops there. The next request failed before Akeeba Backup wrote anything to the log. In the Control Panel screenshot, the error text is Joomla’s own “Sorry, there was a problem we could not recover from” page. This suggests that PHP or Joomla hit an error while handling the request, rather than a firewall rejecting it. I can’t tell what caused it without the actual error message, so I can’t say whether it is related to Akeeba Backup, another extension, or the server.

I consider it OUTRIGHT IMPLAUSIBLE that the PHP vulnerabilities have anything at all to do with this, as I have already explained (mind you it's a long post; about 2400 words). To make a long story short, the impact and exploitability of this vulnerability have been blown completely out of proportion. There's no publicly known working exploit yet. The only exploits witnessed in the wild are merely stage 1; they don't get stage 2 which is code execution. It's a bit like having a gun, a bullet casing, and gunpowder, but no actual bullet, just a wad of paper. It's still scary and stings a bit, but it can't kill you even in point blank range.

What I cannot discount is the possibility that your own host may have hastily done something unadvisable, e.g. applying mitigations and patching PHP which is simultaneously pointless and site-breaking, as I have explained in the same news article I linked above.

It might also be a very mundane problem we've seen before: a badly compiled version of PHP is crashing hard ("dumps core" as we used to call that back when). The latter case would mostly fit your description as it may not leave a trace in the virtual host's error log (what you see), only in the main Apache error log (what your host sees), depending on virtual host configuration.

A combination of all of the above would actually fit your description very well. Part of the mitigation is disabling PHP error exception backtraces, which makes it impossible for Joomla to show an error screen with the exact problem and code location when PHP code fails. Since it's an unconditional check, it might lead to a hard PHP crash under certain circumstances, which would lead to a 500 error page from your host. It's a stretch, but it's a plausible explanation.

As a side note, the PHP warnings you get are not from our software, they're from the NovaRain Framework which is used by Tassos' extensions. We're one country over to him, and a completely different company :)

I would very strongly recommend setting Error Reporting to None and Debug Site to No – the recommended production site values. Then, contact your host and ask them to check the error. This will work best if you record the exact date and time you get the error, as it will let your host narrow down their search within the Apache and PHP log files to just a few dozen to hundred lines. Their investigation becomes more like finding a book in a bookshelf than a needle in a haystack.

Try updating the extensions which were updated in the problem site, but were not yet updated in the site you restored. Do it one at a time, trying to take a backup after each extension update. This will tell you if it was a problem with an extension update. The only thing that would fit the shape of your issue is a third party extension having a buggy Joomla form prepare content plugin handler: since the Backup Now page is a Joomla form, a broken third party handler throwing an error would indeed break that page.

If this is not reproducible, it would appear that an extension update did not complete all the way. This would also fit the third party form content prepare handler issues I mentioned above. A partial update would have resulted in the otherwise fully functional code used by a third party extension for such a handler to no longer work correctly because of missing files, or one or more PHP files being stuck in an older version. Yes, Joomla may do a partial update; it's fairly rare, but not impossible. I have seen it on my own sites twice in twenty years, and about once a month in my clients' sites (law of large numbers and all that). The solution in these cases is simple, and frustrating: install the same updated version twice in a row, without uninstalling it before or in between.

You're welcome! Have a great day!