Website back-up strategie: waarom een back-up zonder geteste restore geen back-up is

Belangrijkste conclusies

• Een back-up-bestand is geen garantie. Pas wanneer je hem succesvol hebt teruggezet, weet je of hij werkt.
• De juiste frequentie hangt af van hoe vaak je site verandert, niet van een vast standaardschema.
• Een back-up die op dezelfde server staat als je website, is geen back-up, het is een kopie die met de site meegaat als er iets misgaat.

Waarom "we maken back-ups" niet genoeg zegt

Bijna elke hostingpartij en elk beheerd CMS claimt back-ups te maken. Dat klinkt geruststellend, tot het moment dat je die back-up daadwerkelijk nodig hebt en blijkt dat het bestand corrupt is, te oud is, of alleen de database bevat en niet de mediabestanden. Een back-up-strategie is pas een strategie wanneer je weet wát er precies wordt bewaard, wáár, hoe vaak, en of het proces om alles terug te zetten ook echt werkt.

Dat laatste punt wordt structureel onderschat. Veel bedrijven ontdekken pas tijdens een crisis, een hack, een mislukte update, een menselijke fout, dat hun back-up niet bruikbaar is. Op dat moment is het te laat om het probleem nog rustig op te lossen.

Hoe vaak moet je back-uppen?

Er bestaat geen universeel juist antwoord, de frequentie hangt af van hoe vaak je site verandert.

• Dagelijks: voor websites met regelmatige content-updates, webshops met bestellingen, of sites met formulieren die klantgegevens verzamelen. Hier kan één dag dataverlies al voelbare schade betekenen.
• Wekelijks: voor informatieve bedrijfswebsites die weinig muteren, bijvoorbeeld een paar keer per maand een blogpost of kleine aanpassing.
• Vóór elke grote wijziging: los van je vaste ritme, maak je altijd een extra back-up vlak voordat je een grote update uitvoert, een thema wijzigt of een nieuwe plugin installeert. Zo kan je in seconden terug naar de vorige, werkende staat.

Voor een webshop of een site met dagelijkse transacties is een back-up van een week oud in de praktijk waardeloos: je verliest dagen aan bestellingen, klantgegevens of content. Reken dus niet in "hoe vaak is gebruikelijk", maar in "hoeveel data kan ik me veroorloven te verliezen".

Waar je back-ups bewaart: niet op dezelfde plek

Een van de meest gemaakte fouten is een back-up bewaren op dezelfde server als de website zelf. Bij een hack, een serverstoring of een falende harde schijf verdwijnt dan niet alleen je site, maar ook je vangnet.

Een degelijke opzet volgt in grote lijnen de 3-2-1-regel:

• 3 kopieën van je data: de live website plus minstens twee back-ups.
• 2 verschillende opslagmedia, bijvoorbeeld de hostingserver en een externe cloudopslag.
• 1 kopie extern, fysiek of netwerkmatig gescheiden van je productieomgeving.

In de praktijk betekent dit meestal: een automatische back-up die naar een externe cloudopslag wordt weggeschreven, los van de hostingpartij waar je site draait. Zo blijft er altijd een werkend exemplaar over, ongeacht wat er met de server zelf gebeurt.

De stap die bijna iedereen overslaat: de restore testen

Dit is het kernprobleem van veel back-up-opzetten: er wordt wel gemaakt, maar nooit teruggezet. En een back-up die je nooit hebt teruggezet, is in feite een onbevestigde hypothese, geen garantie.

Zet daarom periodiek, bijvoorbeeld één keer per kwartaal, een back-up terug in een aparte testomgeving. Controleer of:

1. de volledige site correct laadt, inclusief afbeeldingen en media;
2. de database intact is en actuele gegevens bevat;
3. formulieren, plugins en integraties nog functioneren zoals verwacht;
4. het herstelproces binnen een redelijke tijd afgerond is, zodat je weet hoe lang je offline zou staan bij een echte crisis.

Pas als deze test slaagt, weet je zeker dat je back-up-strategie werkt wanneer het er echt op aankomt.

Back-ups zijn onderdeel van een breder geheel

Back-ups staan niet op zichzelf. Ze zijn één onderdeel van structureel websitebeheer, naast updates, performance-checks en uptime-monitoring. Wil je begrijpen hoe back-ups passen binnen de bredere aanpak van onderhoud, lees dan ons artikel over WordPress onderhoud, waarin we alle pijlers van een gezonde, goed onderhouden website bespreken.

Een goede back-up-strategie hoort daarnaast al vanaf de start ingebouwd te zijn bij de bouw of migratie van een website, niet als losse toevoeging achteraf. Dat is precies hoe we bij Waligoo te werk gaan binnen ons bredere aanbod aan WordPress development: een technische fundering waarbij back-ups, beveiliging en snelheid vanaf dag één meegenomen worden.

Conclusie

Een back-up is pas waardevol wanneer hij aan drie voorwaarden voldoet: hij wordt op het juiste ritme gemaakt, hij staat ergens anders dan je live server, en je weet zeker dat hij werkt omdat je hem hebt getest. Zonder die derde stap heb je in werkelijkheid geen vangnet, maar een aanname.

Wil je zeker weten dat jouw website goed beveiligd is tegen dataverlies, of twijfel je of je huidige developer of hostingpartij dit wel goed heeft ingericht? Dat is trouwens ook precies een van de vragen die je vooraf zou moeten stellen wanneer je een webdeveloper kiest.