Websiteback-up en herstel: wat moet je met je webbouwer afspreken?

Een bruikbare websiteback-up bevat de gegevens die je nodig hebt om opnieuw te werken, blijft bereikbaar bij een storing en heeft een geteste herstelprocedure. Vraag je webbouwer daarom om drie concrete afspraken: wat wordt bewaard, hoeveel recente gegevens mag je verliezen en wie zet wat terug?

Deze gids helpt Belgische ondernemers met een bedrijfswebsite of webshop die afspraken te controleren. De technische afwegingen gelden ook voor Nederlandse bedrijven. Je hoeft zelf geen database terug te zetten: je moet wel kunnen beoordelen of “back-ups inbegrepen” voldoende duidelijk is voor jouw zaak.

#Breng eerst in kaart wat je moet kunnen herstellen

Begin met een lijst van wat je site laat werken: pagina’s, afbeeldingen, instellingen, formulieren en eventueel producten, klanten en orders. Vraag per onderdeel waar het staat en welke partij er een herstelbare kopie van bewaart.

Bij een typische WordPress-site zijn bestanden én database nodig voor volledig herstel. Alleen de websitebestanden downloaden bewaart de afzonderlijke database niet. Dat onderscheid staat in de officiële WordPress-uitleg over back-ups (opent in een nieuw venster).

Bij een website op maat vraag je dezelfde inventaris aan je bouwer, met aandacht voor de broncode, het beheersysteem, uploads en database. Werkt je shop met externe voorraadsoftware of een aparte formulierdienst? Laat die gegevensstroom afzonderlijk beschrijven. Neem niet aan dat een kopie van de website ook alle gekoppelde systemen omvat.

Een export kan nuttig zijn, maar laat tonen hoe je ermee herstelt. Een bestand met productnamen is nog geen bewijs dat afbeeldingen, varianten en instellingen mee terugkomen.

#Kies twee grenzen: gegevensverlies en uitvaltijd

“Elke nacht een back-up” zegt wanneer er een kopie wordt gemaakt. Het zegt nog niet hoe snel je opnieuw kunt verkopen, of hoeveel werk er tussen die kopie en de storing verloren kan gaan.

Bespreek twee grenzen met je leverancier:

• Aanvaardbaar gegevensverlies: hoeveel tijd aan wijzigingen, aanvragen of orders kun je reconstrueren? Dit heet de Recovery Point Objective, of RPO.
• Gewenste hersteltijd: binnen welke tijd wil je weer op een afgesproken niveau kunnen werken? Dit heet de Recovery Time Objective, of RTO.

Het Nederlandse NCSC legt deze begrippen uit in zijn stappenplan voor herstel na een cyberincident (opent in een nieuw venster). Hier gebruiken we ze als planningshulp, niet als een algemene wettelijke norm voor Belgische bedrijven.

Voor een informatieve website die maandelijks verandert, kan een dagelijkse kopie passend zijn. Voor een webshop met doorlopende bestellingen kan dat te veel reconstructiewerk opleveren. Vraag in dat geval welke frequentere gegevensbescherming mogelijk is, wat die omvat en wat ze kost. Een kortere interval helpt alleen als de kopieën ook lukken en herstelbaar zijn.

Maak het hersteldoel meetbaar: “klanten kunnen opnieuw bestellen, de orders zijn gecontroleerd en de voorraad klopt”. Alleen “de homepage is weer zichtbaar” is voor een webshop onvoldoende.

#Fictief voorbeeld: de back-up klopt, maar twaalf orders ontbreken

Stel: een winkel in Limburg heeft een webshop met een volledige nachtelijke back-up om 03.00 uur. Om 15.00 uur loopt een productimport fout. In die twaalf uur zijn twaalf betaalde orders binnengekomen, samen voor € 840. Dit is een fictief voorbeeld, geen klantresultaat.

Als de leverancier de volledige database terugzet naar 03.00 uur, staan die twaalf orders niet in die oudere kopie. Ga er niet van uit dat hiermee ook de betaling wordt teruggedraaid. Bij Mollie bijvoorbeeld is een refund een afzonderlijke actie via de API of beheeromgeving (opent in een nieuw venster). De winkel moet de orderinformatie dus beschermen en de verschillen onderzoeken voordat hij verder verwerkt.

De € 840 is hier het orderbedrag dat gecontroleerd moet worden, geen berekend omzetverlies. Misschien zijn alle gegevens nog terug te vinden; misschien ontbreekt een deel. Ook verzendstatussen en voorraadmutaties vragen controle.

Spreek daarom vooraf af:

1. Wie bewaart, waar technisch mogelijk, de huidige toestand vóór herstel?
2. Kan alleen de foutieve productimport worden hersteld, met behoud van latere orders?
3. Welke order- en betalingsreferenties gebruiken we om verschillen te zoeken?
4. Hoe voorkomen we dubbele bevestigingen, voorraadmutaties of verzendingen wanneer gegevens opnieuw worden verwerkt?

Selectief herstel is een mogelijkheid om te onderzoeken, geen functie die ieder platform standaard biedt. De gegevens moeten samenhangend blijven. Voor het vergelijken van voorraad vind je aanvullende beslisregels in voorraad synchroniseren tussen webshop en winkel.

#Bewaar kopieën buiten dezelfde kwetsbare omgeving

Een kopie die alleen op de productieserver staat, kan met die server verloren gaan. De 3-2-1-uitleg van het NCSC (opent in een nieuw venster) adviseert drie exemplaren van belangrijke gegevens, inclusief het origineel, op twee soorten media, met één kopie op een andere locatie.

