Back-up herstellen: zo leg je een veilige hersteltest vast

Een melding dat een back-up is voltooid vertelt nog niet hoeveel tijd je nodig hebt om weer te werken. Daarvoor moet je weten welke gegevens zijn meegenomen, of je toegang hebt tot de herstelmiddelen en of een teruggezet bestand of systeem bruikbaar is. Een afgebakende hersteltest maakt die vragen concreet voordat een storing je werk onderbreekt.

Deze uitleg helpt kleine ondernemers en hun ICT-beheerder om één veilige test voor te bereiden, te beoordelen en vast te leggen. We werken met een fictief ontwerpbureau en een eigen herstelkaart. De kaart is geen technische instructie voor een bepaald product en geen certificaat dat je bedrijf volledig bestand is tegen incidenten. Laat het daadwerkelijke terugzetten uitvoeren door iemand die de omgeving en de gebruikte software begrijpt.

Kies één bedrijfsproces als beginpunt

Begin niet met de vraag hoeveel gigabytes je kunt terugzetten, maar met het werk dat daarna weer moet kunnen. Een ontwerpbureau wil bijvoorbeeld een lopend project openen, de juiste tekening vinden en controleren welke versie met de klant is afgesproken. Een winkel heeft misschien vooral ordergegevens en voorraadmutaties nodig. Die verschillende doelen vragen verschillende controles.

Schrijf voor jouw eerste test één herkenbare uitkomst op. “Een projectmap kunnen herstellen en drie afgesproken bestanden openen” is duidelijker dan “de back-up werkt”. Maak de selectie klein genoeg om veilig te kunnen oefenen en groot genoeg om iets nuttigs te leren. Een leeg testbestand zegt weinig over een map met verschillende bestandsformaten en afhankelijkheden.

Gebruik de bestaande herstelvolgorde bij een IT-storing als je nog niet weet welk proces prioriteit heeft. Met de bestaande interactieve herstelkaart kun je eerst de volgorde en afhankelijkheden van maximaal zes bedrijfsprocessen verkennen. De CSV bij dit artikel heeft een ander doel: hij legt de uitvoering en uitkomst van één back-uphersteltest vast.

In dit artikel zoomen we vervolgens in op het bewijs van één hersteltest. Een succesvolle deeltest betekent niet dat alle andere processen, accounts en systemen automatisch zijn gecontroleerd.

Maak onderscheid tussen technisch en functioneel herstel

Het NCSC onderscheidt een technische controle van een functionele hersteltest. Bij de technische controle kijk je onder meer naar de uitvoering en de herstelactie in de back-upsoftware. Bij de functionele controle probeer je of relevante bedrijfsprocessen na herstel weer bruikbaar zijn.

Vertaal dat onderscheid naar twee afzonderlijke vragen. Is de geselecteerde kopie zonder gemelde fout teruggezet? En kan de beoogde medewerker met het resultaat de afgesproken handeling uitvoeren? Een bestand kan aanwezig zijn maar niet openen. Een applicatie kan starten terwijl een noodzakelijke koppeling of een bijbehorende map ontbreekt.

Maak de test niet groter dan je kunt beoordelen. Als je alleen bestanden herstelt, noteer dan dat je geen volledig systeemherstel hebt uitgevoerd. Als je een applicatie test, benoem welke onderdelen wel en niet zijn meegenomen. Een duidelijke afbakening voorkomt dat een beperkte controle later wordt aangehaald als bewijs voor een veel ruimere herstelbelofte.

Spreek vooraf een veilige testplek af

Een oefening hoort geen bestaande productiegegevens te overschrijven. Laat je beheerder daarom vooraf bepalen waar het herstel plaatsvindt en hoe de test gescheiden blijft van de omgeving waarin medewerkers en klanten werken. De juiste inrichting hangt af van het product, de gegevens en de koppelingen. Volg de officiële handleiding van de gebruikte software.

