WordPress-back-up: hoe vaak, waarheen — en hoe je merkt dat het werkt

Bijna elke website heeft een back-upplugin. Veel minder websites hebben een back-up die standhoudt als het erop aankomt. Het verschil ligt niet aan de tool, maar aan drie beslissingen die je één keer neemt en daarna vergeet: hoe vaak, waarheen, en hoe je merkt dat het werkt.

Het enige cijfer dat telt: hoeveel mag je kwijtraken?

Het ritme van een back-up volgt niet je gevoel, maar één vraag: hoeveel werk mag verloren gaan zonder dat het pijn doet? Een blog met één bericht per week verliest bij een dagelijkse back-up niets. Een webshop met veertig bestellingen per dag verliest bij een dagelijkse back-up tot veertig bestellingen.

Bestanden veranderen minder vaak dan de database — afbeeldingen, thema's en plugins blijven dagenlang hetzelfde. Daarom loont het om beide een eigen ritme te geven: de database vaak, de bestanden zelden.

Waarheen: de 3-2-1-regel in het kort

Drie kopieën, op twee verschillende media, waarvan één buiten de deur. Voor een WordPress-site betekent dat: de live-gegevens, een archief op de server, een archief ergens anders.

Het derde punt is waar het meestal misgaat. Een archief dat in dezelfde wp-content/uploads staat als de website, overleeft geen schijffout, geen verwijderd account en geen aanvaller die opruimt.

De back-up van je hostingprovider is goed, maar het is geen tweede plek. Valt de hostingprovider uit, dan vallen beide tegelijk uit. Die back-up telt als één kopie, niet als twee.

Hoe lang: bewaartermijn is geen kwestie van opslagruimte

Wie zeven dagen bewaart, merkt schade die acht dagen geleden is ontstaan, te laat. Juist dat is het veelvoorkomende geval: een database raakt beschadigd of er wordt schadelijke code binnengesmokkeld, en het valt pas weken later op.

Een bruikbare opbouw: de laatste zeven dagen, plus vier weekversies en drie maandversies. Dat kost weinig extra ruimte en dekt het geval af waarin je verder terug moet dan je dacht.

Versleutelen — en waar de sleutel ligt

Een archief bevat de hele database: gebruikersaccounts, bestellingen, e-mailadressen, reacties. Staat het onversleuteld bij een opslagaanbieder, dan is het precies zo vertrouwelijk als die aanbieder.

AES-256 is de gangbare standaard, en de vraag is niet ‘of’, maar waar de sleutel ligt. Naast het archief heb je er niets aan. Kakapo Backup versleutelt met jouw sleutel en slaat die niet mee op — wat betekent dat je hem apart moet bewaren. Een wachtwoordmanager volstaat.

Hoe je merkt dat het werkt

Een back-up die nooit is teruggezet, is alleen maar hoop. Er zijn twee controles, en je hebt ze allebei nodig:

• De technische: klopt de checksum van het archief nog? Die vindt alles wat onderweg is beschadigd — en wel voordat je het nodig hebt.
• De echte: kun je de site eruit herstellen? Die vindt al het andere, en alleen dat telt als het erop aankomt.

1. Maak een stagingkopie — oefen nooit op de live-site.
2. Zet daar het meest recente archief terug.
3. Open de homepage, een subpagina, de backend en, als die er is, het winkelwagentje.
4. Controleer een handvol gegevens in de database: het laatste bericht, de laatste bestelling, een gebruiker.
5. Noteer hoe lang het heeft geduurd. Dat getal is je echte uitvaltijd.

Eén keer per kwartaal is genoeg. Zet een herinnering — anders wordt de test nooit gedaan, omdat hij nooit dringend is.

Het speciale geval dat het vaakst voorkomt

De meeste ‘noodgevallen’ zijn geen serveruitval, maar een update die iets kapot heeft gemaakt. Daarvoor heb je geen volledig herstel nodig, maar een weg terug voor precies die ene plugin — en idealiter een back-up die automatisch vóór elke update wordt gemaakt.

Controleer daarom bij je tool: maakt die vóór updates uit zichzelf een herstelpunt aan? En worden die punten anders bewaard dan de gewone runs? Een weg terug die door de bewaargrens na drie dagen wordt opgeruimd, is er geen.

Veelgestelde vragen