Hoe weet je of je back-up echt werkt?

Waarom bewijst een geslaagde back-uptaak niet dat je kunt herstellen?

Omdat een back-uptaak en een herstel twee verschillende dingen zijn. De taak bevestigt dat data naar het back-updoel is gekopieerd. Voor een herstel moet die kopie compleet, onbeschadigd en bruikbaar zijn. Ook heb je een proces nodig dat mensen onder druk kunnen volgen.

Elke nacht staan er groene vinkjes op het dashboard. Dan valt er een server uit en het herstel loopt vast, omdat de versleutelingssleutel niet ligt waar iemand hem verwacht. Of de database komt terug zonder de configuratie die de applicatie nodig heeft. De back-up was in orde. Het herstel niet. Daarom beoordeel je een Backup as a Service die het geld waard is op herstel, niet op vinkjes.

Enquêtes laten zien hoe vaak dat misgaat. In het Unitrends State of Backup and Recovery Report 2025 dacht meer dan 60% van de organisaties binnen uren te kunnen herstellen van een downtime-incident. Slechts 35% kon dat. Uit het Data Trust and Resilience Report 2026 van Veeam blijkt dat 90% van de organisaties erop vertrouwde te kunnen herstellen van een cyberincident, maar dat slechts 28% van de ransomware-slachtoffers alle getroffen data volledig herstelde.

Mislukt herstel komt meestal door drie oorzaken:

1. Onvolledige scope: een systeem, database of configuratie zat nooit in de back-up.
2. Beschadigde data: de taak slaagde, maar de kopie raakte beschadigd door opslagfouten of onderbroken schrijfacties.
3. Ontbrekende afhankelijkheden: het herstel heeft software, licenties, versleutelingssleutels of identiteitsinstellingen nodig die niet beschikbaar zijn.

Geautomatiseerde controles vangen de eerste twee op. De derde komt pas aan het licht als je echt terugzet.

Wat zijn de niveaus van een hersteltest, en hoe vaak voer je ze uit?

Er zijn drie niveaus. Elk bewijst meer dan het vorige. Test kritieke systemen op alle drie, en minder kritieke systemen op de eerste twee.

Zie dit als beginpunt, niet als regel. Test ook na elke ingrijpende wijziging: een migratie, een nieuw systeem, een software-upgrade of een wijziging in de back-upconfiguratie.

Officiële richtlijnen wijzen dezelfde kant op. De CISA #StopRansomware Guide zegt dat organisaties "regelmatig de beschikbaarheid en integriteit van back-ups moeten testen in een disaster recovery-scenario". De NCSC UK small organisations guide zegt dat je na het maken van een back-up moet weten hoe je hem terugzet en moet controleren of hij al je belangrijke data bevat. Veel organisaties testen nog steeds zelden: Unitrends vond dat 25% disaster recovery één keer per jaar of minder vaak test.

Voor een test op niveau 3 zie je hoe een gestructureerde disaster recovery-dienst failovers uitvoert op standby-infrastructuur.

Hoe voer je een hersteltest van je back-up uit, stap voor stap?

Kies een scenario, zet het terug in een geïsoleerde omgeving precies zoals gedocumenteerd, en controleer en meet daarna het resultaat. Het doel is problemen te vinden zolang er nog niets in brand staat.

1. Kies het scenario: een bestand van vorige maand, een database of een complete server.
2. Gebruik een geïsoleerde omgeving: een apart netwerk, zodat het teruggezette systeem niet botst met productie.
3. Volg de schriftelijke procedure: geen shortcuts en geen hulp van die ene collega die alles uit zijn hoofd kent.
4. Meet elke stap: van het besluit om terug te zetten tot het moment dat gebruikers kunnen werken.
5. Controleer de data: open de bestanden, bevraag de database, log in op de applicatie.
6. Controleer het herstelpunt: hoe recent is de nieuwste teruggezette data?
7. Leg het resultaat vast: wat werkte, wat mislukte, wat langer duurde dan gepland.
8. Los het op en test opnieuw: pas de scope, de configuratie of het draaiboek aan en herhaal de test.

Bij stap 5 stoppen veel tests te vroeg. De AWS Well-Architected reliability guidance (REL09-BP04) noemt "terugzetten zonder validatie" een anti-pattern, net als aannemen dat hersteltijd en dataverlies binnen je doelen blijven zonder ze te meten.

Wat als de test mislukt?

Een mislukte test levert nuttige informatie op. Een mislukt herstel bij een echt incident is de ramp. Zoek de oorzaak (configuratie, ontbrekende scope, beschadigde back-up of ontbrekende documentatie), los die op en voer dezelfde test opnieuw uit tot hij slaagt.

Bij Mindtime start je een back-up van een VM direct op in een geïsoleerde herstelomgeving op een apart, schoon netwerk. Daardoor zijn tests op niveau 2 veel minder storend.