Let extra op systemen die na het starten vanzelf iets doen. Denk aan het versturen van berichten, synchroniseren van bestanden, uitvoeren van geplande taken of contact leggen met een betaalomgeving. Spreek af hoe zulke effecten in de test worden voorkomen. Een gekopieerde applicatie mag niet ongemerkt als tweede productieomgeving gaan handelen.

Gebruik fictieve gegevens wanneer die voldoende zijn om de gekozen werking te testen. Als echte bedrijfsgegevens noodzakelijk zijn, beperk de toegang en leg vast hoe de testkopie wordt beschermd en opgeruimd. Zet geen klantgegevens in een openbaar screenshot of een gedeeld bewijsbestand. De herstelkaart heeft geen wachtwoorden, geheime sleutels of volledige gegevensbestanden nodig.

Neem toegang en voorbereiding mee in de tijdmeting

Ga na of de bevoegde uitvoerder bij de benodigde back-up, software en documentatie kan. Een herstelprocedure die afhankelijk is van één persoon of een verdwenen apparaat kan in de praktijk vastlopen. Bespreek de vervanging en bereikbaarheid vooraf met de verantwoordelijke voor de omgeving.

Noteer in de kaart welke rol toegang nodig heeft en waar de officiële procedure te vinden is. Kopieer geen inloggegevens in het document. Voor toegang zelf gebruik je de afgesproken beveiligde voorziening. Controleer ook of er afhankelijkheden zijn, zoals een licentie, een herstelmedium of een leverancier die een handeling moet uitvoeren.

Begin de tijdmeting niet pas nadat alle lastige voorbereiding klaar is. Wil je weten hoelang de hele werkwijze duurt, leg dan ook het verzamelen van toegang en het vinden van de juiste kopie vast. Maak afzonderlijke tijden voor voorbereiding, technisch terugzetten en functionele controle. Daarmee wordt zichtbaar waar vertraging ontstaat.

Kies de kopie en noteer het meetpunt

Leg vast welke back-up je gebruikt en op welk moment de gegevens daarin betrekking hebben. Een bestandsdatum, de start van een back-uptaak en de voltooiing van die taak hoeven niet dezelfde betekenis te hebben. Laat de beheerder uitleggen welk tijdstip in jouw product het beste aangeeft welke gegevens zijn opgenomen.

De back-upstrategie van het NCSC bespreekt zowel gegevensverlies als hersteltijd. Voor je eigen test kun je die vragen eenvoudig formuleren: welk werk mag bij een incident ontbreken, en binnen welke tijd moet het gekozen proces weer bruikbaar zijn? Spreek doelen vooraf af, zodat je de uitkomst niet achteraf passend maakt.

Gebruik de werkelijke bedrijfsbehoefte als uitgangspunt. Een oud archief kan een andere prioriteit hebben dan lopende opdrachten. Een recente kopie kan bovendien onvoldoende zijn wanneer een fout al langer in de gegevens zit. Beschrijf daarom ook waarom de gekozen kopie voor deze test relevant is. Eén succesvolle proef met de nieuwste kopie zegt niets over alle oudere versies.

Fictief voorbeeld: één projectmap terugzetten

Ons fictieve ontwerpbureau heeft een projectmap met een tekening, een planning en een werkdocument. Het bureau laat de map met verzonnen projectgegevens eerst via de te testen back-upvoorziening opnemen in een herkenbare back-up. Een bevoegde beheerder herstelt juist die opgeslagen versie via de bijbehorende herstelprocedure op een afgesproken, afgeschermde testplek. Alleen een losse map handmatig kopiëren zou die back-upketen niet testen. Medewerkers blijven ondertussen in hun gewone omgeving werken.

De afgesproken controle is beperkt: de drie bestanden moeten openen, de verwachte versienamen moeten zichtbaar zijn en een proefwijziging moet uitsluitend in de testomgeving worden opgeslagen. De test omvat geen herstel van een volledig netwerk, geen controle van alle historische bestanden en geen echte verzending naar een klant.

