Website-backups: hoe vaak, waar en hoe je een herstel test

Een website-backup is pas iets waard als je de restore hebt getest.

Het korte antwoord op “hoe vaak, waar en hoe test ik”: back-up zo vaak dat je nooit meer werk verliest dan je kunt missen. Bewaar minstens één kopie buiten je eigen server.

Het verdict: een website backup maken is het makkelijke deel. Een paar keer per jaar een volledige back-up terugzetten in een testomgeving is wat je echt beschermt.

De meeste bedrijven regelen het eerste deel wel en vergeten het laatste. Precies daar gaat het mis, op het slechtste moment.

Back-ups horen bij het bredere onderhoudsverhaal uit onze B2B-website gids.

Wat hoort er in een goede website-backup?

Een volledige back-up bevat alles om je site identiek opnieuw op te bouwen, niet alleen de zichtbare pagina’s.

De vier lagen van een volledige back-up

In de praktijk gaat het om vier lagen:

• Bestanden: templates, afbeeldingen, scripts
• Database: je content en instellingen
• Configuratie: server en omgeving
• Losse data: bijvoorbeeld formulierinzendingen

Mist er één laag? Dan krijg je je site niet identiek terug.

Waarom een halve back-up je niet redt

Het probleem ontstaat als je maar een deel bewaart. Een back-up van alleen de database mist je afbeeldingen en thema.

Een kopie van alleen de bestanden mist je pagina’s en blogartikelen.

WordPress zegt het in zijn eigen documentatie letterlijk: je hebt beide nodig “to be able to fully restore a typical WordPress site” (WordPress-documentatie over back-ups).

Bij een echte calamiteit heb je dus beide nodig om snel weer in de lucht te zijn. Denk aan:

• een gehackte site
• een mislukte update
• een server die crasht

Controleer daarom: omvat je back-up alle lagen, of slaat hij stilletjes iets over?

Wat je doet als het al misging, lees je in onze gids over een gehackte WordPress-site.

Data die buiten de standaard back-up valt

Let ook op data die buiten de gewone back-up valt.

Formulierinzendingen worden op sommige platformen apart opgeslagen. Dan vallen ze niet onder een gewone site-restore.

Zijn die leads bedrijfskritisch, dan regel je daar een aparte export voor.

Een sterke contactpagina die leads binnenhaalt is weinig waard als die leads bij een herstel verdwijnen.

Hoe vaak moet je een website-backup maken?

Zo vaak als nodig om nooit meer te verliezen dan je je kunt veroorloven.

Begin bij je hersteldoel

De vakterm hiervoor is je hersteldoel: hoeveel uur of dagen aan wijzigingen mag je in het ergste geval kwijtraken?

Dat antwoord bepaalt je frequentie. Niet andersom.

Voorbeeld: stel dat je drie blogartikels per week publiceert en elke zondag een back-up maakt. Crasht je site op zaterdag, dan ben je bijna een week werk kwijt.

Te veel? Schuif dan naar een dagelijkse back-up.

Frequentie per type website

Voor een statische bedrijfssite die zelden verandert, kan een wekelijkse back-up volstaan. Er gaat tussen twee momenten weinig nieuw werk verloren.

Publiceer je dagelijks content of draait er een webshopachtige flow met bestellingen? Dan wil je dagelijks of zelfs continu back-uppen.

De WordPress-documentatie hanteert dezelfde lijn: wekelijks voor kleinere sites, dagelijks voor sites met veel activiteit.

Verkoop je via je site geen producten, maar genereer je leads? Dan zit de waarde vooral in je content en je inzendingen.

Stem je ritme daarop af.

Altijd een back-up vlak voor een risicovolle ingreep

Vuistregel: maak altijd een verse back-up vlak voor een risicovolle ingreep.

Dit zijn de momenten waarop sites het vaakst breken:

• een plugin- of platform-update
• een website-redesign
• een website-migratie

Een handmatige back-up direct ervoor kost je een paar minuten. In het slechtste geval bespaart hij je dagen herstelwerk.

Let op: vertrouw niet blind op de standaardfrequentie die je host of platform toevallig heeft ingesteld. Die is gekozen voor het gemiddelde, niet voor jouw situatie.

Waar bewaar je je back-ups het best?

Niet op dezelfde plek als je live site. Nooit.

De 3-2-1-regel

De meest gebruikte richtlijn is de 3-2-1-regel. Het Amerikaanse cyberagentschap CISA noemt hem “a trusted guideline” (CISA over back-ups voor bedrijven).

Zo ziet de regel eruit:

Bewaar dus drie kopieën van je data, op twee verschillende soorten opslag, met minstens één kopie op een andere locatie.

Die regel bestaat al lang. Hij werkt. Hij beschermt je tegen het uitvallen van een enkele schijf, een enkele dienst of een enkele locatie tegelijk.

Zo vertaal je de regel naar je website

Concreet betekent dat het volgende:

1. Kopie één is je live site.
2. Kopie twee is een automatische back-up bij je host of platform.
3. Kopie drie staat buiten dat systeem, in losse cloudopslag of bij een beheerde back-updienst.

Kopie twee staat vaak in dezelfde omgeving als je site. Als die omgeving zelf het probleem is, ben je alsnog kwetsbaar.

Denk aan een gehackt account, een failliete provider of een verwijderd project.

Daarom bewaar je kopie drie los van je webhosting.

WordPress raadt bovendien aan om minstens 3 tot 5 recente back-ups bij te houden, op verschillende locaties.

Isolatie is de kern

De kern van de regel is isolatie.

Een back-up die op dezelfde server staat als je site is geen echte verzekering.

Een probleem dat je site raakt, raakt vaak ook die back-up.

Zorg dus dat minstens één kopie technisch en organisatorisch gescheiden is van je productieomgeving.

CISA raadt daarbij ook encryptie, fysieke beveiliging en offline kopieën aan.

Wie bij welke kopie kan, hoort bij je bredere websitebeveiliging.

Back-ups en de GDPR

Houd ook rekening met de GDPR. Persoonsgegevens in back-ups moeten beveiligd zijn.

Ze mogen ook niet eindeloos en ongecontroleerd ergens blijven staan, dus leg een bewaartermijn vast.

Artikel 32 vraagt bovendien “the ability to restore the availability and access to personal data in a timely manner” na een incident (artikel 32 GDPR).

Waar die kopieën fysiek staan, lees je in onze uitleg over EU-hosting en data residency.

Hoe verschilt back-uppen per platform?

Het hangt af van je platform hoeveel je zelf moet regelen, en geen enkele aanpak is automatisch veilig.

Omdat we websites bouwen in Webflow, WordPress en custom of headless, zien we de verschillen van dichtbij.

Webflow: gemak, met een paar details

Op een gehost platform als Webflow houdt het systeem doorgaans automatisch versies en back-ups bij. Met een paar klikken zet je terug naar een eerder punt.

Webflow is een gehost platform: je bouwt en host op dezelfde plek.

De homepage van Webflow, oktober 2026.

Het gemak is groot, maar let op de details:

• een restore vervangt vaak de hele site naar dat moment
• losse data zoals formulierinzendingen kan apart staan
• die data valt dan buiten zo’n herstel

Hoe de hosting daar precies werkt, lees je in Webflow-hosting uitgelegd.

WordPress: je bent zelf verantwoordelijk

Bij WordPress ben je zelf verantwoordelijk. Sommige hosts maken automatische back-ups, maar dekking, frequentie en bewaartermijn verschillen sterk.

Veel teams vullen dat aan met een back-upplugin of een externe dienst.

WordPress.org, oktober 2026. Bestanden en database back-up je hier apart.

De volgorde volgens de WordPress-documentatie: eerst de database, dan de bestanden, als één set rond hetzelfde moment.

Bij een herstel zet je eerst de bestanden terug en importeer je daarna de database.

Je volledige beveiligingsroutine staat in onze WordPress-beveiligingschecklist.

Custom of headless: back-up als infrastructuur

Bij een custom of headless opzet zit je data verspreid over een database, een CMS en bestandsopslag.

Dan moet je back-up en herstel als onderdeel van je infrastructuur inrichten.

De drie platformen naast elkaar

De les: ga nooit uit van “het zal wel goed zitten”. Zoek concreet uit wat er automatisch gebeurt, wat ontbreekt en wie verantwoordelijk is.

Het juiste platform hangt af van je team, je content en je groeiplannen. De noodzaak van een geteste back-upstrategie geldt overal.

Of je zelf host of laat beheren, vergelijk je in managed hosting vs zelf hosten.

Waarom is een back-up zonder geteste restore waardeloos?

Omdat een back-up die je nooit hebt teruggezet alleen een aanname is, geen zekerheid.

Groene vinkjes zijn geen bewijs

Dit stuk slaat bijna iedereen over. Je ziet groene vinkjes in je back-uptool en je gaat ervan uit dat het goed zit.

Pas als je echt moet herstellen, ontdek je dat het bestand corrupt is, een laag mist of het proces niet werkt zoals gedacht.

Waarom een herstel faalt

