De back-up draait elke nacht. Er staat een groen vinkje in je dashboard en ergens ligt een map met bestanden. Zolang er niets gebeurt, is dat genoeg om rustig van te slapen.
Tot het moment waarop je hem nodig hebt. Een update die de site sloopt, een gehackte plugin, een medewerker die per ongeluk de verkeerde map leeggooit. En dan blijkt het antwoord op de vraag “hebben we een back-up?” verrassend vaak: we hebben een bestand, maar we weten niet of er een werkende website in zit.
Back-up testen betekent dat je je meest recente back-up daadwerkelijk terugzet op een kopie van je site en controleert of alles het doet. Niet kijken of het bestand bestaat, maar hem echt gebruiken. Dat kost je ongeveer een uur, en het is het verschil tussen een aanname en een zekerheid.
Hieronder lees je hoe vaak dat moet, waarom back-ups zo stilletjes falen, hoe je zelf in een uur een test doet, en wat de Cyberbeveiligingswet er per 15 augustus mee te maken heeft.
Hoe vaak moet je een back-up testen?
Verdient je site geld, dan maandelijks. Is hij vooral een visitekaartje, dan elk kwartaal. En daarnaast altijd na een grote wijziging: een nieuw thema, een verhuizing naar andere hosting, een flinke plugin-update of een aanpassing aan je back-upinstellingen.
Dat klinkt vaak. Maar een back-up die je een jaar geleden hebt getest zegt niets over de back-up van vannacht. In dat jaar is er van alles veranderd aan je site, je plugins en je server, en precies daar gaat het mis.
Waarom een back-up die “groen” staat toch kan falen
Een back-up faalt zelden met een luide knal. Hij faalt stil, en je merkt het pas op het slechtste moment. In onze praktijk komen steeds dezelfde vijf oorzaken terug.
- Wel bestanden, geen database. Je WordPress-site bestaat uit twee delen: de bestanden (thema, plugins, afbeeldingen) en de database (je pagina’s, berichten, bestellingen, instellingen). Veel back-uproutines pakken er maar een van. Zet je die terug, dan krijg je een lege huls terug: het uiterlijk klopt, de inhoud is weg.
- De back-up loopt in een time-out. Groeit je site, dan duurt de back-up langer. Op een gegeven moment tikt hij tegen de tijdslimiet van de server aan en stopt halverwege. Het bestand staat er, maar is incompleet. Sommige plugins melden dat netjes, veel niet.
- De back-up staat op dezelfde server als de site. Dan is het geen back-up maar een tweede kopie op dezelfde plek. Gaat de server onderuit of komt er ransomware langs, dan gaan site en back-up samen. Een back-up hoort offsite te staan, ergens waar de site zelf niet bij kan.
- De bewaartermijn is korter dan de tijd waarin je het probleem ontdekt. Dit is de vervelendste. Zit er zes weken malware in je site en gaan je back-ups veertien dagen terug, dan is elke beschikbare back-up besmet. Je hebt keurig back-ups en je hebt er niets aan.
- Niemand weet hoe je hem terugzet. Het bestand deugt, maar de kennis ontbreekt op het moment dat het telt. Op een dinsdagochtend met een platte webshop is dat geen moment om het uit te zoeken.
Dit is geen theoretisch risico. In het Data Trust and Resilience Report 2026 van Veeam zegt negentig procent van de ondervraagde securityverantwoordelijken snel te kunnen herstellen na een aanval, terwijl slechts achtentwintig procent daarna daadwerkelijk alle data terugkreeg. Dat gat tussen vertrouwen en werkelijkheid is precies wat een test wegneemt.
Zo test je je back-up in een uur
Je hebt hier geen technische achtergrond voor nodig, wel een rustig moment. Plan het op een dinsdagochtend, niet op vrijdagmiddag.
- Kijk eerst wat er in de back-up zit. Open of download de nieuwste back-up. Zie je zowel een map met bestanden als een databasebestand (meestal met de extensie .sql)? Zo niet, dan hoef je niet verder te zoeken: je vangnet heeft een gat.
- Zet hem terug op een kopie, nooit over je live site heen. Daar is een staging-omgeving voor. Je hoster of beheerder kan die in een paar minuten voor je klaarzetten. Terugzetten over je live site is precies hoe een test een incident wordt.
- Log in op de herstelde kopie als beheerder. Kom je erin? Dan werken de database en de gebruikersaccounts. Zo niet, dan weet je nu al genoeg.
- Test de functionaliteit, niet de opmaak. Een site die er goed uitziet kan prima kapot zijn. Verstuur het contactformulier, rond een testbestelling af, controleer of de nieuwsbriefkoppeling reageert en kijk of je blogbericht van vorige week erin staat. Dat laatste vertelt je meteen of de back-up echt recent is.
- Klok de tijd. Noteer hoe lang het terugzetten duurde. Dat is je echte hersteltijd, en meestal langer dan je dacht. Weet je die, dan kun je een klant of medewerker eerlijk vertellen hoe lang de site eruit ligt.
- Schrijf drie regels op. Datum, wie de test deed, wat er misging. Meer is het niet, en het is precies het bewijs waar een opdrachtgever, verzekeraar of toezichthouder om vraagt.
Ging er iets mis? Dat is goed nieuws, hoe raar dat ook klinkt. Je bent er nu achter, op een dinsdagochtend, in plaats van tijdens een storing. Hoe je een back-up in de praktijk terugzet, staat stap voor stap in onze gids over een WordPress-back-up terugzetten zonder downtime.
Wat het je kost als je het niet doet
Eerlijk verhaal: een test kost je ongeveer een uur. Twaalf keer per jaar is dat twaalf uur, tegen zestig euro per uur zo’n 720 euro als je het zelf inkoopt.
Daar staat tegenover wat er gebeurt als je back-up faalt op het moment dat je hem nodig hebt. Herstel van een gehackte of verloren MKB-site kost al snel 1.500 tot 8.000 euro aan reparatie, gemiste omzet en SEO-schade. En dat is het scenario waarin er nog iets te herstellen valt. Is de laatste bruikbare back-up drie maanden oud, dan bouw je een deel van je site opnieuw.
De rekensom is simpel: een uur per maand is de goedkoopste verzekering die je hebt.
De Cyberbeveiligingswet maakt de restoretest een eis
Op 15 augustus 2026 treedt de Cyberbeveiligingswet in werking, de Nederlandse uitwerking van de Europese NIS2-richtlijn. Er is geen overgangsperiode.
Artikel 21 van de richtlijn noemt back-upbeheer en herstel expliciet, en dan gaat het niet over het maken van back-ups maar over een geteste herstelprocedure. Val je er niet direct onder, dan raakt het je waarschijnlijk alsnog via je opdrachtgevers: die moeten hun toeleveringsketen op orde hebben en gaan hun leveranciers om bewijs vragen.
“We hebben dagelijkse back-ups” is dan geen antwoord meer. “We zetten ze maandelijks terug op een testserver en dit is het logboek” wel. Dat is meteen de reden dat die drie regels uit stap zes de moeite waard zijn.
Zo doen wij het bij PC Patrol
PC Patrol bestaat sinds 2010 en heeft ruim 855 domeinen in beheer. Wat we bij nieuwe klanten het vaakst tegenkomen is niet een ontbrekende back-up, maar een back-up waar niemand ooit iets mee gedaan heeft. In een aantal gevallen bleek de back-upplugin al meer dan een jaar stil te vallen, zonder één melding, terwijl het dashboard netjes groen bleef.
Daarom draaien wij het om. Bij onze onderhoudspakketten maken we dagelijks een offsite back-up in een EU-datacenter met dertig dagen bewaartijd, en die back-up zetten we elke maand daadwerkelijk terug op een testserver. Niet steekproefsgewijs, standaard. Werkt hij niet, dan zoeken we uit waarom voordat het uitmaakt. Risicovolle updates draaien we eerst op staging (op de pakketten Uitgebreid en Premium), en gaat er toch iets mis, dan pakken we dat op werkdagen binnen vier uur op, op Premium binnen een uur. Bereikbaar op werkdagen van 9 tot 17 uur via telefoon, WhatsApp of mail, en altijd door iemand die jouw site kent.
Wordt je site alsnog geraakt, dan volgen we ons vaste noodprotocol voor het eerste uur. Dat protocol werkt alleen als het vangnet eronder klopt, en daar zit precies het verschil tussen een back-up en een geteste back-up.
Waar begin je?
Doe vandaag één ding: zoek op waar je nieuwste back-up staat en controleer of er een databasebestand bij zit. Duurt dat langer dan tien minuten, of vind je hem helemaal niet, dan is dat je antwoord.
Wil je er niet elke maand zelf aan denken, dan is WordPress-onderhoud uitbesteden de kortste route. Wij testen, jij leest het terug in het maandrapport.
Veelgestelde vragen over het testen van je back-up
Zet de nieuwste back-up terug op een staging-omgeving, dus een kopie van je site, en nooit over je live site heen. Log daarna in als beheerder en test de functionaliteit: contactformulier versturen, een testbestelling afronden en controleren of je bericht van vorige week erin staat. Reken op ongeveer een uur.
Maandelijks als je site geld verdient, elk kwartaal als hij vooral een visitekaartje is. Test daarnaast altijd na een grote wijziging, zoals een nieuw thema, een verhuizing naar andere hosting of een aanpassing aan je back-upinstellingen.
De vijf oorzaken die we het vaakst zien: de back-up bevat alleen bestanden en geen database, hij loopt halverwege in een time-out, hij staat op dezelfde server als de site, de bewaartermijn is korter dan de tijd waarin je het probleem ontdekt, of niemand weet hoe je hem terugzet. Geen daarvan geeft een foutmelding waar je iets van merkt.
Artikel 21 van de NIS2-richtlijn noemt back-upbeheer en herstel expliciet, en gaat daarbij uit van een geteste herstelprocedure. De Cyberbeveiligingswet geldt vanaf 15 augustus 2026 zonder overgangsperiode. Val je er niet direct onder, dan kunnen opdrachtgevers er via hun ketenverplichting alsnog om vragen.
Ja, en dat is ook de bedoeling. Je zet de back-up terug op een staging-omgeving, een aparte kopie die los staat van je live site. Bezoekers merken er niets van. Terugzetten over je live site heen is precies hoe een test alsnog een incident wordt.
WordPress-onderhoud
Wij testen elke maand of je back-up echt terugkomt
Dagelijkse offsite back-ups met dertig dagen bewaartijd, elke maand teruggezet op een testserver, en updates die eerst op staging draaien. Vanaf 79 euro per maand, maandelijks opzegbaar, en we verhuizen je site gratis mee.