De fictieve uitvoering duurt tien minuten voorbereiding, achttien minuten technisch terugzetten en twaalf minuten controle met de medewerker. De totale oefentijd is in dit fictieve voorbeeld veertig minuten. Deze getallen zijn zelfgekozen om de methode te laten zien. Ze zijn geen klantmeting, marktgemiddelde of indicatie voor de tijd die jouw herstel zal kosten.

Tijdens het openen blijkt dat één bestand verwijst naar een ontbrekend lettertype. Het bestand staat wel in de map, maar de weergave is niet gelijk aan wat de medewerker nodig heeft. De test krijgt daarom niet de uitkomst “volledig geslaagd”. Het bureau legt de ontbrekende afhankelijkheid vast en plant een gerichte herhaling nadat die is uitgezocht.

Dit is de nuttige opbrengst van een oefening: je ontdekt een concrete beperking terwijl er nog tijd is om haar aan te pakken. Het doel is niet zoveel mogelijk groene vinkjes verzamelen. Een afwijking met een duidelijke eigenaar en een hercontrole geeft meer houvast dan een algemene mededeling dat de back-up in orde is.

Download de lege herstelkaart (CSV). Vul geen wachtwoorden, herstelsleutels of klantgegevens in. De kaart bevat alleen invulvelden en verstuurt niets. Bewaar een ingevulde kaart op de afgesproken interne plek en verwijs naar beveiligde procedures in plaats van geheimen te kopiëren.

Leg succescriteria vóór de uitvoering vast

Beschrijf wat iemand daadwerkelijk moet kunnen zien of doen. “Het systeem start” kan een eerste technische controle zijn, maar zegt nog weinig over de bruikbaarheid van een werkproces. Kies handelingen die passen bij het doel van de proef, zoals een bestaand dossier openen, een rapport bekijken of een testwijziging terugvinden.

Zet bij ieder criterium wie het beoordeelt. De beheerder kan vaststellen of de herstelactie technisch voltooid is. Een medewerker die met de bestanden werkt, kan beoordelen of het resultaat bruikbaar is voor de afgesproken taak. Beide beoordelingen kunnen nodig zijn zonder dat één persoon alle details beheerst.

Benoem ook wanneer je stopt. Een onverwachte verbinding met productie, onduidelijkheid over de gekozen kopie of een risico op overschrijven is reden om de proef te onderbreken en de situatie te controleren. Spreek af wie beslist over hervatting. Probeer een onzeker resultaat niet snel te repareren terwijl de gevolgen nog onduidelijk zijn.

Beoordeel ontbrekend werk afzonderlijk

Een teruggezette kopie bevat gegevens van een bepaald moment. Werk dat daarna is gedaan kan ontbreken. Vraag daarom niet alleen of de oude gegevens bruikbaar zijn, maar ook hoe je het verschil met het gewenste herstelmoment vaststelt. Dat kan per proces verschillen.

In een oefening kun je met fictieve mutaties laten zien wat ontbreekt. Maak bijvoorbeeld na het gekozen meetpunt drie genummerde testwijzigingen en controleer welke daarvan in de geselecteerde kopie voorkomen. Gebruik die proef niet om zonder meer te concluderen dat echte betalingen, orders of dossiers op dezelfde manier kunnen worden gereconstrueerd.

Leg vast welke aanvullende bron nodig zou zijn en wie die mag gebruiken. Een export, logbestand of bevestiging kan helpen, maar ook die informatie heeft grenzen. De vraag of verloren werk volledig kan worden teruggevonden blijft open zolang dat niet werkelijk is beoordeeld. Vermijd een algemene belofte dat gegevensverlies uitgesloten is.

Neem afhankelijkheden mee in het verslag

