Backup en hersteltest: kun je werkelijk weer verder?

Een backup is een middel, geen afgerond herstelplan

Een backup bewaart informatie waarmee herstel mogelijk kan zijn. Een herstelplan beschrijft wat je ermee doet. Een hersteltest levert bewijs dat een deel van dat plan onder de geteste omstandigheden uitvoerbaar is. Die drie begrippen horen bij elkaar, maar zijn niet uitwisselbaar.

De Amerikaanse beveiligingsdienst CISA adviseert om backups van kritieke gegevens afgescheiden en versleuteld te bewaren en de beschikbaarheid en integriteit regelmatig te testen. Het belangrijke woord voor dit artikel is testen: aanwezigheid alleen is niet het eindpunt. CISA StopRansomware Guide.

Wij willen daarom niet alleen horen dat er iedere nacht ‘iets wordt opgeslagen’. We willen weten welke onderdelen zijn opgenomen, wie erbij kan, welke periode beschikbaar is en wanneer terugzetten daadwerkelijk is geprobeerd.

Herstel is niet hetzelfde als een beveiligingsupdate

Een backup repareert geen kwetsbare PHP-versie. Als je een oude omgeving terugzet waarin hetzelfde probleem nog aanwezig is, kan de oorspronkelijke oorzaak blijven bestaan. Herstel en onderhoud moeten daarom samen worden beoordeeld, maar blijven afzonderlijke taken.

Bij de PHP-kwetsbaarheid van oktober 2026 hoort een actueel technisch advies. Dit artikel vervangt dat niet. Het helpt je bepalen of je een veilige terugweg hebt wanneer een wijziging of storing fout gaat.

Een bruikbare herstelbeslissing zegt dus niet alleen ‘welke backup nemen we?’, maar ook ‘in welke omgeving herstellen we en welke oorzaak moet vóór heropening zijn aangepakt?’ Dat voorkomt dat beschikbaarheid wordt hersteld ten koste van hetzelfde bekende probleem.

Begin bij wat je bedrijf moet kunnen blijven doen

Maak een lijst van de processen waarvoor de website nodig is. Voor een dakdekker kan een werkend aanvraagformulier belangrijker zijn dan de volledige projectgalerij. Voor een cursusaanbieder zijn inschrijvingen en toegang tot lesmateriaal mogelijk essentieel. Voor een webshop zijn bestellingen en betalingstoestanden cruciaal.

Die prioriteiten moet de eigenaar bepalen. Een beheerder kan uitleggen wat technisch mogelijk is, maar weet niet automatisch welke onderbreking het bedrijf het zwaarst raakt. Begin daarom met een kort gesprek over gevolgen, niet met opslagruimte en bestandsformaten.

Vraag per proces: wat gebeurt er als dit een uur niet werkt? Wat als het een dag niet werkt? Welke handmatige uitwijkroute bestaat? Welke informatie mogen we beslist niet kwijtraken? Gebruik je eigen situatie; neem geen standaardtijd over omdat die professioneel klinkt.

Twee verschillende grenzen

Wij leggen voor een herstelplan twee keuzes apart vast. De eerste is hoeveel tijd je voor herstel kunt accepteren. De tweede is hoeveel recente informatie je eventueel opnieuw zou moeten verwerken. Dat zijn verschillende vragen.

Een fictief adviesbureau kan tijdelijk telefonisch bereikbaar blijven als het formulier uitvalt. Het wil echter geen aanvraag verliezen die iemand eerder op de dag heeft ingestuurd. Een andere organisatie kan aanvragen opnieuw uit een extern systeem ophalen, maar kan haar klanten niet lang zonder login laten.

Schrijf de grenzen in gewone taal op en laat de beheerder aangeven of de huidige inrichting daarbij past. Een afspraak over gewenst herstel is nog geen bewezen prestatie. Pas een test laat zien wat onder de onderzochte omstandigheden werkelijk haalbaar was.

Wat hoort er in de herstelset?

Voor een typische WordPress-website zijn zowel bestanden als de database nodig. Bestanden bevatten bijvoorbeeld de applicatieonderdelen en uploads; de database bevat andere noodzakelijke websitegegevens. Alleen een map downloaden is dus niet vanzelf een volledige herstelset. WordPress-handboek over backups.

