Back-up testen met een restoretest: zo weet je dat herstel werkt

Een back-up test je pas echt door gegevens terug te zetten en te kijken of je er weer mee kunt werken. Een groene melding in je back-upsoftware laat alleen zien dat de taak is gedraaid. Of je bestanden, mailboxen en systemen bruikbaar terugkomen, en hoe lang dat duurt, weet je pas na een restoretest. In dit artikel lees je welke soorten tests er zijn, hoe vaak je ze doet, hoe je een hersteltest veilig uitvoert en wat je vastlegt. Ook de disaster recovery test komt aan bod: de oefening waarin je kijkt of je hele bedrijf weer kan draaien.

Kort samengevat

• ✅ Een geslaagde back-upmelding is geen bewijs dat herstel werkt. Het NCSC adviseert om naast de technische controle ook echt een herstelactie uit te voeren.
• 🔁 Test in lagen: losse bestanden vaak, complete systemen regelmatig en een volledige disaster recovery test minstens eens per jaar.
• ⏱️ Klok elke test en leg de uitkomst naast je gewenste hersteltijd (RTO) en je maximaal aanvaardbare dataverlies (RPO).
• 📝 Schrijf elke test dezelfde dag op, inclusief wat er misging en de datum van de volgende test.
• ⚖️ Voor organisaties onder NIS2 of DORA is het testen van herstel geen keuze meer, maar een eis.

Inhoudsopgave

• Waarom een groene back-upmelding niet genoeg is
• Drie niveaus van testen: van bestand tot disaster recovery
• Hoe vaak test je je back-ups en je disaster recovery?
• Stappenplan: zo voer je veilig een restoretest uit
• Hersteltijd en dataverlies meten: RTO en RPO
• Wat leg je vast na een test?
• Wat doe je als de hersteltest mislukt?
• Welke regels gelden voor het testen van herstel?
• Onze kijk op back-up testen
• Back-up en herstel uitbesteden aan ASTIA
• Veelgestelde vragen
• Bronnen

Waarom een groene back-upmelding niet genoeg is

Back-upsoftware meldt dat een taak geslaagd is als de kopie is weggeschreven. Dat zegt weinig over wat er gebeurt als je die kopie nodig hebt. In de praktijk gaat herstel om drie redenen mis:

1. De scope klopt niet. Een server, database of configuratie zat nooit in de back-up. Denk aan een nieuwe schijf die na een uitbreiding niet is toegevoegd, of een cloudapplicatie waarvan iedereen dacht dat de leverancier de back-up regelde.
2. De data is beschadigd. De taak liep goed, maar de kopie raakte onderweg of op de opslag beschadigd, bijvoorbeeld door een onderbroken schrijfactie.
3. Er ontbreken afhankelijkheden. Het herstel lukt technisch, maar de applicatie start niet omdat een licentie, een versleutelingssleutel, een wachtwoord of een gebruikersinstelling ontbreekt.

De eerste twee problemen vang je deels op met automatische controles. Het derde ontdek je alleen door echt terug te zetten en de applicatie te gebruiken. Daarom maakt het NCSC onderscheid tussen een technische en een functionele test: bij de technische test controleer je of de software succes meldt en voer je een herstelactie uit. Bij de functionele test zet je een volledige back-up terug en probeer je je bedrijfsprocessen uit. Het NCSC wijst er ook op dat je blijft controleren of geautomatiseerde back-ups en hersteltests technisch slagen, zodat je niet pas bij een echte storing ontdekt dat het al een tijd fout gaat.

Een ander risico zit in de mensen. Vaak weet één collega of één externe partij hoe het herstel werkt. Staat die procedure alleen in iemands hoofd, dan heb je bij ziekte, vakantie of een vertrek geen werkend plan. Een goede test maakt dat zichtbaar.

Drie niveaus van testen: van bestand tot disaster recovery

Niet elke test hoeft groot te zijn. Het werkt het best als je in lagen denkt. Hoe zwaarder de test, hoe minder vaak je hem doet, maar hoe meer je ervan leert.

Niveau 1: itemherstel

Dit is de test die het vaakst gebeurt, vaak zonder dat je het een test noemt. Een collega gooit per ongeluk een map weg en jij zet die terug. Maak er een bewuste routine van: kies elke keer een ander soort item, zoals een Excel-bestand van de administratie, een mailbox van een vertrokken medewerker of een SharePoint-map. Controleer of het bestand opent en of het de laatste versie is.