De redenen zijn vervelend banaal:

• een back-up die maandenlang stilletjes onvolledig draaide
• een database-export die niet samenpast met de bestanden
• een procedure die niemand ooit uitvoerde en meer stappen blijkt te hebben

Op het moment dat je site plat ligt, valt ook je omzet stil. Je leadgeneratie stopt en de telefoon gaat.

Slechter kan je het niet ontdekken.

Plat liggen merk je sneller met uptime-monitoring, maar herstellen moet je zelf kunnen.

De waarde zit in het terugzetten

De waarde van een back-up zit niet in het maken, maar in het bewezen kunnen terugzetten.

Een geteste restore verandert je back-up van een hoopvolle aanname in een echte verzekering.

We vertellen je liever vooraf dat je herstel nooit getest is dan dat je daar tijdens een crisis achterkomt.

Hoe test je een herstel in de praktijk?

Door een volledige back-up periodiek terug te zetten in een aparte omgeving en te controleren of de site echt werkt.

Je test dus niet op je live site, maar op een staging- of testomgeving. Zo maak je niets in productie kapot.

CISA formuleert het doel zo: test of je team data “both fully and partially” snel kan terugzetten.

Een werkbare aanpak in vier stappen:

Stap 1: Kies een recente back-up

Zet een recente back-up volledig terug op een geïsoleerde test- of stagingomgeving, los van je live site.

Kies bewust ook eens een oudere back-up. CISA raadt aan dat je data minstens zeven dagen kunt terugdraaien.

Zo ziet een back-upoverzicht er bij een gehost platform uit:

Stap 2: Controleer of alles er is

Loop deze punten na:

• laden de pagina’s en kloppen de afbeeldingen?
• staat de content er volledig?
• werken de formulieren?
• is de configuratie correct?

Test ook een gedeeltelijk herstel, bijvoorbeeld één verwijderde pagina terugzetten.

Stap 3: Meet de hersteltijd

Noteer hoelang het volledige proces duurt. Dat is je realistische downtime in een echte calamiteit.

Voorbeeld: duurt het herstel in staging drie uur, dan ligt je site in een echte crisis ook minstens drie uur plat.

Stap 4: Leg de stappen vast in een draaiboek

Schrijf de stappen op in een kort draaiboek. Zo volg je in een crisis een bekende procedure en hoef je niet onder druk te improviseren.

Een goed draaiboek bevat:

• waar elke kopie staat en wie toegang heeft
• de herstelvolgorde per laag
• de gemeten hersteltijd en de datum van de laatste test

Leg in je onderhoudscontract vast wie die test uitvoert.

Hoe vaak test je?

Doe dit minstens een paar keer per jaar, en zeker na elke grote wijziging aan je site of hosting.

De GDPR vraagt in artikel 32 ook “a process for regularly testing” van je beveiligingsmaatregelen.

Net als bij een brandoefening is het doel niet de oefening zelf. Het doel is de zekerheid dat het werkt als het er echt toe doet.

Een herstel dat je drie keer rustig hebt uitgevoerd, jaagt je geen stress aan als het een keer menens is.

Veelgestelde vragen

Hoe vaak moet ik een website backup maken?

Dat hangt af van hoeveel werk je maximaal wilt verliezen. Een statische site kan met een wekelijkse back-up toe, een site met dagelijkse content of bestellingen heeft dagelijks of continu nodig.

Is de back-up van mijn hostingprovider genoeg?

Meestal niet als enige kopie. Die back-up staat vaak in dezelfde omgeving als je site, dus volgens de 3-2-1-regel bewaar je minstens één kopie daarbuiten.

Hoe vaak moet ik een restore testen?

Minstens een paar keer per jaar, en zeker na elke grote wijziging aan je site of hosting. Test in een aparte omgeving, nooit op je live site.

Zitten formulierinzendingen in mijn back-up?

Niet altijd. Op sommige platformen staan ze apart en vallen ze buiten een gewone site-restore, dus regel een aparte export als die leads bedrijfskritisch zijn.

De korte samenvatting

Een goede back-upstrategie staat of valt met de restore.

Bepaal je frequentie op je hersteldoel, bewaar volgens de 3-2-1-regel één kopie los van je live omgeving, en zet een paar keer per jaar een volledige back-up terug in een testomgeving.

Wil je dat je website en je leadflow ook bij een calamiteit overeind blijven? Via ons website-onderhoud nemen we back-ups en hersteltests mee.

Benieuwd of je huidige opzet echt waterdicht is? Neem contact op en we lopen je back-up- en herstelopzet samen kritisch door.