Maak daarnaast zichtbaar welke instellingen en externe afhankelijkheden nodig zijn om de website bruikbaar te maken. Denk niet alleen aan het uiterlijk, maar aan de functies die gegevens lezen, verwerken of doorsturen.

Je hoeft niet alle geheime waarden in een herstelmap te stoppen. Je moet wel weten hoe een bevoegde beheerder tijdens herstel de juiste toegang en configuratie kan verkrijgen. Een herstelplan met gekopieerde wachtwoorden in een gedeeld document creëert een nieuw probleem.

De ontbrekende onderdelen vallen vaak buiten de website

Een website kan voor mail, afspraken, betalingen of klantgegevens afhankelijk zijn van andere diensten. Een backup van WordPress herstelt niet automatisch de toestand van die diensten. Leg daarom per koppeling vast welk systeem leidend is en wie toegang heeft.

Neem een fictieve boekingswebsite. De website toont een reservering, een agenda houdt het tijdstip bij en een betaalprovider registreert de betaling. Na herstel moet je kunnen verklaren welke gegevens bij elkaar horen. Je wilt niet dat iemand opnieuw betaalt omdat de website een oudere toestand toont.

Wij zouden voor iedere belangrijke koppeling een korte herstelvraag opnemen: welke waarheid halen we waar op, hoe vergelijken we de gegevens en wie mag een verschil corrigeren? Dat is vaak waardevoller dan nog een extra kopie van dezelfde websitebestanden.

De nieuwste backup is niet altijd de juiste

Bij een gewone bedieningsfout kan een recent herstelpunt geschikt zijn. Bij een mogelijk beveiligingsincident moet je ook rekening houden met de vraag wanneer de omgeving nog betrouwbaar was. Het meest recente bestand kan het probleem al bevatten.

Het Britse NCSC benadrukt daarom onder meer het belang van versiegeschiedenis en kunnen herstellen van een eerder punt wanneer latere kopieën beschadigd zijn. Het noemt ook testen als onderdeel van het beheer. NCSC-principes voor herstelbare backups.

Voor ons proces betekent dat: kies een herstelpunt met een reden. Noteer het tijdstip, de aanleiding en de beperkingen van je kennis. Noem een backup niet ‘schoon’ alleen omdat het bestand normaal opent. Bij aanwijzingen voor een inbraak hoort deskundig incidentonderzoek bij de beslissing.

Bewaar onderzoeksmogelijkheden

Wanneer een incident wordt vermoed, is blind overschrijven een slechte eerste reflex. Je kunt daarmee informatie verliezen die nodig is om de oorzaak en de omvang te begrijpen. Laat de verantwoordelijke beheerder bepalen welke gegevens en logs eerst veiliggesteld moeten worden.

Dat betekent niet dat de hele onderneming stil moet blijven wachten op een perfect onderzoeksrapport. Het betekent dat herstel en onderzoek gecoördineerd worden. Soms is een tijdelijke, beperkte dienstverlening mogelijk terwijl de verdachte omgeving afgeschermd blijft.

Leg steeds vast welke keuze is gemaakt en waarom. Een latere beheerder moet kunnen zien of een omgeving is hersteld na een gewone fout, een mislukte update of een vermoedelijk incident. Die context verandert welke controles nog nodig zijn.

Test op een afgeschermde bestemming

Een hersteltest hoort niet ongemerkt de live omgeving te overschrijven. Kies vooraf een afzonderlijke bestemming en laat bevestigen dat zij geschikt is voor de test. Benoem expliciet welke omgeving onaangeroerd moet blijven.

Scherm de testkopie af voor onbevoegden en zorg dat zij niet per ongeluk als normale website wordt gebruikt. Beoordeel bovendien welke uitgaande verbindingen actief mogen zijn. Een teruggezette kopie kan anders oude mails, taken of andere handelingen opnieuw uitvoeren.

Onze praktische testregel is eenvoudig: geen echte klantberichten, betalingen of voorraadmutaties zonder afzonderlijke toestemming en een passend testscenario. De bedoeling is herstel aantonen, niet het productieproces dubbel laten lopen.

Gebruik representatieve, beperkte gegevens

