Support

Akeeba Backup for Joomla!

#38647 NON-URGENT - Clarification of Site Restoration Issues

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.2.8
PHP version
8.0.27
Akeeba Backup version
9.5.0

Latest post by nicholas on Friday, 03 March 2023 01:55 CST

Wednesday, 01 March 2023 16:38 CST

[email protected]

Hello,

I have experienced two issues during some site restoration efforts. I was hoping to get some clarification or suggestions to avoid them in the future:

My Process:

-Upload backup archive to target site

-Run kickstart

Observations:

1.) When specifying a different database prefix than the original server, during the site restoration process. I noticed that everything appeared to function correctly. I then found that I received an error message in  System>Plugins when I published or unpublished a plugin. The message displayed was something like: "database.gna_extensions table could not be found". Apologies but I did not capture a screenshot of the exact message. I verified that Joomla was indeed using the new prefix in System>Global Configuration>Server>Database. I assume that Joomla would not allow me to login if the table prefix was not functional.

However, the plugin showed that it was either published or unpublished. I am not sure if this is a cosmetic error and the plugin was successfully published or unpublished.

After receiving this message, I did another restore operation and used the same table prefix as the original server. The issue was not present. It should also be noted that I used a different database for both attempts. The issue seems tied the table prefix.

 

2.) Over the past two months I have done a lot of restore operations for development and testing. I have discovered that after each restore operation, The Smart Search Index is corrupted and needs to be re-built. In addition I need to reconfigure any existing search filters to have the correct document types and categories selected. Do you have any ideas as to why Smart Search Index doesn't work after a restore?

 

Thanks in advance for any advice or tips!

Eric Johnson

Thursday, 02 March 2023 02:18 CST

nicholas

1. Changing the table prefix is something that is fully supported and fully functional ever since JoomlaPack 1.0.0.b1 back in October 2006. Joomla can work perfectly fine after changing the database prefix. All the tests we run on Akeeba Backup include changing the database prefix. In fact, we do a daily restoration of this site here on our dev server changing its database prefix. Every week we restore at least half a dozen client sites to troubleshoot issues, all of them changing the database prefix. If there was a problem there we'd have caught it before anyone else.

The question is, did you exclude the #__extensions table from your backup? If so, it would explain why you have a problem. If not, it's possible that you simply had a corrupt table. All this based on the partial information you have provided.

A full error message, especially with Debug Site set to Yes, would help more. Maybe there is a third party plugin which does something funky.

2. The Smart Search index is never backed up. After restoring your site you are supposed to rebuild it. This might also affect your Smart Search filters, especially if they were created with a different set of enabled Smart Search plugins and/or different priorities for these plugins.

If you would rather back up the entire Smart Search index set “Skip Finder terms and taxonomy tables” to No in your backup profile's configuration. WARNING! This will make the backup desperately slow. A site of mine which used to be backed up in 14 seconds would take over half an hour backing up Finder (Smart Search) tables. Restoration time also increases. Do keep that in mind, especially if you have a really big index.

Further to that, I have observed that at around 20,000 indexed items Smart Search starts taking way too long to return results. At 100,000 items it's practically useless, taking 15–20 seconds to return a reply. In my opinion, Joomla would make more sense if it just discontinued Smart Search and integrated with a purpose-built search engine backend such as Apache Solr. I mean, even the official Joomla.org sites don't use Smart Search because it sucks so bad...

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!

Thursday, 02 March 2023 11:16 CST

[email protected]

Nicholas,

Thank you for the prompt and detailed response!

 

1.) Yes...apologies for not providing more detail. I have isolated this to an issue with the specific plugins after performing more tests. I will be contacting the vendor.

 

2.) I now understand that rebuilding the Smart Search Index and verifying the Smart Search filters should just be part of my site restoration process.

I have become aware of the "finicky" nature of Smart Search but was completely unaware of the performance issues. Looks like, we will need to rethink our strategy and architecture before our site content grows too large. I realize that this out of scope of Akeeba Backup Support , but do you know of any Joomla development/service organizations that specialize in 3rd party Search integration?

Once again...thank you for your detailed and prompt input!

Eric

Friday, 03 March 2023 01:55 CST

nicholas

I already have this problem on our own site. If I index all of our tickets (nearly 40,000 of them, with almost 200,000 posts) Smart Search is borked to the point that three people trying to use the search at the same time has a measurable impact on the server's performance. 

The JED has this section https://extensions.joomla.org/category/search-a-indexing/site-search/ which tells me that my options are using Algolia, or use ElasticSearch through AWS OpenSearch.

My unique problem with this site is that search is a tertiary, at best, feature and we have way too much content to index. This means I am looking at a very high cost for something that is a far cry from being business-critical. That's why I ended up just putting a DuckDuckGo link as a search button on our site. It does the trick without costing anything.

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!