Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
I have recently recovered a backup of QlikSense 2023 and followed all the steps highlighted in this guide: https://www.linkedin.com/pulse/qlik-sense-server-recovery-overview-howdashllc-wxm8e/
I have also changed hostnames and IP addresses.
Everything is working except for the QlikSense Bundled Extensions - They come up in QMC OK but 404 on any existing application in the Hub showing an "Invalid visualisation" (Example is qlik-button-for-navigation)
I can also see the extensions in the Qlikshare folder, all system paths are referencing the new hostname correctly and I did bootstrap the server successfully. Permissions are set correctly and other system extensions in the same shared path are working fine.
I have reinstalled the bundle and ensured it was set to install the full packages. If I delete the extensions and restart the Qlik services it automatically recreates the bundles in the share but still don't get picked up by hub.
Any advice in getting the hub to see these extensions?
Video Walkthrough
Deprecated Extensions
You mentioned specifically the qlik-button-for-navigation extension which has been deprecated since February 2020. I'm curious to hear if the other extensions that are part of the Dashboard bundle working fine after recovery.
I recommend opening up an app on the recovered server and checking to see if there are other visualization extensions available and are working fine, like this:
If you see other extensions in the list but not the navigation button, that could mean that Qlik Sense is refusing, for whatever reason, to display deprecated extensions in a newer version of Qlik Sense.
If that's the case, you might need to convert extension to the newer, default button object. That can be done by simply dropping the default button object on top of deprecated object and selecting the Replace with: Button option, like this:
Fix Corrupted Extension
However, before you go and replace all of the objects it's worth to try to see if it's just one extension that is corrupted and try to fix it.
If the extension is corrupted, you can try replacing the individual extension that is not working on the new server with the extension that is working on the original server. That can be done by:
I showed how to do that in the video above.
Summary
If you can see other extensions on the new server, in the list of custom objects, and they are working, it's likely that the recovery went well and that newer version of Qlik Sense is simply not displaying deprecated extensions.
If replacing the extension on the new server with the extension from the old server won't fix the issue, try converting the deprecated extensions to newer objects.
@LeighH ,
There's a quick guide on how to reinstall the extension bundle. Please perform these steps and let us know the results, ok?
Qlik Sense Enterprise on Windows (Server installation):
You can verify that the changes have been correctly applied by checking the Extensions section in the Qlik Management Console (QMC).
Live and Breathe Qlik & AWS.
Follow me on my LinkedIn | Know IPC Global at ipc-global.com
Video Walkthrough
Deprecated Extensions
You mentioned specifically the qlik-button-for-navigation extension which has been deprecated since February 2020. I'm curious to hear if the other extensions that are part of the Dashboard bundle working fine after recovery.
I recommend opening up an app on the recovered server and checking to see if there are other visualization extensions available and are working fine, like this:
If you see other extensions in the list but not the navigation button, that could mean that Qlik Sense is refusing, for whatever reason, to display deprecated extensions in a newer version of Qlik Sense.
If that's the case, you might need to convert extension to the newer, default button object. That can be done by simply dropping the default button object on top of deprecated object and selecting the Replace with: Button option, like this:
Fix Corrupted Extension
However, before you go and replace all of the objects it's worth to try to see if it's just one extension that is corrupted and try to fix it.
If the extension is corrupted, you can try replacing the individual extension that is not working on the new server with the extension that is working on the original server. That can be done by:
I showed how to do that in the video above.
Summary
If you can see other extensions on the new server, in the list of custom objects, and they are working, it's likely that the recovery went well and that newer version of Qlik Sense is simply not displaying deprecated extensions.
If replacing the extension on the new server with the extension from the old server won't fix the issue, try converting the deprecated extensions to newer objects.
Thanks so much for your help and suggestions so far. Looks like it's "all" the bundled extensions/visualisations also a handful of built in extensions such as 2D heatmaps, calendar heatmaps, sunburst etc. which all work perfectly fine on the previous server with the same Qliksense version and patch level. Some built in extensions are working.
I did completely uninstall the bundle, import the bundled ZIP - No change. Reinstalled a number of times too via add/remove programs.
The QlikShare directory permissions are the same on both servers. The only thing I can think of was when installing Postgres I used a different root (postgres) PW then the original server but made sure the qliksenserepository password was the same as the original.
EDIT: As per your video (Thanks for putting that together) I did just try an export from our Dev server the qlik-button-for-navigation , deleted it via QMC and re-imported it - Its now working.
I may have to do this for a number of extensions, but this may fix the issue.
EDIT 2: Looks like a bunch of extensions are simply missing the ResourceGroup under CustomProperties. On Dev its set to "All" however on the restored server it is set to nothing. Updating this to "All" seemed to have fixed permissions and restored functionality to both deprecated and non-deprecated extensions.
My question now is why this didn't carry over with the database?
Hi @LeighH ,
Regarding edit 2, not all properties regarding the extensions are kept on the database itself. Some of them are on the actual extension file sitting inside the Shared Persistence Root folder.
Please confirm that you have copied over the Static Content folder from one server to the other. This folder contains the extensions. You can see the location of the folder on QMC -> ServiceCluster section. Make sure the content is copied too.
Let us know how it goes. Restart the services to double-check.
Live and Breathe Qlik & AWS.
Follow me on my LinkedIn | Know IPC Global at ipc-global.com
RE: Edit 1, I'm glad that worked and I'm happy too help 😊
RE: Edit 2, I don't know for sure, but my best guess is a mismatch in PostgreSQL version.
The Guess
Qlik Sense can either have a bundled or standalone installation of PostgreSQL. If you have bundled installation, then it's possible that the original server used a version of PostgreSQL that is older than the one that's on the restored server.
How Could Same QS Version Have Different PSQL Version?
For example, if you installed May 2023 version of Qlik Sense on the original server then upgraded original server to August 2023 version, then the original server will still have version 12.5 of PostgreSQL.
However, when installing August 2023 version of Qlik Sense on the recovery server, that version of Qlik Sense comes with version 14.8 of PostgreSQL. So even though both the original and recovery server have the same version of Qlik Sense, they may have different versions of PostgreSQL.
This happens because when you upgrade Qlik Sense, the upgrade process doesn't upgrade bundled PostgreSQL server. So if your original server used version 12.5 of PostgreSQL and recovered version uses version 14.8, that might have caused the issue during recovery. But that depends on how backups of PostgreSQL server were created.
Version Agnostic Backups
If pg_dump command was used to create tarball files (files with .tar extension) and pg_restore was used to restore from the .tar files, that shouldn't cause any issues.
Similarly, if you've used the pg_dumpall command to create a SQL file and then used psql command to restore data from that SQL file, that also shouldn't cause issues.
SQL script is version agnostic. And, from what I understand, the tarball files created using pg_dump command should also be version agnostic.
Physical PSQL Backups
If, however, tarball files were created some other way, not with the pg_dump command (by manually zipping PostgreSQL data directory for example) then that could have caused the issue when recovering PostgreSQL data to a newer version of PostgreSQL.
TL;DR
All that's is just a guess though, and I'm assuming that versions of PostgreSQL varied between the original and new server. It's hard to know for sure without taking a look at the servers and running through a recovery process to try and reproduce the issue.
Hi Hugo, Static Content was synced across and cluster settings updated on a few occasions. I'm going to delete the new server and start the process again in case I missed anything and see if the extensions retain their ResourceGroup settings. I will report back my findings.
Thanks again for your suggestion. I can confirm PostgreSQL versions are the same. I'm going to delete the new server and start the process again in case I missed anything and see if the extensions retain their ResourceGroup settings. I will report back my findings.
Good luck! Hopefully, it'll go better this time around!
Followed the guide from start to finish and this time it worked perfectly. There might have been some corruption or lock files on the old server the first-time around that prevented that field from populating.
I did do a pg_dumpall this time instead of dumping/importing each of the 4 individual databases. I had to comment out the postgres user creation in the sql dump beforehand and manually reset the repository user database password as it seems to have randomly generated it.
I also had to skip the section in your guide to sync "Program files" - This would brick the services and cause random crashes (New OS version?). Only syncing the Qlik Shares and Programdata was required for me - I have developers testing it extensively as we speak before we officially migrate to it.
Thanks again for your help - I'm faily new in this space and I have learnt a lot. Time to move onto QlikView
Kind regards, Leigh