Sommige herstelvragen kun je met synthetische gegevens testen. Andere vereisen een gecontroleerde kopie van de werkelijke structuur. Laat de beheerder uitleggen wat noodzakelijk is en beperk toegang en bewaartermijn tot dat doel.

Een schermafbeelding van een herstelde klantlijst is meestal geen goed bewijs voor een algemeen onderhoudsverslag. Je kunt ook aantonen dat een afgesproken aantal records aanwezig is of dat een herkenbaar testrecord werkt, zonder persoonsgegevens breed te delen.

Bepaal vooraf wat na de test met de kopie gebeurt. Een vergeten herstelomgeving is geen onschuldige restpost als zij gegevens en applicatiecode bevat. Verwijderen of bewaren vraagt een duidelijke afspraak en een gecontroleerde uitvoering.

Maak van terugzetten een test met uitkomsten

Een testplan heeft niet genoeg aan ‘restore uitvoeren’. Je wilt beoordelen of de applicatie start, of de juiste gegevens aanwezig zijn en of de belangrijke functies werken. Iedere stap krijgt een verwachte uitkomst.

Wij gebruiken vier niveaus van bewijs. Eerst: de herstelset is beschikbaar. Daarna: terugzetten naar de afgesproken testomgeving lukt. Vervolgens: de noodzakelijke gegevens en instellingen zijn aanwezig. Tot slot: een representatieve gebruikersroute werkt zoals bedoeld.

Die niveaus helpen om nauwkeurig te rapporteren. Een geslaagde import is waardevol, maar is niet hetzelfde als een werkend klantportaal. Een werkende homepage is niet hetzelfde als een complete aanvraag die op de juiste bestemming aankomt.

Een bruikbare testkaart

Maak voor iedere noodzakelijke route een kaart met de volgende velden:

• Wat wordt hersteld en uit welk herstelpunt?
• Welke bestemming is uitsluitend voor deze test bedoeld?
• Welke handeling voert de tester uit?
• Welk resultaat moet zichtbaar zijn?
• Wat is daadwerkelijk waargenomen en op welk moment?
• Welk bewijs wordt bewaard, zonder onnodige gevoelige gegevens?
• Welke beperking of vervolgactie blijft over?

De laatste vraag voorkomt een overdreven eindconclusie. Als een externe koppeling bewust is uitgeschakeld, kun je haar werking niet als bevestigd registreren. Je kunt wel vastleggen hoe zij later apart wordt getest.

Meet de hele hersteltijd, niet alleen de bestandsoverdracht

Bij een storing begint het wachten eerder dan het moment waarop bestanden worden teruggezet. Iemand moet de fout herkennen, de juiste persoon bereiken, toegang krijgen en een herstelpunt kiezen. Daarna volgen controles en mogelijk aanvullende werkzaamheden.

Registreer tijdens de test daarom de belangrijkste tijdstippen. Wanneer begon de voorbereiding? Wanneer was de bestemming beschikbaar? Wanneer startte de applicatie? Wanneer was de belangrijkste functie gecontroleerd? Dat laat zien waar het werk werkelijk blijft hangen.

Een fictief bedrijf ontdekt zo dat het technische terugzetten snel gaat, maar dat toegang tot het backupaccount via één afwezige medewerker loopt. Meer opslag lost dat niet op. Een passende toegangs- en vervangingsafspraak doet dat mogelijk wel.

Gebruik de uitkomst als planning, niet als belofte

Een testduur is een waarneming onder specifieke omstandigheden. Een echt incident kan andere problemen geven. Meld daarom wanneer en hoe is getest, en welke voorwaarden toen gunstig waren.

Als de test veel langer duurt dan het bedrijf kan accepteren, volgt een keuze. Je kunt de inrichting verbeteren, een beperkte noodvoorziening voorbereiden of de gewenste dienstverlening tijdens een storing aanpassen. De eigenaar moet dat verschil kennen voordat het dringend wordt.

Herhaal niet alleen het getal in een offerte of onderhoudsrapport. Leg uit wat het betekent voor aanvragen, medewerkers en klanten. Dan kan het bedrijf zinvol besluiten waarin het wil investeren.

Behandel nieuwe gegevens na het herstelpunt apart

