Support

Akeeba Backup for Joomla!

#40240 Attempt to restore from backup results in 403 error

Posted in ‘Akeeba Backup for Joomla! 4 & 5’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

Joomla! version
4.4.2
PHP version
8.1.27 (probably)
Akeeba Backup version
9.8.5 (probably

Latest post by nicholas on Tuesday, 06 February 2024 00:37 CST

wd5mush

EXTREMELY IMPORTANT: Please attach a ZIP file containing your Akeeba Backup log file in order for us to help you with any backup or restoration issue. If the file is over 10MiB, please upload it on your server and post a link to it.

I am locked out of my site when attempting a site restore.

This morning I logged in to my admin area and noticed a batch of extension updates were available.  Before installing them I did a backup (thank goodness!)

I installed some without any obvious problem, but one resulted in the Joomla red screen (

Sorry, there was a problem we could not recover from.

The server returned a "500 - Whoops, looks like something went wrong.")

So I decided to roll back and restore using the backup I had just made.  That seemed to run to the point where I had to click the run the restore script button.  When I did that I received a 403 Forbidden error and I am now unable to access any part of the site - back or front end.

Rather than me mess around experimenting (I suspect this might involve the .htaccess file) and risk messing things up even more, can you please point me in the right direction.  My site is now down and that is not good!

Where will I find the Backup log file?  I will need to use ftp to gain access while the site is down.

nicholas
Akeeba Staff
Manager

First, delete the .htaccess file. Remember, this file is included in your backup and can be regenerated using Admin Tools.

If this doesn't help, you will have to restore the site again. You can use Kickstart (see this video). The backup archives are stored in the backup output directory you have chosen, the default being the administrator/components/com_akeebabackup/backup directory under your site's root. You can even tell Kickstart to look in there so you don't have to copy your backup archive into your site's root.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

wd5mush

Good morning Nicholas and thank you for the advice.  I deleted (actually renamed) the .htaccess file and the recovery worked as you hoped and my site is now active again.

The key question now is 'What went wrong?'  I have been using Akeeba Backup for the best part of 13 years and have got to know my way around reasonably well.  Fortunately I have not had to restore a backup very often, but when I have it has worked fine.

This is the first time it has not and I am wondering why. 

  • The front end and back ends were working OK before I did the extension updates;
  • I did a backup using Akeeba Backup Pro 9.8.4 before I started to install extension updates;
  • I installed AB Pro 9.8.5 (one of the updates) successfully;
  • Another extension I tried to install failed and gave a 500 error message on the front end, but I still had access to the back end;
  • I decided to roll back so was using 9.8.5 to restore a 9.8.4 site.
  • Restore worked with file recovery but failed with the restore script.
  • Nothing here that suggests I made a change to the .htacess file.
  • The only change I have recently made to my installation that might have impacted the .htaccess file was a week or so ago when I added a temporary Super User to the site.  That has been used and worked OK.

Up to now I have had complete confidence that I can recover my site if I mess things up.  If it happens again I know what to do, but this has all the feel of a bug rather than an expected behaviour.

Any ideas? 

nicholas
Akeeba Staff
Manager

I can tell you that whatever the problem was before it was not due to the restoration, assuming that what you say about running the restoration to completion is accurate.

The .htaccess file is part of the backup archive itself, unless you explicitly excluded it from the backup. Since you did not say anything like that, I assume you did not do that.

When extracting the backup archive, the backed up .htaccess file is extracted as htaccess.bak. When you complete the restoration and click on the Clean Up button, one of the actions performed is renamed htaccess.bak back to .htaccess.

It does not even matter if you are using Kickstart or the integrated restoration in Akeeba Backup's Manage Backups page. You are using Kickstart both times. The integrated restoration is a Joomla UI skin of Kickstart with a lot of the more advanced options hidden away.

What could have gone wrong? Plenty.

First of all, if there was another file named htaccess.bak then the .htaccess included in the backup archive maybe could not be extracted. This is not a fatal error, and the restoration will proceed. However, when renaming whatever random htaccess.bak file at the end of the restoration back to .htaccess you may be renaming a file which doesn't quite work.

Renaming the htaccess.bak to .htaccess may also have not worked, depending on the ownership / permissions. You get a warning about that, but it's easy to miss when you've restored sites thousands of times and stopped paying attention at the final displayed message.

It's also possible that you chose to remove the .htaccess during restoration, or replace it with the default Joomla! file. Since your host puts the code to activate a specific PHP version and will use the default (usually very old) PHP version if this code does not exist, you may have simply ran into the simple case of trying to access your site under a PHP version it's not compatible with.

When you get an access denied error, just delete the .htaccess file, go into your hosting control panel, choose the correct PHP version (if it's not already selected) and access the site's backend. If that works, you can regenerate the .htaccess with Admin Tools' .htaccess Maker since you're already using it. The reason I had you redo the restoration is that I had no idea what exactly you had tried so far and I wanted to remove all variables. I could not know if you had an extraction issue, or didn't run the restoration to completion, or had a permissions issue you didn't catch, or missed a message. Having you redo the restoration more carefully now that you were asking me for help would ensure that any such issues would be caught, reported back to me, and I could help you. Apparently your issue was far easier and I could have told you to just regenerate it, but as I said I wanted to remove all variables.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

wd5mush

Thanks for that explanation, much appreciated.

As the site is now working having used the restored files it's not possible to see exactly what went on.   Up to the point where I tried to restore the backup I had made only some 30 mins before all was working fine - other than the red screen that resulted from a problem updating another plug-in.

The restore went through its normal recovery process of unpacking the files until it reached the two button option to run the restoration script.  When I clicked the proceed button (using the right hand option,  not the special one) I got the 403 error.  So, I presume that at that point something changed the content of the .htaccess file.

After receiving your advice I used my hosting company's file manager.  Rather than delete the .htaccess file I renamed it fred.htaccess.  I do seem to recall seeing a .htaccess.bak file in the directory at that point, but cannot be sure.

After doing that I browsed to the site - although it took me directly to the restore page. As you say, it is a screen I recognised from kickstart, and I followed that sequence through to successful completion.

Checking the root directory I see my fred.htaccess file is still there, but there is no .htaccess.bak

So the key question is still, assuming the 403 was the result of an issue with .htaccess, why did it only show half way through the restore and not before or since?  I suppose I ought to try another restore and see what happens.  Perhaps tomorrow...

nicholas
Akeeba Staff
Manager

The restore went through its normal recovery process of unpacking the files until it reached the two button option to run the restoration script.

What are you talking about? There's only one button: "Run the Installer". See https://www.akeeba.com/documentation/akeeba-kickstart-documentation/the-setup-page.html

The only time you see two buttons is if you finish the extraction, click on Run the Installer, go through the entire restoration process, go back to Kickstart, and click on Clean Up. At this point your .htaccess file has changed as per my previous reply.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

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!