Niveau 2: systeemherstel

Hier zet je een heel systeem terug, bijvoorbeeld je boekhoudserver of de database van je planningssoftware. Doe dit in een afgeschermde testomgeving, zodat het herstelde systeem niet botst met je live omgeving. Je kijkt of het systeem start, of gebruikers kunnen inloggen en of de koppelingen met andere software werken.

Niveau 3: de disaster recovery test

De disaster recovery test is de generale repetitie. Je speelt een scenario na, zoals een uitgevallen kantoor of een ransomware-aanval, en kijkt of je de belangrijkste processen weer op gang krijgt. Daar hoort meer bij dan data: wie neemt welk besluit, hoe bereik je klanten, werkt de telefonie nog en kunnen medewerkers thuis verder. Heb je nog geen uitgewerkt plan, begin dan met een praktisch disaster recoveryplan en test daarna dat plan.

Een disaster recovery test kan ook klein beginnen. Een tafeloefening, waarbij je met het team het scenario stap voor stap doorloopt zonder iets technisch aan te raken, laat al snel zien waar het plan gaten heeft.

Hoe vaak test je je back-ups en je disaster recovery?

Eén vast getal voor iedereen bestaat niet. De frequentie hangt af van hoe kritiek een systeem is en hoeveel er in je omgeving verandert. Wel zijn er duidelijke ankerpunten.

Het Security Expertise Centrum van SURF stelt dat een disaster recovery plan minimaal jaarlijks wordt beoordeeld en periodiek getest. Het raadt aan het plan minstens eens per twee jaar te testen, en een volledige parallelle test of een test met echte uitval minstens eens per vijf jaar.

Voor het mkb werken wij liever met een strakker ritme, omdat de impact van een dag stilstand in een klein bedrijf groot is. Een praktisch schema ziet er zo uit:

Test daarnaast altijd extra na een grote wijziging. Denk aan een cloudmigratie, een nieuwe server, een andere back-upleverancier of een nieuwe kernapplicatie. Juist dan valt er makkelijk iets buiten de back-up.

💡 Tip: zet de tests als terugkerende afspraak in de agenda, met een vaste eigenaar. Wat niet gepland is, gebeurt niet.

Stappenplan: zo voer je veilig een restoretest uit

Een hersteltest mag je live omgeving nooit in gevaar brengen. Volg daarom een vaste werkwijze.

1. Kies een scenario. Bepaal wat je terugzet en waarom. Bijvoorbeeld: “De financiële administratie is per ongeluk overschreven” of “De fileserver is versleuteld door ransomware”.
2. Kies een veilige bestemming. Zet terug naar een aparte map, een testaccount of een afgeschermd netwerk. Overschrijf nooit productiedata voor een test.
3. Laat iemand anders het doen. Laat de test uitvoeren door een collega die het normaal niet doet, met alleen de schriftelijke procedure als hulp. Zo ontdek je of de instructie compleet is.
4. Klok de tijd. Noteer het moment waarop je begint en het moment waarop het systeem echt bruikbaar is. Niet het moment waarop de restore klaar is, maar het moment waarop een gebruiker weer kan werken.
5. Controleer of alles compleet is. Kijk naar de datum van de laatste data, gebruikers en rechten, koppelingen met andere software en bestanden die buiten de database staan, zoals bijlagen of scans.
6. Laat een gebruiker meekijken. Iemand die dagelijks met het systeem werkt, ziet direct of er iets mist. Vraag die persoon een paar normale handelingen te doen, zoals een factuur openen of een planning aanpassen.
7. Ruim netjes op. Verwijder de testomgeving of sluit hem af, zodat er geen tweede kopie van gevoelige data blijft rondslingeren.
8. Leg het dezelfde dag vast. Wacht niet tot volgende week. Details vergeet je snel.

Werk je met Microsoft 365? Neem dan ook mailboxen, OneDrive en Teams-bestanden mee in je tests. Veel ondernemers gaan ervan uit dat alles in de cloud automatisch veilig staat. Hoe je die omgeving goed inricht, lees je in ons artikel over AVG en Microsoft 365.

Hersteltijd en dataverlies meten: RTO en RPO

Een test is pas echt nuttig als je de uitkomst ergens tegen kunt afzetten. Daarvoor gebruik je twee begrippen:

• RTO (Recovery Time Objective): hoe lang een systeem maximaal mag uitliggen. Bijvoorbeeld: de kassa moet binnen vier uur weer werken.
• RPO (Recovery Point Objective): hoeveel data je maximaal mag kwijtraken, uitgedrukt in tijd. Bijvoorbeeld: je accepteert hooguit één werkdag aan verloren mail.

Meet de RTO over het hele pad tot een werkend systeem. Daar horen ook de minder zichtbare stappen bij: het besluit om te herstellen, het kiezen van het juiste herstelpunt, het klaarzetten van de omgeving, het terugzetten zelf, het opstarten, het controleren en het weer aansluiten van gebruikers. Een database die in een kwartier terug is, kan in de praktijk alsnog twee uur nodig hebben voordat iedereen weer werkt.

Meet de RPO aan de data die je na herstel echt kunt gebruiken, niet aan het tijdstip van de back-uptaak. Stond de laatste nachtelijke back-up erin, maar is de database van die nacht niet bruikbaar? Dan is je werkelijke RPO de back-up daarvoor.

Leg beide uitkomsten naast je doelen. Haal je ze niet, dan heb je twee opties: de techniek aanpassen, bijvoorbeeld vaker back-ups maken of sneller herstellen vanuit de cloud, of de afspraken met de business bijstellen. Hoe lang je back-ups bewaart speelt hier ook mee. Lees daarvoor ons stuk over het opstellen van een back-up retentiebeleid.

Wat leg je vast na een test?

Een test die niet is opgeschreven, is voor een verzekeraar, een auditor of een toezichthouder nooit gebeurd. Zorg dat elk testverslag deze punten bevat:

• 📅 datum en tijd van de test
• 👤 wie de test uitvoerde en wie meekeek
• 📂 wat er is teruggezet en van welke datum de back-up was
• 📍 waarheen het is teruggezet
• ⏱️ de doorlooptijd, van start tot werkend systeem
• ✅ de uitkomst, gemeten tegen RTO en RPO
• ⚠️ wat er niet goed ging en welke actie daarop volgt
• 🔜 de datum van de volgende test

Wees eerlijk in je verslag. Een verslag met een paar kanttekeningen en concrete acties laat zien dat je het proces serieus neemt. Die vervolgdatum maakt van een losse actie een proces. Steeds vaker vragen verzekeraars naar dit soort bewijs. Welke IT-eisen een verzekeraar stelt, lees je in ons artikel over cyberverzekering en IT-eisen.

Wat doe je als de hersteltest mislukt?

Een mislukte test is goed nieuws: je ontdekt het probleem nu, en niet tijdens een echte storing. Pak het zo aan:

1. Stel vast waar het misging. Ging het om de scope, beschadigde data of een ontbrekende afhankelijkheid?
2. Los de oorzaak op. Voeg het ontbrekende systeem toe aan de back-up, vervang de opslag, of bewaar licentiesleutels en wachtwoorden op een veilige plek buiten het systeem.
3. Pas de procedure aan. Werk de schriftelijke instructie bij met wat je hebt geleerd.
4. Test opnieuw. Plan de hertest binnen korte tijd en sluit het punt pas als die slaagt.

Let bij een echt incident op één extra punt: een geslaagde restore betekent niet dat de oorzaak weg is. Na een ransomware-aanval kun je zomaar een besmet herstelpunt terugzetten. Controleer daarom eerst de bron, de gebruikersrechten en de koppelingen voordat je teruggaat naar productie, en laat de verantwoordelijke IT- en proceseigenaar het herstel vrijgeven. In ons ransomware herstelplan lees je hoe je dat stap voor stap doet.

Welke regels gelden voor het testen van herstel?

Voor veel mkb-bedrijven is testen vooral gezond verstand. Voor een groeiende groep is het ook een wettelijke verplichting.

• NIS2: de uitvoeringsverordening bij NIS2 vraagt dat relevante entiteiten regelmatig het herstel van back-ups testen, de resultaten documenteren en waar nodig corrigerende maatregelen nemen. Ook als je zelf niet onder NIS2 valt, kan een klant die dat wel doet deze eisen aan jou als leverancier doorgeven.
• DORA: voor financiële organisaties schrijft artikel 12 van DORA back-upbeleid, herstelprocedures en periodieke tests voor. Bij herstel met eigen systemen moeten die systemen fysiek en logisch gescheiden zijn van het bronsysteem.
• AVG: artikel 32 vraagt om de beschikbaarheid van persoonsgegevens tijdig te kunnen herstellen en om maatregelen regelmatig te testen en te evalueren. Een back-upbeleid dat nooit met een echte restore is getest, sluit daar slecht op aan.