Tussen een backup en een herstel kunnen nieuwe aanvragen, accounts of bestellingen zijn ontstaan. Als je een oudere toestand terugzet, zijn die gegevens niet automatisch in die kopie aanwezig. Daarom hoort gegevensvergelijking bij het herstelplan.

Het NCSC noemt expliciet dat plannen moeten beschrijven hoe nieuw ontstane gegevens worden gevalideerd en samengebracht met teruggezette gegevens. NCSC over technisch herstel voorbereiden.

Onze praktische aanpak begint met een lijst van bronnen. Welke informatie staat ook in een mailbox, CRM, agenda of betaalprovider? Welke gegevens bestaan uitsluitend in de website? Wie kan verschillen beoordelen zonder op eigen houtje financiële of klantgegevens te wijzigen?

Voorkom dubbele handelingen

Een herstel mag niet betekenen dat een klant dezelfde bevestiging, bestelling of afschrijving opnieuw krijgt. Laat de verantwoordelijke beheerder daarom onderzoeken hoe herhaalde taken en externe berichten worden behandeld voordat de omgeving weer normaal gaat draaien.

Gebruik bij de test een fictieve gebeurtenis met een herkenbare referentie. Controleer of die gebeurtenis precies op de bedoelde plek staat en of een herhaalde verwerking ongewenste bijwerkingen zou hebben. Voer geen echte financiële handeling uit om dit te demonstreren.

Als een verschil menselijke beoordeling vraagt, zet het in een aparte lijst. Vermeld de bron en de vraag, niet meteen een zelfbedachte correctie. Zo blijft duidelijk wat technisch is vastgesteld en waar een bevoegd persoon een besluit moet nemen.

Bescherm ook de toegang tot de backups

Een backup die alleen bereikbaar is via dezelfde kwetsbare toegang als de website verdient extra aandacht. Vraag wie backups kan bekijken, verwijderen en herstellen. Dat zijn verschillende bevoegdheden die niet automatisch bij iedere beheerder hoeven te liggen.

Wij zouden ook een vervangingsscenario bespreken. Wat gebeurt er als de vaste beheerder niet beschikbaar is? Kan een bevoegde vervanger bij de benodigde procedure zonder eerst het uitgevallen systeem te gebruiken? Dat zijn eenvoudige vragen die tijdens een storing veel verschil kunnen maken.

Bewaar hersteltoegang niet als onbeveiligde bijlage bij het plan. Gebruik het afgesproken beveiligde beheer van toegangsgegevens. Het document beschrijft waar een bevoegde persoon moet zijn en wie toegang verleent; het bevat niet de geheime waarden zelf.

Versleuteling vraagt ook om herstelbare sleutels

Versleutelde opslag helpt niet wanneer de bevoegde organisatie bij herstel niet meer over de juiste sleutel of toegang beschikt. Laat daarom het toegangsproces zelf onderdeel van de test zijn, zonder sleutels zichtbaar te maken in een verslag.

Het NCSC neemt sleutelbeheer expliciet op in zijn principes voor backups die bestand moeten zijn tegen destructieve aanvallen. Dat onderstreept dat bescherming en herstelbaarheid samen moeten worden ontworpen. NCSC-backupprincipes.

Voor een kleine onderneming hoeft dit geen ingewikkelde organisatie te worden. Wel moet iemand kunnen uitleggen wie bevoegd is, welke vervanging bestaat en hoe ongewenste toegang wordt voorkomen. Een antwoord dat alleen de naam van een opslagdienst noemt, is nog niet volledig.

Kies bewaartermijnen op basis van je werk

Meer backups bewaren is niet automatisch de beste uitkomst. Opslag kost geld, oudere kopieën bevatten mogelijk gegevens die je niet onnodig wilt bewaren en een grote verzameling zonder overzicht kan herstel juist vertragen.

Bepaal daarom welke tijdsperiodes je nodig hebt om gewone fouten en later ontdekte problemen te kunnen onderzoeken. Koppel dat aan het soort gegevens en aan bestaande bewaarbeleidsafspraken. Laat specifieke wettelijke of contractuele vragen beoordelen door de daarvoor verantwoordelijke deskundige.

Onze voorkeur is een begrijpelijk schema met een eigenaar: wat wordt bewaard, hoe lang, waar en waarom? Controleer daarna of de ingestelde backupdienst werkelijk bij dat schema aansluit. Een beleid op papier en een instelling in een dashboard kunnen verschillen.