Een werkbestand kan een programma, lettertype, sjabloon of gekoppeld bestand nodig hebben. Een applicatie kan afhankelijk zijn van accounts, configuratie of een externe dienst. Noteer tijdens de oefening welke afhankelijkheden onverwacht naar voren komen en of die in de bestaande herstelprocedure zijn beschreven.

Bewaar geen gevoelige configuratie in het openbare artikel of een vrij gedeeld rapport. Het verslag kan verwijzen naar een afgeschermde technische bijlage. Voor het bedrijfsbesluit is vaak voldoende om te weten welke afhankelijkheid ontbreekt, wat de gevolgen zijn en wanneer de gerichte hercontrole plaatsvindt.

Spreek met de leverancier over werk, niet alleen over licenties

Als je ICT-beheer uitbesteedt, vraag dan wie de back-ups controleert, wie hersteltests uitvoert en welke werkzaamheden in het abonnement zitten. De aanwezigheid van een back-uplicentie maakt nog niet duidelijk wie een mislukte taak opvolgt of hoeveel herstelwerk beschikbaar is.

Laat de leverancier het resultaat van een concrete test toelichten. Welke kopie is gebruikt? Waar is hersteld? Welke handelingen zijn beoordeeld? Welke problemen bleven open? Een kort, begrijpelijk verslag geeft je meer informatie dan alleen de algemene mededeling dat alles groen staat.

Maak ook duidelijk welke werkzaamheden jij als ondernemer moet doen. Misschien moet een medewerker de bestanden beoordelen, moet je een procesprioriteit kiezen of moet je toestemming geven voor een test met echte gegevens. Neem die tijd en verantwoordelijkheid mee in de afspraak. Onze gids over de prijs van een ICT-beheerabonnement helpt om de werkzaamheden concreet te beschrijven.

Kies een herhaalmoment dat past bij verandering

Een geslaagde proef blijft een waarneming op een bepaalde datum. Veranderingen aan software, accounts, bestanden en leveranciers kunnen invloed hebben op de volgende herstelactie. Maak daarom vooraf duidelijk wanneer je de test herhaalt en welke wijzigingen aanleiding zijn voor een eerdere controle.

Een vaste frequentie kan helpen, maar kies die niet uitsluitend omdat een voorbeeldkaart een kalenderdatum vraagt. Kijk naar het belang van het proces, de hoeveelheid verandering en de gevolgen van stilstand. Het geschikte interval verschilt per bedrijf en per systeem. Laat de beheerder de keuze onderbouwen.

Controleer daarnaast of meldingen over gewone back-uptaken worden opgevolgd. Een periodieke hersteltest vervangt die dagelijkse uitvoering niet. Als taken al enige tijd mislukken, kan de eerstvolgende oefening met een oude kopie een misleidend beeld geven van de actuele situatie. Benoem daarom altijd de gekozen kopie en de actuele bekende beperkingen.

Rond de testomgeving zorgvuldig af

Spreek vóór de uitvoering af wat na afloop met de testkopie gebeurt. Bewaar alleen wat nodig is voor een onderbouwd verslag en eventuele gerichte hercontrole. Laat tijdelijke toegang en kopieën volgens de afgesproken procedure afhandelen door de bevoegde beheerder.

Controleer dat de productieomgeving ongemoeid is gebleven en dat geen testtaak later alsnog berichten of wijzigingen gaat uitvoeren. Een proef is pas afgerond wanneer ook die nazorg is gedaan. Leg in de kaart vast wie dit heeft bevestigd en welke open acties nog bestaan.

Een probleem in de test hoeft niet te betekenen dat de productie direct moet worden veranderd. Beoordeel eerst oorzaak, risico en mogelijke oplossing. Een haastige ingreep kan nieuwe problemen maken. Behandel de oplossing als een afzonderlijke wijziging met een passende controle en een mogelijkheid om terug te keren.

Gebruik de uitkomst in je bedrijfsbesluit

