Disaster Recovery Planning for Qlik Sense Enterprise

At most of our clients, Qlik Sense Enterprise (QSE) is an integral part of day-to-day operations.  Where once reporting and analytics was used for historical analysis, it is now used actively to run the business.  From that perspective, it is very important to safeguard QSE (and the supporting systems) by making sure there is a good disaster recovery plan.  

For this post, the focus will be on things to consider when doing DR planning for Qlik Sense.  Your disaster recovery plan will vary depending on whether you are running QSE on Windows or QSE SaaS.

A good disaster recovery plan would include the following types of activities:

  • Multiple time-based backups with multiple retention periods
  • Plan for alternate recovery hardware or VM hosting
  • Periodic testing of recovery plan 

For QSE, your plan should include the following items:

Description QSE WindowsQSE SaaS
Virtual Machine Snapshots (if a VM) Checkmark with solid fillQlik Provided 1
Backup of Repository Database (Postgres)Checkmark with solid fill 2Qlik Provided 1
Backup of Repository ShareCheckmark with solid fill2Qlik Provided 1
Backup of Log DataCheckmark with solid fill2Qlik Provided 1
Application BackupsCheckmark with solid fillCheckmark with solid fill
Planning for Disaster RecoveryCheckmark with solid fillCheckmark with solid fill
Note version and keep installation files with backupsCheckmark with solid fillN/A
1 Note that for QSE SaaS Qlik does NOT provide granular level recovery or versioning currently.  If a user deletes an application, there is no mechanism to recover an individual application within QSE SaaS.  We recommend implementing an application-level backup approach (see below).
2  Qlik’s recommended process is that all Qlik services (Except the database) be stopped when doing Repository / Repository Share / Log Data backups.  This can be tricky to schedule with high availability environments and another reason we recommend combining with the application backups.

By combining all the methods below, an organization can setup a plan that provides for multiple recovery options.  Having object level backups allows for recovering individual Apps or Objects where that can be difficult if you just have environment level backups.  Sometimes with only environment level backups, it would take more time to recover lost work than it would take to manually recreate the work.

Virtual Machine Snapshots (if a VM) 

If you are running Qlik Sense as a Virtual Machine a great place to start is by making Virtual Machine backups (aka Snapshots) and storing them redundantly and for multiple time periods.  This approach will help you quickly if the server has an Operating System or Qlik Sense software / technical issue.  Rolling back to an earlier version of the server can be a quick way to recover.  

Since sometimes you may need to go back further to solve a technical issue with the environment, it is good to pair this with additional approaches below.

Backup of Repository Database (Postgres)

Qlik Sense stores all server settings, information about apps, users, user created content (Sheets, Stories, Bookmarks, etc.) in a Postgres database.  By default, that database is on the Central Node of a Qlik Sense environment.  This database is integral to the operation of Qlik Sense and needs to be backed up.  

Backup of Repository Share

In addition to the Repository database, Qlik stores the actual Applications with the data as QVF files in the Repository File Share.  There are also additional files and data in that are and that should be backed up for easy retrieval as well.

Backup of Log Data

In addition to the Repository database, Qlik stores all the log data.  The log data provides the mechanism to see license usage, application usage and server performance over time.  This is often very useful for organizations.

Application Backups / Source Control

In addition to backing up all the data in aggregate, we suggest that individual applications also be backed up and archived.  Although this can be done manually, an automated approach is the best approach.  Both QSE on Windows and SaaS have APIs that allow the exporting of applications and a solution can be built to provide this capability.  

For QSE Windows, a source control system can be used to version applications on a schedule or automatically.  We recommend Motio Soterre and would be happy to discuss if you are interested.  In addition, a source control system can include User Objects (Sheets, Stories and Bookmarks) in the versioning allowing easy rollback or recovery of deleted / changed objects.  

Options for Application Backups / Source Control by Environment

Description QSE WindowsQSE SaaSNotes
Manual (User) Export of ApplicationsCheckmark with solid fillCheckmark with solid fillRequires diligence to maintain
API Automation of Application ExportsCheckmark with solid fillCheckmark with solid fillRequires programming to integrate to API and export applications (QVFs) to storage location
Source Control (i.e., Motio Soterre)Checkmark with solid fillN/ACommercial solution providing source control for QSE on Windows.  
Export of User Objects (Sheets / Bookmarks, Stories)Checkmark with solid fillCheckmark with solid fillRequires programming to integrate to API and export applications (QVFs) to storage location

Testing the Recovery Plan

A DR Plan is important but testing and practicing a recovery plan with multiple scenarios is crucial.  During a disaster is the wrong time to find out that backups weren’t being done correctly or be figuring out the steps for recovery and that something is missing.

Good things to think about:

  • If running on physical machines, do you have a backup server?  
  • If running on a Virtual Machine Host, do you have a secondary host that can host the Qlik environment?
  • Where are the backups stored and what is the retention policy?
  • If a user accidentally deletes an application or it is corrupted, what is the plan for recovery? 
  • Do you have all the instructions/documentation that are required to complete the recovery?  For example, if the Qlik server name changes, additional steps are required to recover a Qlik instance.
  • Do you have a multi-Node Qlik Environment?
  • How long can the system be offline?
  • How much data loss is acceptable (i.e., how often and how many backups should be retained)?

Tips:

  • Your disaster recovery plan should be revisited any time a new version is implemented to see if anything needs to change.
  • Your disaster recovery plan should be tested frequently (Annually at a minimum)

Summary

Every organization’s disaster recovery plan is unique.  Please let us know if you need any help devising or reviewing your plan for your organization.  We are always happy to help!  Feel free to contact me, any of our consultants or email our Customer Success Team at Support@Solve100.com

Team Solve

Business intelligence is our passion. We thrive to help you grow your business through solving critical problems by using data. The team behind this passion is made up of all walks of life, and we all have the same drive to help you find new solutions to old problems.