27 mei 2026

Wat hoort er eigenlijk in een goede Qlik Cloud backup?

Deel dit bericht

Screenshot van een Bitmetric daily backup manifest met 1842 apps en 334 automation-connections, status Success.

Qlik Cloud neemt veel technisch beheer uit handen. Geen servers onderhouden, geen updates plannen, geen platformcomponenten draaiend houden. Dat is precies de kracht van SaaS.

Maar daarmee is niet alles geregeld wat je als organisatie zelf opbouwt in die omgeving.

Ik zie het regelmatig bij klanten: er is goed nagedacht over hoe Qlik Cloud wordt ingericht, welke apps er komen, wie er toegang krijgt. Maar wat er nodig is om dat allemaal te kunnen herstellen, is een stuk minder vaak uitgedacht. Logisch, want het is niet het eerste waar je aan denkt als je een nieuwe omgeving opzet. Totdat je het nodig hebt.

Apps zijn het meest zichtbare onderdeel van een Qlik Cloud-omgeving. Logisch dat mensen daar als eerste aan denken. Er zit ook veel werk in: dashboards, datamodellen, scripts, businesslogica en visualisaties.

Toch staat een app zelden op zichzelf. Ze gebruikt dataverbindingen, staat in een space, heeft rechten nodig en wordt misschien automatisch herladen. Daarnaast bevat een Qlik Cloud-omgeving vaak ook automations, rapportagetaken, themes en extensions die los van één specifieke app waardevol zijn.

Een goede backup kijkt daarom verder dan appbestanden alleen.

Een praktische Qlik Cloud backup kijkt naar een paar lagen.

Apps zijn de kern. Die wil je kunnen herstellen bij verwijdering, foutieve wijzigingen of ongewenste overschrijvingen. Ook bookmarks kunnen relevant zijn, zeker als gebruikers vaste analyses of selecties gebruiken in hun dagelijkse werk.

Een bewuste keuze hierbij: exporteer apps zonder geladen data. De appstructuur, scripts en metadata worden dan veiliggesteld, terwijl de datasets zelf niet buiten Qlik Cloud worden opgeslagen. Dat beperkt opslagvolume en verkleint risico’s rondom vertrouwelijke data. De consequentie is dat de app na herstel opnieuw geladen moet worden, maar dat is prima zolang dat vooraf duidelijk is.

Een herstelde app heeft weinig waarde als de koppelingen naar bronsystemen ontbreken. Dataverbindingen horen dus in het backupplaatje.

Hetzelfde geldt voor automations, webhooks en web integrations die belangrijk zijn voor de bredere werking van de omgeving. Denk aan processen die acties uitvoeren na bepaalde gebeurtenissen, of integraties met andere applicaties, portals of embedded analytics-scenario’s.

Gevoelige gegevens zoals wachtwoorden en client secrets sla je bewust niet op in een backup. Die voer je bij herstel opnieuw in.

In Qlik Cloud zit veel waarde in hoe toegang is ingericht. Welke teams werken in welke spaces? Wie mag apps publiceren? Welke groepen zijn gekoppeld aan welke rollen?

Als die inrichting verloren gaat of onbedoeld wijzigt, kan de impact groot zijn. Gebruikers die niet meer bij rapportages kunnen, of juist te veel toegang krijgen. Publicatieprocessen die vastlopen.

Je hoeft niet elk detail volledig automatisch terug te kunnen zetten. Maar je wilt wel kunnen achterhalen hoe de omgeving was ingericht.

Naast spaces en rechten heeft een Qlik Cloud-tenant ook bredere instellingen die de werking van de omgeving bepalen. Denk aan identity providers voor SSO, licentieconfiguratie en beveiligingsinstellingen. Dit zijn geen onderdelen waar je dagelijks aan zit, maar als ze verloren gaan of onbedoeld wijzigen, heeft dat direct impact op toegang en gebruik.

Sommige dingen vallen pas op wanneer ze ontbreken. Een theme dat niet is teruggezet. Een extension die een visualisatie breekt. Een reload task die stilstaat. Een sharing task die geen rapportages meer verstuurt. Een glossary met bedrijfsdefinities die opnieuw moet worden opgebouwd. Een rapportagesjabloon dat opnieuw moet worden ingericht.

Niet de grootste onderdelen, maar ze bepalen wel of het analyticsproces na herstel gewoon weer werkt.

Backup wordt pas echt waardevol wanneer vooraf is nagedacht over hoe je iets terugzet.

Voor sommige onderdelen is dat eenvoudig: een appbestand terugplaatsen. Voor andere bestaat herstel uit opnieuw aanmaken, vergelijken of configureren op basis van backupinformatie. Dat is geen probleem, zolang van tevoren duidelijk is welke onderdelen direct herstelbaar zijn en waar extra handwerk bij komt kijken.

Praktische vragen die het waard zijn om vooraf te stellen:

  • Welke onderdelen zijn beschikbaar via Qlik API’s?
  • Welke metadata heb je nodig om configuratie te reconstrueren?
  • Welke informatie moet bij herstel opnieuw worden aangevuld?

Een backupproces zonder monitoring is een backupproces dat je alleen maar vertrouwt tot het tegenvalt.

Je wilt controle op backupruns, meldingen bij fouten en inzicht in wat per run wel en niet is meegenomen. Een manifest per backup helpt daarbij: daarmee zie je achteraf precies welke onderdelen succesvol zijn veiliggesteld.

Retentie verdient ook aandacht. Alleen de backup van gisteren bewaren is in de meeste gevallen te beperkt, want fouten worden soms pas later ontdekt. Een gelaagde aanpak werkt in de praktijk goed: dagelijkse backups voor de korte termijn, wekelijkse en maandelijkse versies voor langere terugkijkmomenten.

Een goede Qlik Cloud backup vraagt om meer dan periodiek apps exporteren. Dataverbindingen, automations, integraties, spaces, rechten, tenant-instellingen, opmaak, taken, monitoring en restore-afspraken horen er allemaal bij. En daarbinnen horen bewuste keuzes: wat sla je wel op, wat niet, en wat moet bij herstel opnieuw worden aangevuld?

Het hoeft niet ingewikkelder te zijn dan nodig. Maar het vraagt wel om een helder beeld van wat je beschermt en wat je daadwerkelijk kunt terugzetten als het nodig is.

Backup is niet het meest glamoureuze onderdeel van een Qlik Cloud-omgeving. Maar op het moment dat je iets kwijt bent, is het het enige dat telt.

Veel organisaties hebben goed nagedacht over Qlik Cloud als platform, maar minder over wat er nodig is om hun eigen content en inrichting te kunnen herstellen. Herkenbaar? We sparren er graag over.

Barry Harmsen | Bitmetric
Governance Qlik Support

Hoe kunnen we je ondersteunen?

Barry beschikt over meer dan 20 jaar ervaring als architect, developer, trainer en auteur op het gebied van Data & Analytics. Hij is bereid om je te helpen met al je vragen.