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 Windows||QSE SaaS|
|Virtual Machine Snapshots (if a VM)||Qlik Provided 1|
|Backup of Repository Database (Postgres)||2||Qlik Provided 1|
|Backup of Repository Share||2||Qlik Provided 1|
|Backup of Log Data||2||Qlik Provided 1|
|Planning for Disaster Recovery|
|Note version and keep installation files with backups||N/A|
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 Windows||QSE SaaS||Notes|
|Manual (User) Export of Applications||Requires diligence to maintain|
|API Automation of Application Exports||Requires programming to integrate to API and export applications (QVFs) to storage location|
|Source Control (i.e., Motio Soterre)||N/A||Commercial solution providing source control for QSE on Windows.|
|Export of User Objects (Sheets / Bookmarks, Stories)||Requires 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)?
- 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)
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