Bespreek na de oefening of het resultaat past bij het doel dat je vooraf had gekozen. Misschien is technisch herstel mogelijk, maar duurt het verzamelen van toegang te lang. Misschien zijn de bestanden bruikbaar, terwijl een belangrijke applicatie nog niet is getest. Maak die verschillen herkenbaar.

Kies vervolgens één concrete verbetering. Dat kan betere documentatie zijn, een duidelijkere rolverdeling of een uitbreiding van de volgende test. Leg niet meteen een brede zekerheid vast over het hele bedrijf. Bouw de onderbouwing stap voor stap op en houd de grenzen van iedere proef zichtbaar.

Voor een startend ICT-bedrijf kan deze werkwijze ook helpen om afspraken met klanten eerlijk te formuleren. Beschrijf wat je werkelijk uitvoert, welk bewijs je levert en welke onderdelen buiten je opdracht vallen. Een hersteldoel dat nog niet is getest hoort als doel te worden gepresenteerd, niet als vaststaand resultaat.

Maak van een afwijking een toetsbare vervolgactie

Een herstelverslag wordt bruikbaar wanneer een open punt een duidelijke vervolgstap krijgt. “De applicatie werkte niet helemaal” is te algemeen. Noteer welke handeling mislukte, welke uitkomst je verwachtte en welke informatie nog ontbreekt. Laat geheime configuratie en echte persoonsgegevens buiten het algemene verslag.

In het fictieve ontwerpbureau is het probleem niet dat alle bestanden ontbreken. De geselecteerde bestanden zijn teruggezet, maar de weergave van één document hangt af van een lettertype. De actie kan zijn om vast te stellen welke rechtmatig gebruikte afhankelijkheden bij de herstelprocedure horen en hoe de beheerder die beschikbaar maakt. Daarna wordt dezelfde afgesproken handeling opnieuw beoordeeld.

Verander de succescriteria niet om een probleem weg te schrijven. Als de medewerker een document in de vereiste vorm moet kunnen gebruiken, blijft een onjuiste weergave relevant. Je kunt de testgrens in een volgende proef veranderen, maar leg dan uit waarom. Het eerdere resultaat blijft een beperkte waarneming met de toen geldende criteria.

Een herhaling hoeft niet altijd het hele bedrijf te omvatten. Begin met het gerichte probleem en bepaal vervolgens of de oplossing invloed heeft op andere onderdelen. Een aangepast herstelbestand kan bijvoorbeeld aanleiding zijn om opnieuw te controleren welke versie wordt gebruikt. Bewaar de relatie tussen de oorspronkelijke afwijking, de wijziging en de hercontrole.

Onderscheid een oefening van een echt incident

Deze kaart is bedoeld om vooraf te oefenen. Tijdens een werkelijk incident kunnen andere vragen voorrang krijgen, zoals het veiligstellen van informatie, het beperken van schade en het onderzoeken van de oorzaak. Een teruggezette kopie is niet vanzelf veilig of geschikt wanneer niet bekend is wat er misging. Volg dan het incidentplan en betrek de verantwoordelijke deskundigen.

Voer tijdens een oefening geen ongeplande aanvalstest uit en schakel geen beveiliging uit om een herstel sneller te laten verlopen. Dat verandert de aard en het risico van het werk. De bevoegde beheerder moet weten wat de proef omvat en welke grenzen gelden. Een gewone hersteltest geeft geen toestemming om andere systemen te onderzoeken of toegang uit te breiden.

Zet ook geen oefenresultaat om in een algemene verklaring dat er geen datalek of beveiligingsprobleem bestaat. De test beantwoordt alleen de vooraf gekozen herstelvragen. Voor een incidentbeoordeling zijn andere feiten nodig. Houd die onderwerpen in het verslag gescheiden, zodat een beperkte proef niet als een bredere veiligheidscontrole wordt gelezen.

