Serhii LypiiWordPress backup testen is de stap die iedereen overslaat, tot een restore mislukt op het moment dat het écht moet. De mythe: “ik heb UpdraftPlus, dus ik zit goed”. De realiteit: ongeteste backups falen vaker dan mensen denken. Corrupte zips, incomplete database-dumps, ontbrekende media-mappen, verkeerd geconfigureerde offsite-storage. Dit artikel loopt in zes stappen een test-restore-procedure door die je zonder je live site te raken kunt uitvoeren, met Local (voorheen Local by Flywheel, nu van WP Engine) of een staging-omgeving als sandbox en WP-CLI voor de zware checks. Aan het einde weet je zeker dat je backup werkt, en heb je een documentatie-log waar je in een crisis op terug kunt vallen.
De kern is simpel: een backup die je nooit hebt teruggezet, is geen backup, maar een aanname.
Waarom een ongeteste backup geen backup is
De backup-industrie leert twee tegenstrijdige dingen. Eén: kies een goede plugin en je bent klaar. Twee: alleen een geverifieerde restore telt. Het eerste is marketing, het tweede is waar.
Ik zie in de praktijk vier veelvoorkomende faal-patronen:
- Zip-corruptie in offsite-storage. De download werkte, maar bij unzip komen niet alle bestanden mee.
- Incomplete database-dump. De plugin exporteerde alleen tabellen met bepaalde prefix, of stopte halverwege door een memory-limiet.
- Ontbrekende media-mappen. Uploads groter dan de plugin-timeout werden overgeslagen. Je site restoret, maar met stukken van het beeld weg.
- Verkeerde retention. De plugin bewaart alleen 7 dagen, maar de crash werd pas na 10 dagen ontdekt.
Al deze problemen zijn onmerkbaar tot je een restore probeert. En op dat moment is de bewijstijd voorbij. Vandaar dit artikel: één keer per kwartaal een test-restore, en je backup verandert van aanname in zekerheid.
WordPress backup testen: 6 stappen route
De volledige route neemt ongeveer 90 tot 120 minuten voor een middelgrote site. Overzicht:
| Stap | Wat | Tijd |
|---|---|---|
| 1 | Backup downloaden | 5-15 min |
| 2 | Integriteit checken (SHA256, zip-check) | 5 min |
| 3 | Restore-omgeving opzetten (Local of staging) | 15-20 min |
| 4 | Files + database importeren, URLs vervangen | 20-30 min |
| 5 | Functionele checklist doorlopen | 15-20 min |
| 6 | Rapporteren en documenteren | 5-10 min |
Deze zes stappen loop ik hierna in detail door. Doe dit bij een eerste test rustig aan; vanaf de tweede keer weet je waar de valkuilen zitten en gaat het sneller.
Stap 1 en 2: backup downloaden en integriteit checken
Log in op je backup-locatie (Google Drive, S3, Dropbox, hosting-panel) en download de meest recente backup naar je laptop. Meestal krijg je twee bestanden of één gecombineerd archief: een database-dump (.sql of .sql.gz) en een files-archief (.zip of .tar.gz).
Integriteit controleren voor je verder gaat.
Op Mac of Linux:
shasum -a 256 backup.zip
unzip -t backup.zipOp Windows:
certutil -hashfile backup.zip SHA256De SHA256-hash vergelijk je met de hash die je backup-plugin of hosting-panel toont (als die functionaliteit er is). Matchen ze niet, dan is het bestand tijdens download corrupt geraakt. Download opnieuw.
unzip -t test de integriteit van elk bestand in de zip zonder ze uit te pakken. Krijg je errors, dan is de backup zelf corrupt. Ga terug naar je backup-tool en check een oudere versie.
Voor de database-dump: open met een text-editor of head en tail en kijk of het bestand begint met CREATE TABLE (of vergelijkbaar) en eindigt met COMMIT of -- Dump completed. Een dump die halverwege afbreekt herken je aan een lege of onvolledige laatste regel.
Stap 3: restore-omgeving opzetten (Local of staging)
Nooit een test-restore op je live site draaien. De sandbox-optie die ik zelf gebruik is Local: gratis, cross-platform (Mac, Windows, Linux), en installeert in vijf minuten.
De workflow in Local:
- Open Local en klik “Create a new site”.
- Kies een sitenaam (bijvoorbeeld
test-restore-2026-07). - Kies “Preferred environment” (of custom, met dezelfde PHP-versie als live).
- Log met dummy-credentials in de tijdelijke admin.
Alternatief is een staging-omgeving bij je hosting. Kinsta, WP Engine, SiteGround en Hostinger hebben allemaal een one-click staging. Voordeel: identieke serveromgeving als live. Nadeel: je gebruikt server-resources en de test-restore is minder geïsoleerd.
Voor grote sites (5+ GB uploads, complexe database) is staging vaak sneller. Voor middelgrote sites (onder 5 GB) is Local prima en makkelijker.
Stap 4: files + database importeren
Nu de kern. In Local (of op staging) importeer je eerst de files, daarna de database.
Files. Pak de zip uit in de site-map van Local: ~/Local Sites/test-restore-2026-07/app/public/. Overschrijf de bestaande wp-content-map (die zit in de nieuwe installatie). Bij grote uploads-mappen kan dit een paar minuten duren.
Database. In Local klik je op “Database” tab en dan “Open Adminer”. Import de .sql-dump via het adminer-scherm, of via WP-CLI:
wp db import backup.sqlwp-config.php aanpassen. Local heeft eigen DB-credentials (root/root op localhost). Als jouw wp-config-backup andere waarden bevat, moet je die overschrijven met de Local-waarden voor DB_NAME, DB_USER, DB_PASSWORD, DB_HOST.
URLs vervangen. Live URL (bijvoorbeeld https://jouwsite.nl) moet vervangen door de Local-URL (bijvoorbeeld https://test-restore-2026-07.local). WP-CLI is hiervoor de veiligste route omdat hij serialized data correct herschrijft:
wp search-replace 'https://jouwsite.nl' 'https://test-restore-2026-07.local' --all-tables --dry-runDry-run eerst, altijd. Als de output er goed uitziet, draai je hetzelfde commando zonder --dry-run.
Stap 5: functionele checklist doorlopen
De site laadt in Local? Mooi. Nog niet klaar. Doorloop deze minimale checklist:
- Homepage laadt zonder JS-fouten of ontbrekende beelden. Open DevTools, tab Console, en kijk of er rode errors staan.
- Admin login werkt. Log in met je normale credentials. Als je 2FA gebruikt, is dat op Local meestal even uit (staging kan lastiger zijn).
- Één blogpost laadt volledig. Content, featured image, comments (als je die hebt).
- WooCommerce (indien van toepassing): open een product, leg in cart, ga naar checkout. Verwacht geen echte betaling, wel dat het formulier laadt zonder errors.
- Contactformulier of andere kernfunctie. Klik door en check dat het formulier zichtbaar en interactief is.
- Media-map is compleet. Bezoek
/wp-content/uploads/2024/en check dat er bestanden inzitten voor recente maanden.
Op WooCommerce-shops voeg ik extra items toe: één order-detailpagina openen, coupons-lijst checken, subscriptions-plugin (indien aanwezig) doorlopen. Managed hosts hebben soms hun eigen “one-click restore” functionaliteit; test ook die apart, niet alleen de plugin-backup.
Vindt je een probleem, dan noteer je het en zoek je de oorzaak. Meestal is het: verkeerde URL-vervanging (voeg een run toe met andere spelling zoals http:// naast https:// en www. naast bare domain), of ontbrekende database-tabellen (check wp db tables output).
Stap 6: rapporteren en documenteren
Klein maar cruciaal. Schrijf een kort logboek van deze test.
Voorbeeld-template:
Test-restore log
Datum: 2026-07-19
Backup-bron: UpdraftPlus, offsite naar Google Drive
Backup-datum: 2026-07-18 03:00
Restore-omgeving: Local, PHP 8.3
Duur: 1u 45min
Issues gevonden:
- Elementor global styles niet direct geladen na URL-replace
Fix: extra wp search-replace op elementor-CSS-map
Test-checklist: alles OK na fix
Volgende test: 2026-10-19Bewaar dit logboek op dezelfde plek als je backup-configuratie. Bij een crisis weet je precies welke backup-versie recent gerestored werd, wat de bekende issues zijn, en hoe je die snel oplost. Voor de WP-CLI-commando’s die je hier gebruikt is de officiële WP-CLI database import documentatie de bron.
Hoe vaak testen: realistisch schema voor MKB
Testfrequentie hangt af van site-type:
- Statische bedrijfssite of portfolio: kwartaal-test volstaat.
- Actieve blog met wekelijkse content: maandelijkse test.
- WooCommerce-shop: maandelijkse test verplicht, extra na elke grote plugin-update.
- Membership-site of complexe custom app: maandelijkse test, met scenario-check (kan een lid nog inloggen na restore?).
Bewaar retention op minimaal 30 dagen dagelijkse backups en 6 maanden wekelijkse backups. De 3-2-1 regel blijft in 2026 valide: 3 kopieën van je data, 2 verschillende media, 1 offsite. Voor de meeste MKB-sites vertaalt dat naar: hosting-snapshot + plugin-backup naar cloud + één maandelijkse export lokaal.
Wanneer je een specialist inschakelt
Er zijn drie scenario’s waar externe hulp de tijd waard is. Ten eerste: een test-restore procedure inrichten die je zelf periodiek kunt draaien (eenmalige investering, jaren rendement). Ten tweede: een spoed-restore bij een crisis waarin de backup niet vanzelf terug wil. Ten derde: complexe site-migraties waarin backup en restore samenkomen met DNS, mail en SSL.
Een volledige backup + restore-test procedure inrichten kost bij mij drie tot vijf uur op het 105-euro-tarief voor het senior werk. Een spoed-restore in crisis (bijvoorbeeld ’s avonds of in het weekend) werk ik op 175 euro per uur. Preventief inrichten scheelt bijna altijd meerdere spoed-uren later. Direct contact, geen bureau-tarieven, en de source-code plus backup-configuratie blijft van jou zodat je nooit vast zit bij één partij.
Voor recovery-scenario’s specifiek is een route via WordPress recovery mode een parallelle skill die naast backup-restore hoort te staan in je disaster-recovery-checklist. Verbeteren boven herbouwen: een goed geteste backup betekent dat je bij een crash niet opnieuw hoeft te bouwen; je hoeft alleen te herstellen.
Multi-stack noot. WooCommerce vraagt extra checklist-items (orders, subscriptions, coupons). Managed hosts hebben eigen restore-tools die je apart moet testen. Op Joomla werkt Akeeba Backup vergelijkbaar met een test-restore-flow via Kickstart, op Drupal gebruik je drush sql-cli en drush cr voor de restore-check.