Vraag je leverancier hoe dat principe voor jouw hosting wordt ingevuld. “In de cloud” is te vaag om de scheiding te beoordelen. Kan een probleem met het productieaccount ook de back-ups raken? Wie heeft toegang tot de aparte opslag, en kun je herstellen als de gewone beheeromgeving onbereikbaar is?

Leg ook vast hoelang oudere kopieën blijven bestaan. Een fout kan pas dagen later worden ontdekt. WordPress beschrijft in zijn beveiligingsdocumentatie (opent in een nieuw venster) waarom eerdere herstelpunten bij een later ontdekte aanval nuttig kunnen zijn en waarom de integriteit van back-ups telt. De nieuwste kopie is dus niet vanzelf de juiste.

Kopieën kunnen klantgegevens bevatten. Laat toegang beperken en de opslag beschermen; zet herstelbestanden niet op een publiek bereikbare plek. Neem in de afspraken op wie ongebruikte testkopieën verwijdert en hoe de bewaartermijn wordt toegepast.

#Laat een afgeschermde hersteltest uitvoeren

Vraag om een hersteltest voordat je op de back-up vertrouwt, en spreek af wanneer die wordt herhaald. Doe dat ook na een belangrijke wijziging in hosting, platform of gegevensopslag.

Het NCSC onderscheidt een technische controle van een functionele hersteltest (opent in een nieuw venster): na het terugzetten controleer je of je bedrijfsprocessen weer kunnen werken. Vertaal dat voor je website naar een kleine, herhaalbare proef.

Laat je leverancier daarvoor:

1. Een herstelpunt kiezen en de datum, inhoud en beschikbare toegang vastleggen.
2. Een afgeschermde testomgeving voorbereiden die echte betalingen, klantmails, verzendingen en wijzigingen in gekoppelde productiesystemen blokkeert. Een wachtwoord op de testsite alleen blokkeert die uitgaande acties niet.
3. De benodigde onderdelen terugzetten en controleren of software, bestanden en gegevens bij elkaar passen.
4. Bedrijfsfuncties nalopen: enkele pagina’s en afbeeldingen openen, aanmelden in het beheer en bij een webshop bestaande orders, varianten en prijzen vergelijken. Formulier- of betaalproeven gebeuren uitsluitend met afgesproken testinstellingen.
5. De uitkomst noteren: wat werkte, wat ontbrak, hoe lang het duurde en welke handelingen nog nodig zijn voor echt herstel.

Gebruik voor de technische instructies de documentatie van jouw platform en hosting. Laat bij twijfel de leverancier uitvoeren; een herstelknop op productie is geen veilige oefenplek.

#Een storing: bepaal eerst wat je wilt terugzetten

Bij een verwijderde pagina is de herstelkeuze anders dan bij een vermoedelijke aanval. Laat de verantwoordelijke eerst de oorzaak en omvang beoordelen. Vraag welke gegevens sinds het gekozen herstelpunt zijn veranderd voordat iemand een volledige terugzetactie start.

Bij een veiligheidsincident moet ook worden beoordeeld of het herstelpunt schoon is en de oorzaak is aangepakt. Anders kan dezelfde storing terugkomen. Bewaar relevante informatie over het incident en laat de technische verantwoordelijke bepalen wat veilig opnieuw online kan.

Zorg dat je een contactlijst en herstelafspraken buiten de website zelf hebt. Noteer wie toestemming geeft, wie uitvoert, wie de inhoud of orders controleert en via welk kanaal je elkaar bereikt als de normale omgeving uitvalt. Bewaar wachtwoorden en geheime sleutels in de afgesproken beveiligde voorziening, niet in een gedeelde checklist.

#Neem deze afspraken mee naar je onderhoudsgesprek

Vraag om schriftelijke antwoorden op acht punten:

• Welke bestanden, databases en externe gegevens vallen binnen de back-up?
• Wat zijn de frequentie, bewaartermijn en melding bij een mislukte kopie?
• Waar staat de aparte kopie, en hoe blijft die bereikbaar bij uitval?
• Wie kan herstellen, ook wanneer je vaste contactpersoon afwezig is?
• Welke grenzen voor gegevensverlies en hersteltijd spreken we af?
• Wanneer was de laatste hersteltest, en welke functies zijn toen gecontroleerd?
• Hoe beschermen we recente orders en gekoppelde systemen bij herstel?
• Welke hulp is inbegrepen, en welk herstelwerk kan extra kosten?

Brisk beschrijft op de huidige pagina over onderhoud en hosting nachtelijke back-ups van database en bestanden, een aparte kopie en herstel eerst op een testomgeving. De bewaartermijn wordt samen afgesproken. Vraag voor jouw project ook naar de gewenste hersteltijd en de bescherming van recente webshoporders; een demonstratie op een servicepagina is geen bewijs dat jouw eigen site al getest is.

#Bronnen en onderzoeksmethode

Bronnen gecontroleerd op 6 oktober 2026: de hierboven gelinkte WordPress-documentatie, de NCSC-pagina’s over hersteldoelen, de 3-2-1-regel en hersteltesten, de Mollie-documentatie over refunds en Brisks actuele onderhoudspagina (opent in een nieuw venster). De NCSC-bronnen dienen als technisch advies; dit artikel maakt geen vergelijking van Belgische en Nederlandse wettelijke verplichtingen.

Dit artikel is met AI-assistentie onderzocht en geschreven. De checklist en het winkelvoorbeeld zijn een praktische uitwerking van die bronnen. Er is voor dit artikel geen klantomgeving teruggezet of platformherstel persoonlijk getest.