De basis onder al deze regels is een goede back-upopzet. Bewaar meerdere kopieën op verschillende plekken, waarvan één buiten je kantoor. Hoe dat werkt, lees je in de 3-2-1 back-upregel uitgelegd.

Onze kijk op back-up testen

Wij zien het vaak bij ondernemers die bij ons aankloppen: er is een back-up, de meldingen zijn groen, en toch weet niemand hoe lang herstel duurt of wat er precies in die back-up zit. Dat is geen verwijt. Een klein bedrijf heeft geen tijd om elk kwartaal een server terug te zetten in een testomgeving.

Daarom vinden wij dat back-up en herstel bij het fundament van je IT horen, en niet bij een los product van een losse leverancier. Als dezelfde partij je werkplekken, netwerk, telefonie en cloud beheert, weet die ook welke koppelingen, licenties en accounts nodig zijn om weer te kunnen werken. Precies die afhankelijkheden gaan bij herstel het vaakst mis.

Met 24/7 monitoring zien wij problemen aankomen voordat ze een storing worden. En gaat er toch iets mis, dan bel je ons direct. Geen ticket, geen wachtrij, maar iemand die je omgeving kent.

Mick

Back-up en herstel uitbesteden aan ASTIA

Wil je zeker weten dat je bedrijf na een storing, een fout of een aanval snel weer draait? Bij ASTIA nemen we back-up en disaster recovery voor het mkb op in het totale beheer van je IT. Je betaalt een vaste, transparante prijs per werkplek en je hebt één aanspreekpunt voor werkplekken, netwerk, telefonie, cloud en beveiliging.

Benieuwd hoe dat er voor jouw bedrijf uitziet? Bekijk wat het betekent om je IT uit te besteden en neem contact met ons op. We denken graag met je mee vanuit Vianen, voor bedrijven in de regio Utrecht en daarbuiten.

Veelgestelde vragen

Wat is het verschil tussen een back-uptest en een restoretest?

Bij een back-uptest controleer je vaak alleen of de back-uptaak is geslaagd en of de software de kopie kan lezen. Bij een restoretest zet je de data echt terug en controleer je of je ermee kunt werken. Alleen de restoretest laat zien of herstel in de praktijk lukt en hoe lang het duurt.

Wat is een disaster recovery test?

Een disaster recovery test is een oefening waarin je een groot incident naspeelt, zoals uitval van je kantoor of een ransomware-aanval. Je test niet alleen de data, maar ook de afspraken, rollen, communicatie en systemen die nodig zijn om je bedrijf weer te laten draaien. Doe zo’n test minstens eens per jaar en na grote wijzigingen.

Kan een restoretest mijn live omgeving verstoren?

Niet als je hem goed opzet. Zet altijd terug naar een aparte locatie, een testaccount of een afgeschermd netwerk, en overschrijf nooit productiedata. Ruim de testomgeving na afloop op, zodat er geen extra kopie van gevoelige gegevens blijft staan.

Moet ik ook mijn Microsoft 365-gegevens testen?

Ja. Mailboxen, OneDrive, SharePoint en Teams bevatten vaak je belangrijkste bedrijfsdata. Neem deze onderdelen op in je back-up én in je restoretests, bijvoorbeeld door elk kwartaal een mailbox of een SharePoint-map terug te zetten naar een testlocatie.

Hoe lang duurt een restoretest?

Het terugzetten van een los bestand of een map kost meestal minder dan een kwartier. Een complete server herstellen in een testomgeving kost al snel een dagdeel. Een volledige disaster recovery test vraagt voorbereiding en vaak een hele dag met meerdere mensen.

Bronnen

• NCSC: Hoe test ik een back-up?
• SURF Security Expertise Centrum: Disaster Recovery Plan
• NIS2 Guide 4.2.6: Testing of backup and recovery processes
• DORA artikel 12: Backup policies and procedures, restoration and recovery
• GDPR Disaster Recovery: What Article 32 Requires

Aanbevelingen

• Back-up en disaster recovery: zo overleeft je bedrijf een datacrisis
• MKB: binnen uren herstellen met een praktisch disaster recoveryplan
• De 3-2-1 backup regel uitgelegd voor het MKB
• Backup retentiebeleid opstellen: zo bepaal je de juiste bewaartermijnen