What should be included in a good Qlik Cloud backup?

Qlik Cloud takes a lot off your plate. No servers to maintain, no updates to schedule, no platform components to keep running. That is the strength of SaaS.

But it does not cover everything you build yourself inside that environment.

I see it regularly with clients: plenty of thought has gone into how to set up Qlik Cloud, which apps to build, who gets access. But what it would take to actually recover all of that? Much less often considered. Which is understandable, it is not the first thing on your mind when you are standing up a new environment. Until you need it.

Apps are the starting point, not the finish line

Apps are the most visible part of a Qlik Cloud environment, so it makes sense that people think of them first. A lot of work goes into them: dashboards, data models, scripts, business logic, visualisations.

But an app rarely stands alone. It relies on data connections, lives in a space, requires permissions and is probably reloaded on a schedule. Most environments also contain automations, reporting tasks, themes and extensions that have value well beyond any single app.

A good backup looks further than app files.

What do you actually want to be able to restore?

A practical Qlik Cloud backup covers a few distinct layers.

Apps and user content

Apps are the core. You want to be able to recover them after accidental deletion, unwanted changes or an overwrite that should not have happened. Bookmarks can matter too, especially when users rely on saved selections as part of their daily workflow.

One deliberate choice worth making upfront: export apps without loaded data. The app structure, scripts and metadata are preserved, while the datasets themselves stay within Qlik Cloud. That keeps storage volumes manageable and reduces risk around sensitive data. The trade-off is that after a restore, the app needs a reload before it shows current data again. That is fine, as long as everyone knows it going in.

Data connections, automations and integrations

A restored app is not much use without its connections to source systems. Data connections belong in your backup.

The same goes for automations, webhooks and web integrations that keep the broader environment running. That includes processes triggered by events, and integrations with other applications, portals or embedded analytics setups.

Sensitive data such as passwords and client secrets should not be stored in a backup. Those get re-entered at restore time. That is a deliberate choice, not an oversight.

Spaces, users and permissions

A lot of the value in Qlik Cloud lives in how access is structured. Which teams work in which spaces? Who can publish? Which groups map to which roles?

If that structure is lost or accidentally changed, the consequences can be significant. Users locked out of reports. Others with more access than they should have. Publishing workflows that stop working.

You do not need to automate every last detail of a restore. But you do need to be able to reconstruct how things were set up.

Tenant settings

Beyond spaces and permissions, there are broader tenant-level settings that affect how the environment functions. Identity providers for SSO, licence configuration, security settings. Not things you change often, but if they are lost or accidentally modified, the impact on access and day-to-day use is immediate.

Formatting, tasks and the smaller parts

Some things only become visible when they are missing. A theme that did not come back. An extension that breaks a visualisation. A reload task that stopped running. A sharing task that is no longer sending reports. A business glossary that needs to be rebuilt from scratch. A report template that needs to be reconfigured.

Not the most prominent parts of your environment, but they determine whether everything actually works again after a restore.

Think about restore, not just about saving

A backup only becomes valuable when you have thought through how you would actually use it.

For some components, a restore is simple: put the file back. For others, it means recreating, reconfiguring or using the backup as a reference for manual work. None of that is a problem, as long as you know in advance what can be restored directly and where extra effort is involved.

Practical questions worth asking in advance:

• What components are available through Qlik APIs?

• What metadata do you need to reconstruct configuration?

• What information will need to be re-entered during a restore?

Make sure you know if it works

A backup process without monitoring is a backup process you trust until it fails you.

You want visibility into backup runs, alerts when something goes wrong, and a clear record of what each run did and did not cover. A manifest per run helps with this: it tells you exactly what was backed up successfully and where issues occurred.

Retention is worth thinking about too. Keeping only yesterday’s backup is rarely enough, because problems are not always noticed straight away. A layered approach works well: daily backups for the short term, weekly and monthly snapshots for longer lookback periods.

In short

A good Qlik Cloud backup is more than periodically exporting apps. Data connections, automations, integrations, spaces, permissions, tenant settings, appearance, tasks, monitoring and restore agreements all belong in the picture. And within all of that, deliberate choices need to be made: what do you store, what do you leave out, and what needs to be re-entered when something goes wrong?

It does not need to be complicated. But it does require a clear picture of what you are protecting and what you can actually get back when you need it.

Backup is not the most glamorous part of a Qlik Cloud environment. But when something is gone, it is the only thing that matters.

Many organisations have thought carefully about Qlik Cloud as a platform, but less about what it would take to recover their own content and configuration. Does that sound familiar? We are happy to talk it through.