Support

There are two ways to do that. For both, you need to extract the backup archive using Kickstart. The easiest way to do that is running Kickstart on a local server (MAMP, WAMPServer, ...) or a subdomain of your se.

Now, we have two options.

The easy option is to run the restoration. When you reach the Database page enter the information of the database into which you want to restore the table. From the right hand side, check the "Select which database items to restore" option. You will see a list of tables. Select the one you want to restore and click on Next. Only this table and its contents will be extracted; everything else is ignored. When this is done, just delete the installation folder. You can read the documentation for the option I mentioned in https://www.akeeba.com/documentation/brs/database.html 

The second and significantly more complicated option is explained in https://www.akeeba.com/documentation/akeeba-backup-joomla/unorthodox-emergency-restoration.html.

When I had a use case similar to yours I used the first option. The second option is literally the last resort. It is a major pain and requires going through dozens or hundreds of files. I would only use that for an ancient site which requires a PHP version I no longer have access to.

This backup archive was not taken with Akeeba Backup 10.0.0. The interface looks like what we were using between 2017 and 2024. You must've taken the backup with an older version which did not have that option in the restoration script. Do remember, the restoration script is placed into the backup archive at backup time.

Therefore you either go with option 2, or you proceed to restore the backup archive in a new database and then you can use phpMyAdmin to get the table you want.

When you submitted this ticket you specified the Akeeba Backup version used as 10.0.0. Please note that for obvious reasons I cannot know what you are using and what you are doing beyond what you share with me. If the information you share with me is inaccurate, so are my replies.

When you sent me the screenshot of what you see it was obvious to me that the information you provided was inaccurate. The giveaway is the checkboxes on the right hand column, telling me that you are using a version of the restoration script released between 2017 and 2024. The new restoration script that's included in backup archives created by Akeeba Backup 10 have sliders, not checkboxes, for toggle options. Akeeba Backup 10.0.0 was released today, February 18th, 2025. The previous release of Akeeba Backup for Joomla was 9.9.11 released on November 21st, 2024. You can see the release history in https://www.akeeba.com/download/akeeba-backup.html. So, as I said and as you confirmed, you have indeed NOT used Akeeba Backup 10 to take this backup archive. You had used an older version which lacked the option.

The Kickstart version is irrelevant. Kickstart, as it tells you every time it runs, is only used to extract the backup archive. As I explained in my previous reply, the actual restoration script is put into the backup archive at backup time.

Therefore, as I told you in my previous reply, you cannot follow the instructions about restoring just the one table. The reason of course being that your backup archive was taken with an older version of Akeeba Backup which does not have the necessary option in the restoration script included into the backup archive.

As a result, you have two options.

One option is the emergency manual restoration which I still consider a last resort and won't tell you to use.

The other option is what you are trying to do. Restore the backup archive in a different server, or subdomain, and definitely a different database than your original site. After you restore your site, you can use phpMyAdmin to locate the table you want, export it, and then import it into your original site's database.

Most likely your problem is #6 in https://www.akeeba.com/documentation/brs/ts-database.html 

As to why you get a 404 Not Found instead of a 403 Forbidden, that has to do with the server config. The server is set up to use custom error pages. However, the specified HTML file for the custom 403 error page does not exist, therefore you get a very confusing 404.

Please contact your host. Ask to escalate to level 2 directly, since this is not something level 1 can handle. Ask the level 2 technician to identify why the POST request to /installation/index.php results in a 404 response. Most likely he'll find a mod_security2 rule; ask them to disable it. While you are at it, also ask them to disable custom error pages for your site since they get in the way of troubleshooting without adding any value to you.