Als er tijdens de proef onverwachte gevoelige gegevens of tekenen van een echt probleem zichtbaar worden, stop dan de betreffende handeling en volg de afgesproken meldroute. Beschrijf in het gewone verslag alleen wat nodig is om de situatie te herkennen. Deel technische details en gegevens uitsluitend met de bevoegde personen via de afgesproken kanalen.

Wat bewaar je als bewijs?

Een bruikbaar bewijs bestaat uit de testgrens, het gekozen kopiemoment, de uitgevoerde controles en de uitkomst. Voeg de tijden toe als je hersteltijd hebt gemeten. Een screenshot kan helpen, maar een afbeelding van een groen scherm zonder uitleg vertelt niet welk bestand, systeem of proces is onderzocht.

Leg vast wie de technische controle en de functionele beoordeling heeft gedaan. Vermeld ook wanneer een conclusie alleen op een melding van de leverancier berust. Je hoeft niet te doen alsof je zelf een handeling hebt gezien wanneer je een rapport hebt ontvangen. Dat onderscheid helpt bij een latere herhaling of overdracht.

Bepaal hoe lang je het verslag nodig hebt en wie erbij mag. Een beknopt verslag zonder geheimen is makkelijker veilig te beheren dan een map met volledige exports en schermafbeeldingen van klantgegevens. Bewaar de noodzakelijke technische details afgeschermd en verwijs er alleen naar. De herstelkaart is een overzicht, geen vervanging van het beveiligde beheer van je omgeving.

Veelgestelde vragen

Kan ik een back-up over mijn gewone werkmap terugzetten om te testen?

Doe dat niet als algemene proef. Je kunt daarmee actuele gegevens overschrijven. Laat een bevoegde beheerder een passende testplek en werkwijze bepalen op basis van de gebruikte software en gegevens. De juiste herstelstappen verschillen per product; volg daarvoor de actuele officiële handleiding en de afspraken met je beheerder.

Is een controle van drie bestanden voldoende?

Dat kan een nuttige eerste deeltest zijn wanneer je precies vastlegt wat ermee is onderzocht. Het bewijst niet dat alle bestanden, applicaties en bedrijfsprocessen herstelbaar zijn. Kies vervolgstappen op basis van de gevonden beperkingen en de belangrijkste risico’s voor je bedrijf.

Wie bepaalt of de test is geslaagd?

Spreek dat vooraf af. De technische uitvoerder beoordeelt de herstelactie en de verantwoordelijke voor het bedrijfsproces beoordeelt de afgesproken bruikbaarheid. Leg afwijkingen vast in plaats van één algemeen groen vinkje te gebruiken voor verschillende controles.

Wat kan ik vandaag voorbereiden zonder iets terug te zetten?

Kies één proces, benoem de gewenste uitkomst en bespreek de testgrens met je beheerder. Zoek de officiële herstelprocedure op, wijs de beoordelaars aan en vul de lege herstelkaart in. Voer het daadwerkelijke herstel pas uit wanneer toegang, testplek, gevolgen en bevoegdheden duidelijk zijn.

Bronnen en verantwoording

De primaire bronnen zijn gecontroleerd op 9 november 2026. De herstelkaart, de afbakening en het ontwerpbureau zijn eigen redactionele uitwerkingen. Er is voor dit artikel geen echte klantomgeving getest. De tijden en projectgegevens in het voorbeeld zijn fictief.

• NCSC: Hoe test ik een back-up? voor het onderscheid tussen technisch en functioneel testen.
• NCSC: Een back-upstrategie opstellen voor hersteldoelen, toegang, monitoring en periodiek testen.
• NCSC: Waarom een back-up maken? voor het doel van een reservekopie bij verstoring of gegevensverlies.

Verder lezen: herstelvolgorde bij een IT-storing, een ICT-beheerabonnement afbakenen en een eigen ICT-bedrijf starten.

Deze uitleg is met AI-ondersteuning opgesteld. De bronnen zijn gecontroleerd; laat de concrete herstelprocedure en risico’s voor jouw omgeving beoordelen door een bevoegde ICT-beheerder.