Hoe controleer je of je back-up compleet is?

Maak een herstelinventaris: een lijst van alles wat je na een totaal verlies nodig hebt om te herstellen. Vergelijk die met wat er echt in de back-up zit. Alles wat op de lijst staat maar niet in de back-up, is een gat.

Compleet is meer dan alleen de data zelf. Controleer per soort systeem:

• Servers en VM's: besturingssysteem, applicaties, configuratie, data en licentiegegevens.
• Microsoft 365: Exchange-mailboxen, OneDrive, SharePoint-sites en Teams. Accounts van vertrokken medewerkers horen er ook bij.
• Databases: de data plus het schema, stored procedures, views en de taken die ervan afhangen.
• Endpoints (laptops, desktops en mobiele apparaten) en NAS: de bestanden die mensen buiten de centrale systemen bewaren.
• Wat je nodig hebt om te herstellen: versleutelingssleutels, beheerdersgegevens, draaiboeken en contactgegevens van leveranciers, bewaard op een plek waar je bij kunt als productie uitvalt.

Loop de inventaris na zodra je een systeem toevoegt. Nieuwe SaaS-apps en databases die IT niet kent, zijn waar de gaten meestal ontstaan. Lees wat erbij komt kijken voor Microsoft 365-back-up en back-up van SQL Server-databases.

Welke meetwaarden laten zien dat je back-up- en herstelstrategie werkt?

Meet uitkomsten, geen activiteit. De belangrijkste cijfers zijn hoe vaak herstel slaagt, hoeveel data je zou verliezen en hoe lang herstel duurt, afgezet tegen doelen die je met de business hebt afgesproken.

Twee doelen vormen het anker. RPO (recovery point objective) is het maximale dataverlies: hoeveel werk je kunt missen, uitgedrukt in tijd. RTO (recovery time objective) is de maximale hersteltijd: hoe lang een systeem uit de lucht mag zijn. Stel beide per systeem vast en meet er daarna tegen. In onze gids over RTO en RPO lees je hoe je ze kiest.

De laatste rij is belangrijker dan hij lijkt. Uit het Ransomware Trends-rapport 2025 van Veeam, zoals weergegeven door Intelligent CISO, blijkt dat slechts 10% van de aangevallen organisaties meer dan 90% van hun data herstelde. Hersteltests bewijzen dat het proces werkt. Een onveranderbare kopie volgens de 3-2-1-1-0-regel zorgt dat er iets overblijft om terug te zetten.

Welk bewijs verwachten NIS2, de AVG en auditors?

Toezichthouders en auditors willen bewijs dat je kunt terugzetten, geen verklaring dat je een back-up maakt. Dat betekent: hersteltests met een datum, resultaten afgezet tegen je doelen en een overzicht van wat je hebt opgelost.

AVG-artikel 32(1) vereist "het vermogen om de beschikbaarheid van en de toegang tot persoonsgegevens bij een fysiek of technisch incident tijdig te herstellen" (onder c) en "een procedure voor het regelmatig testen, beoordelen en evalueren van de effectiviteit" van beveiligingsmaatregelen (onder d). NIS2-artikel 21(2)(c) vereist "bedrijfscontinuïteit, zoals back-upbeheer en noodherstel, en crisisbeheer" voor essentiële en belangrijke entiteiten. Lees meer over wat artikel 21 vraagt.

Een bruikbaar bewijsdossier per systeem bevat:

• De afgesproken RPO en RTO, en wie ze heeft goedgekeurd.
• Rapporten van back-uptaken en hoe mislukkingen zijn afgehandeld.
• Registraties van hersteltests: datum, scope, duur, resultaat en oplossingen.
• Bewijs dat minstens één kopie onveranderbaar is en apart is opgeslagen.

Hier helpt automatisering. Bij Mindtime controleren we elke back-uptaak automatisch en bewaken we ze 24/7. Bij onze Disaster Recovery-dienst valideert een gecertificeerde engineer de eerste testfailover, meestal binnen 10 dagen. Elk kwartaal draaien geautomatiseerde DR-tests, met bewijs voor je auditors.

Wat je nu kunt doen

Een back-up die je niet hebt getest, is een aanname. Begin deze week klein: zet één bestand van een maand geleden terug en meet hoe lang het duurt. Zet volgende maand een hele server terug in een geïsoleerd netwerk. Leg daarna je RPO en RTO per systeem vast en houd de meetwaarden hierboven daartegen bij.

Wil je dit liever niet allemaal zelf doen? Lees hoe Backup as a Service controles, onveranderbaarheid en herstel regelt, of lees waarom cloudopslag niet hetzelfde is als back-up.

Wil je een hersteltest en het bewijs dat die oplevert zien? Plan een gratis demo van 15 minuten, in het Nederlands, Duits of Engels.

Dit artikel is algemene informatie, geen juridisch advies.