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 een kopie buiten je eigen server, en herstel een paar keer per jaar een volledige back-up in een testomgeving om te bewijzen dat het werkt. De meeste bedrijven regelen het eerste deel wel en vergeten het laatste, en dat is precies waar het misgaat op het slechtste moment.

In deze gids lopen we door wat een goede back-up bevat, hoe vaak je hem maakt, waar je hem bewaart, hoe dit per platform verschilt en, het belangrijkste, hoe je een herstel test. Het hoort bij het bredere onderhoudsverhaal uit onze B2B-website gids.

Wat hoort er in een goede website-backup?

Een volledige back-up bevat alles wat nodig is om je site identiek opnieuw op te bouwen, niet alleen de zichtbare pagina’s. In de praktijk gaat het om vier lagen: de bestanden (templates, afbeeldingen, scripts), de database met je content en instellingen, de configuratie van server en omgeving, en eventuele losse data zoals formulierinzendingen.

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. Bij een echte calamiteit, denk aan een gehackte site, een mislukte update of een server die crasht, heb je beide nodig om snel weer in de lucht te zijn. Controleer daarom of je back-up alle lagen omvat en niet stilletjes iets overslaat.

Let ook op data die buiten de standaard back-up valt. Formulierinzendingen worden op sommige platformen apart opgeslagen en vallen niet onder een gewone site-restore. Als die leads bedrijfskritisch zijn, 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. 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.

Voor een statische bedrijfssite die zelden verandert, kan een wekelijkse back-up volstaan, omdat er tussen twee momenten weinig nieuw werk verloren gaat. Publiceer je dagelijks content of draait er een webshopachtige flow met bestellingen, dan wil je dagelijks of zelfs continu back-uppen. 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.

Een praktische vuistregel: maak altijd een verse back-up vlak voor een risicovolle ingreep. Een plugin- of platform-update, een redesign of een website-migratie zijn de momenten waarop sites het vaakst breken. Een handmatige back-up direct ervoor kost je een paar minuten en bespaart je in het slechtste geval dagen herstelwerk. Vertrouw daarbij niet blind op de standaardfrequentie die je host of platform toevallig heeft ingesteld, want 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. De meest gebruikte richtlijn is de 3-2-1-regel: bewaar drie kopieën van je data, op twee verschillende soorten opslag, met minstens een kopie op een andere locatie. Die regel bestaat al lang omdat hij werkt: hij beschermt je tegen het uitvallen van een enkele schijf, een enkele dienst of een enkele locatie tegelijk.

Concreet betekent dat het volgende. Je live site is kopie een. Een automatische back-up bij je host of platform is kopie twee, maar die staat vaak in dezelfde omgeving, dus als die omgeving zelf het probleem is (een gehackt account, een failliete provider, een verwijderd project), ben je alsnog kwetsbaar. Daarom bewaar je kopie drie buiten dat systeem, bijvoorbeeld in losse cloudopslag of op een beheerde back-updienst die los staat van je hosting.

De kern van de regel is isolatie. Een back-up die op dezelfde server staat als je site is geen echte verzekering, want een probleem dat je site raakt, raakt vaak ook die back-up. Zorg dus dat minstens een kopie technisch en organisatorisch gescheiden is van je productieomgeving. Houd daarbij ook rekening met de GDPR: persoonsgegevens in back-ups moeten beveiligd zijn en mogen niet eindeloos en ongecontroleerd ergens blijven staan, dus leg een bewaartermijn vast.

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.

Op een gehost platform als Webflow houdt het systeem doorgaans automatisch versies en back-ups bij, en kun je met een paar klikken naar een eerder punt terugzetten. Het gemak is groot, maar let op de details: een restore vervangt vaak de hele site naar dat moment, en losse data zoals formulierinzendingen kan apart staan en buiten zo’n herstel vallen. Bij WordPress ben je zelf verantwoordelijk: sommige hosts maken automatische back-ups, maar de dekking, frequentie en bewaartermijn verschillen sterk, en veel teams vullen dat aan met een back-upplugin of een externe dienst. Bij een custom of headless opzet zit je data verspreid over een database, een CMS en bestandsopslag, en moet je back-up en herstel als onderdeel van je infrastructuur inrichten.

De les is voor elk platform hetzelfde: 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, maar de noodzaak van een geteste back-upstrategie geldt overal.

Waarom is een back-up zonder geteste restore waardeloos?

Omdat een back-up die je nooit hebt teruggezet alleen een aanname is, geen zekerheid. Dit is het stuk dat bijna iedereen overslaat. Je ziet groene vinkjes in je back-uptool, je gaat ervan uit dat het goed zit, en pas op het moment dat je echt moet herstellen ontdek je dat het bestand corrupt is, een laag mist of het proces niet werkt zoals gedacht.

De redenen waarom een herstel faalt zijn vervelend banaal. Een back-up die maandenlang stilletjes onvolledig draaide. Een database-export die niet samenpast met de bestanden. Een herstelprocedure die niemand ooit heeft uitgevoerd en die in de praktijk meer stappen blijkt te hebben. Op het moment dat je site plat ligt, je omzet en je leadgeneratie stilvallen en de telefoon gaat, is dat de slechtst denkbare plek om dat te ontdekken.

Daarom geldt: 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. Dit past in onze bredere lijn van eerlijk advies: we vertellen 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, zodat je niets in productie kapot maakt.

Een werkbare aanpak in vier stappen:

1. Kies een recente back-up en zet hem volledig terug op een geïsoleerde test- of stagingomgeving, los van je live site.
2. Controleer of alles er is: laden de pagina’s, kloppen de afbeeldingen, staat de content er, werken de formulieren en is de configuratie correct?
3. Meet de hersteltijd: noteer hoelang het volledige proces duurt, want dat is je realistische downtime in een echte calamiteit.
4. Leg de stappen vast in een kort draaiboek, zodat je in een crisis een bekende procedure volgt en niet onder druk moet improviseren.

Doe dit minstens een paar keer per jaar, en zeker na elke grote wijziging aan je site of hosting. Net als bij een brandoefening is het doel niet de oefening zelf, maar 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.

De korte samenvatting

Een goede back-upstrategie staat of valt met de restore. Bepaal je frequentie op basis van hoeveel werk je maximaal mag verliezen, back-up extra vlak voor risicovolle ingrepen, en bewaar volgens de 3-2-1-regel minstens een kopie los van je live omgeving. Controleer dat je back-up alle lagen bevat, inclusief data die apart wordt opgeslagen zoals formulierinzendingen. En het belangrijkste: zet een paar keer per jaar een volledige back-up terug in een testomgeving, zodat je weet dat je herstel werkt voordat je het echt nodig hebt.

Wil je dat je website en je leadflow ook bij een calamiteit overeind blijven, en wil je weten of je huidige back-up- en herstelopzet echt waterdicht is? Plan je gratis intake en we kijken er samen kritisch naar.