Hoe vaak moet je een back-up maken van je WordPress-site?

"We hebben back-ups" is een van de meest misleidende zinnen in websitebeheer. Er bestáát een back-up, ergens, van een moment in het verleden — maar is die recent genoeg, staat hij op een veilige plek, en werkt hij daadwerkelijk als je hem nodig hebt? Dat zijn drie andere vragen, en het antwoord is verrassend vaak nee. In dit artikel bespreken we hoe je de juiste back-upfrequentie voor jouw site bepaalt, waar je back-ups het beste bewaart, en waarom een back-up die je nog nooit hebt teruggezet eigenlijk geen gegarandeerde back-up is.

Waarom back-ups net zo belangrijk zijn als updates

Updates verkleinen de kans dat er iets misgaat. Back-ups bepalen wat er gebeurt als het toch misgaat — en dat gebeurt uiteindelijk bij vrijwel elke website: een mislukte plugin-update, een hack, een menselijke fout, of gewoon een serverstoring bij de hostingpartij. Zonder een recente, werkende back-up is elk van die scenario's een potentiële ramp. Mét een goede back-up is hetzelfde scenario een kwestie van uren, of zelfs minuten, herstel.

Een update voorkomt het probleem, een back-up bepaalt hoeveel je verliest als het toch misgaat.

De juiste frequentie: het hangt af van hoe vaak je content verandert

Er bestaat geen universeel juiste back-upfrequentie. De kernvraag is simpel: hoeveel werk zou je kwijtraken als je moest terugvallen op de laatste back-up? Hoe vaker je content wezenlijk verandert, hoe frequenter je moet back-uppen.

Webshops en sites met dagelijkse activiteit

Een WooCommerce-shop verwerkt voortdurend nieuwe bestellingen, klantgegevens en voorraadmutaties. Verlies je hier een dag aan data, dan verlies je niet alleen content maar ook echte bestellingen en omzetgegevens. Voor dit type site is een dagelijkse back-up eigenlijk het absolute minimum — en voor grotere shops is vaker, bijvoorbeeld meerdere keren per dag, geen overdreven voorzichtigheid maar gewoon proportioneel aan wat er op het spel staat.

Sites met regelmatige content, zoals een blog

Wordt er een paar keer per week een artikel gepubliceerd of aangepast, dan is een dagelijkse tot wekelijkse back-up meestal voldoende. Het verlies van een enkele dag content is vervelend, maar zelden bedrijfskritiek.

Statische brochuresites

Een site die maanden ongewijzigd blijft, heeft geen dagelijkse back-up nodig. Een wekelijkse back-up, aangevuld met een handmatige back-up direct vóór elke wijziging die je zelf doorvoert, is hier ruim voldoende.

Waar je back-ups het beste bewaart

Een back-up die alleen op dezelfde server staat als de website zelf, is eigenlijk maar een half antwoord op het probleem. Gaat de hele server down, wordt de server gehackt, of gaat er iets mis bij de hostingpartij, dan verdwijnt de back-up mogelijk samen met de site die hij had moeten redden. De vuistregel hier is simpel:

• Bewaar back-ups op een externe locatie, los van de server waar de website zelf op draait — bijvoorbeeld cloudopslag bij een andere partij.
• Zorg voor meerdere kopieën, zodat je niet afhankelijk bent van precies één opslaglocatie.
• Automatiseer het proces, zodat een back-up niet per ongeluk wordt overgeslagen omdat iemand het vergat.

Hoeveel historie je moet bewaren

Naast frequentie is ook de bewaartermijn van belang. Een probleem wordt namelijk niet altijd meteen ontdekt — soms merk je pas na een paar dagen of zelfs weken dat er iets mis is gegaan, bijvoorbeeld met content die stilletjes is gecorrumpeerd. Bewaar je alleen de laatste back-up van gisteren, dan kan die net zo goed al het probleem bevatten. Een goede opzet bewaart daarom meerdere back-ups terug in de tijd — bijvoorbeeld de laatste dagen dagelijks, de laatste weken wekelijks, en een aantal maanden terug maandelijks — zodat je altijd een punt kunt terugvinden van vóórdat het probleem ontstond.

Hoe je een back-up daadwerkelijk test

Dit is de stap die het vaakst wordt overgeslagen, en tegelijk de belangrijkste. Een back-up die je nog nooit hebt teruggezet, is geen gegarandeerde back-up — het is een aanname. Bestanden kunnen corrupt zijn, een back-up kan onvolledig zijn gestopt, of het herstelproces zelf kan haperen op het moment dat het er echt toe doet.

1. Zet regelmatig een back-up terug in een aparte testomgeving, los van de live site, om te controleren of het herstel daadwerkelijk werkt.
2. Controleer of alle onderdelen aanwezig zijn — database, mediabestanden, plugins en instellingen — en niet alleen een deel van de site.
3. Meet hoelang een herstel duurt, zodat je weet wat je kunt verwachten als het echt nodig is, in plaats van dat pas te ontdekken tijdens een crisis.
4. Documenteer het herstelproces, zodat het ook uitvoerbaar is als degene die het normaal doet, net niet beschikbaar is.

Wat een goed back-upbeleid in de praktijk betekent

Samengevat komt een goed back-upbeleid neer op vier elementen: een frequentie die past bij hoe vaak je content verandert, opslag op een externe locatie los van de server zelf, voldoende historie om ook een laat ontdekt probleem te kunnen herstellen, en periodiek daadwerkelijk testen of het herstel werkt. Ontbreekt een van deze vier, dan is de kans groot dat de back-up er wél is op het moment dat je hem nodig hebt, maar niet doet wat je ervan verwacht.

Kort samengevat

Hoe vaak je moet back-uppen, hangt af van hoeveel je zou verliezen tussen twee back-ups in — voor een webshop is dat dagelijks, voor een statische site kan wekelijks volstaan. Minstens zo belangrijk is waar je die back-ups bewaart en of je ze daadwerkelijk hebt getest. Een back-up die alleen op de server zelf staat en nog nooit is teruggezet, geeft schijnzekerheid — en die ontdek je meestal pas op het slechtst mogelijke moment.