Een fictieve hersteltest voor een dienstverlener

Stel dat een onderhoudsbedrijf een website heeft met projectpagina's, een offerteformulier en een kleine klantomgeving. Nieuwe aanvragen worden ook in een CRM vastgelegd. De eigenaar wil vooral voorkomen dat aanvragen verdwijnen en dat klanten hun documenten niet meer kunnen bereiken.

Het team kiest een afgeschermde testomgeving en een vooraf bepaald herstelpunt. Uitgaande mails en andere echte klantacties worden voor de test geblokkeerd. De beheerder zet de omgeving terug en noteert de duur van voorbereiding, uitvoering en controle.

De publieke pagina's werken en het testaccount kan inloggen. Een document ontbreekt omdat het buiten de oorspronkelijke backupselectie stond. Dat is geen mislukking die verstopt moet worden. Het is precies de informatie waarvoor je test voordat een echte storing plaatsvindt.

De selectie wordt aangepast en dezelfde controle wordt opnieuw uitgevoerd. Daarna vergelijkt het team hoe aanvragen na het gekozen herstelpunt uit het CRM kunnen worden herkend. Het voert geen correcties in echte klantrecords uit; het beschrijft de noodzakelijke bevoegdheden en test met een afgesproken voorbeeld.

Het eindverslag benoemt welke routes bewezen werken en welke externe handelingen bewust niet zijn uitgevoerd. Het bedrijf heeft daarmee geen garantie op probleemloos herstel, maar wel een concreter en verbeterd herstelplan dan vóór de oefening.

Oefen ook zonder systemen terug te zetten

Een technische hersteltest en een gespreksoefening vullen elkaar aan. In een gespreksoefening loop je een fictieve storing door: wie merkt het, wie belt wie, wie beslist en welke informatie is nodig? Je verandert daarbij niets aan productie.

Zo ontdek je bijvoorbeeld dat het noodnummer alleen in de uitgevallen mailbox staat, of dat niemand weet wie een herstel mag goedkeuren. Die bevindingen kun je oplossen zonder eerst een ingewikkelde testomgeving te bouwen.

Gebruik de oefening niet als vervanging voor technisch bewijs. Een besproken plan blijft een besproken plan. Het wordt sterker wanneer de belangrijkste technische stappen daarna in een afgeschermde omgeving worden geprobeerd en de resultaten in hetzelfde overzicht terechtkomen.

Checklist voor een verantwoord herstelbesluit

Voordat een omgeving weer openbaar wordt, willen we antwoord op deze vragen:

1. Is de aanleiding voldoende begrepen om verantwoord te herstellen?
2. Is het gekozen herstelpunt passend en zijn onzekerheden benoemd?
3. Is de bestemming geschikt en is de oorspronkelijke oorzaak aangepakt of afgeschermd?
4. Zijn noodzakelijke gegevens, bestanden en instellingen aanwezig?
5. Werken de afgesproken gebruikersroutes?
6. Zijn nieuwe gegevens en externe systemen op verschillen beoordeeld?
7. Zijn ongewenste dubbele handelingen voorkomen?
8. Heeft de bevoegde eigenaar de heropening goedgekeurd?

Een onbeantwoorde vraag hoeft niet iedere vorm van dienstverlening onmogelijk te maken. Zij moet wel zichtbaar zijn in het besluit. Soms kan een beperkte functie eerder terugkomen terwijl andere onderdelen nog afgeschermd blijven. Maak die beperking duidelijk aan medewerkers en bezoekers.

Veelgestelde vragen

Vraag om herstelbewijs, niet alleen om een backupbelofte

Een goed herstelplan maakt duidelijk wat je kunt terugzetten, wie dat kan en welke controle nodig is voordat klanten weer verdergaan. Het geeft ook eerlijk aan wat nog niet is bewezen. Dat is bruikbaarder dan een algemeen geruststellend vinkje.

Wil je samen bepalen welke functies en gegevens voor jouw website als eerste herstelbewijs nodig hebben? Plan een gesprek. Dan beginnen we bij de bedrijfsprocessen die je niet kwijt wilt raken.