WordPress backup 3-2-1 regel + test-restore gids 2026

De wordpress backup 3-2-1 regel test restore workflow is de enige backup-strategie die ik in 2026 nog aan klanten aanbeveel. Dat komt door één telefoontje in maart. Een webshop-eigenaar uit Antwerpen belde in paniek: site gehackt, checkout naar een malafide gateway.

UpdraftPlus draaide weekly, dus we startten de restore. Vorige week: geïnfecteerd. Twee weken oud: ook. Zes weken oud: eindelijk clean, maar 6 weken orders en klantdata weg. Ongeveer €18.000 orderverlies, reputatieschade niet meegeteld.

Het probleem was niet de plugin. Er was één backup-locatie, geen offsite kopie, en de restore was nooit getest. Reken op 4 tot 6 uur voor een goede eerste 3-2-1 setup, en 2 uur per kwartaal voor de test-drill.

Waarom bijna alle MKB-sites falen bij een echte restore

Backup-setups falen zelden op de dag van installatie. Ze falen op het moment dat je ze nodig hebt. In mijn praktijk kom ik vijf klassen fouten tegen, vrijwel altijd in combinatie.

1. Effectief 1-1-0 in plaats van 3-2-1. Klant heeft één backup, op één medium (dezelfde server als de site), en nul offsite kopieën. Als de hoster brand krijgt of gehackt wordt, is alles weg.
2. Nooit getest. De backup-plugin draait keurig, stuurt maandelijkse success-mails, maar niemand heeft ooit geverifieerd dat de zip-file écht restoreable is. Corrupte archieven, incomplete dumps en missende uploads-mappen kom je pas tegen bij nood.
3. PHP memory limits breken de restore. Een backup van 3 GB unpack je niet met 256 MB PHP memory. Restore-scripts crashen halverwege, laten je site kapot achter, en zonder WP-CLI ben je vast.
4. Encryption keys verloren. Backup is netjes AES-256 versleuteld, maar het wachtwoord staat in een tekstbestand op dezelfde vernietigde server. Zonder key is de backup wiskundig onbereikbaar.
5. Infected backups. De ergste categorie. Malware zit maanden dormant in /wp-content/uploads/ of een geïnfecteerd theme-bestand, dus elke recente backup bevat de backdoor. Zonder oude clean-referentie herstel je alleen maar de infectie.

De EssentialPlugin supply-chain aanval van april 2026 liet dit exact zien. De backdoor zat al sinds augustus 2025 dormant in 30+ plugins, gerapporteerd door BleepingComputer. Sites die alleen 30-daagse backup-retentie hadden, konden niet terug naar een pre-infection state.

WordPress backup 3-2-1 regel test restore: wat de regel precies zegt

De regel komt van fotograaf Peter Krogh (2005, The DAM Book) en is in 2012 door US-CERT formeel geadopteerd als backup-standaard. NIST verwijst ernaar in de Cybersecurity Framework onder “Protect” en “Recover” (zie NIST CSRC guidance). De regel zegt drie dingen:

1. 3 kopieën: één productie-versie plus twee onafhankelijke backups.
2. 2 verschillende media: bijvoorbeeld hosting-snapshot plus cloud-object-storage, of hosting plus fysieke externe HDD. Niet twee kopieën in dezelfde S3-bucket.
3. 1 offsite: minimaal één kopie fysiek gescheiden van de productielocatie. Geen colocatie met je hoster.

Voor Nederlands MKB vertaal ik dat naar:

1. Copy 1: WordPress-site live op hosting.
2. Copy 2: dagelijkse plugin-backup naar cloud (Backblaze B2 of vergelijkbaar).
3. Copy 3: maandelijkse export naar een externe HDD die je fysiek meeneemt of naar een tweede cloud-provider.

Varianten bestaan (3-2-1-1-0 voegt “één offline” en “nul test-errors” toe), maar voor MKB is de basisregel voldoende mits punt 3 (test) daadwerkelijk gebeurt.

Backup-tools voor WordPress 2026: eerlijke vergelijking

Ik gebruik in mijn praktijk vier tools, afhankelijk van site-omvang en klantbudget. Hieronder de vergelijkingstabel met prijzen die ik in augustus 2026 zelf heb geverifieerd.

Mijn defaults: UpdraftPlus Business ($95/jaar, 10 sites) voor multi-site freelancers, BlogVault Plus ($149/jaar) voor hands-off klanten, en JetBackup 5 wanneer de hoster het al heeft. BackWPup is prima gratis mits je zelf encryptie regelt.

Cloud-storage prijzen 2026: waar zet je copy 2?

De offsite kopie is de belangrijkste, en daar wordt bespaard op de verkeerde plek. Cloud object-storage is in 2026 spotgoedkoop, mits je de egress-modellen begrijpt. Ik heb de prijzen op 4 augustus 2026 gecheckt.

Voor 90% van mijn MKB-klanten is Backblaze B2 de juiste keuze: $6/TB/maand, egress gratis tot 3x storage, en S3-compatible API zodat je later kunt migreren. Zie de Backblaze pricing pagina. Boven 5 GB monthly volume is Wasabi vergelijkbaar goedkoop, mits je binnen de 90-dagen minimum past.

RTO en RPO: bepaal je backup-frequentie voordat je een tool kiest

RTO (Recovery Time Objective) is hoe lang je downtime accepteert. RPO (Recovery Point Objective) is hoeveel data-verlies je accepteert. Deze twee getallen bepalen je backup-frequentie en je hostingkeuze, niet andersom.

Deze matrix vertel ik letterlijk aan iedere nieuwe klant. Een fotograaf-portfolio heeft geen 15-minuten-RPO nodig, en een webshop heeft geen weekly-backup nodig. Kies pas een tool nadat je jouw regel in deze tabel hebt gevonden.

Roadmap 1: Initiële 3-2-1 setup in 7 stappen

Dit is de setup die ik voor nieuwe klanten uitvoer, meestal in één sessie van 3 tot 4 uur. Uitgangspunt: WordPress-site draait al, hosting heeft cPanel of vergelijkbaar paneel.

1. Copy 1 configureren (hosting-native): activeer de dagelijkse snapshot bij je hoster. Bij Antagonist en Vimexx zit dat in JetBackup 5, bij TransIP zakelijk in Plesk Backup Manager, bij Kinsta ingebouwd. Verifieer dat backups daadwerkelijk gemaakt worden (kijk in het paneel of er van gisteren één staat).
2. Copy 2 configureren (cloud): installeer UpdraftPlus Business, koppel Backblaze B2 als remote destination met een dedicated App Key. Stel dagelijkse full-backup in (files + database), retentie 14 kopieën. Encryptie AES-256 aan.
3. Copy 3 configureren (cold storage): maandelijkse export naar een externe HDD. Deze HDD ligt fysiek niet bij de klant thuis maar bijvoorbeeld in een bankkluis of bij een familielid. Alternatief: maandelijkse sync naar een tweede cloud-provider (bijvoorbeeld Wasabi als B2 al copy 2 is).
4. Encryption-key beheer: zet het UpdraftPlus wachtwoord in 1Password of Bitwarden onder een dedicated “Backup Keys” vault, gedeeld met minimaal één andere persoon (klant + webmaster). Nooit op dezelfde machine als productie.
5. Retention policy vastleggen: 7 daily + 4 weekly + 6 monthly + 2 yearly. Dat is 19 restore-points en dekt zowel recente ongelukken als dormant-malware scenario’s.
6. Notifications configureren: UpdraftPlus emailt bij success (dagelijks) en bij failure (direct). Voeg de webmaster in CC. Voor extra zekerheid: Better Uptime keyword-check op de backup-log URL.
7. Eerste test-restore inplannen: binnen 30 dagen na setup een staging-restore uitvoeren. Zonder deze stap heb je geen 3-2-1 backup, alleen een 3-2-1 hoop bytes.

Total setup-time in mijn praktijk: 3-4 uur eerste keer (€210-340 aan tarief), daarna hands-off tot de kwartaal-drill.

Roadmap 2: Kwartaal test-restore drill in 7 stappen

Dit doe ik elke 3 maanden voor elke klant met een maintenance-contract. Duur: circa 2 uur. Kost dus 8 uur per jaar, oftewel €560, wat je één keer terugverdient bij één voorkomen incident.

1. Staging voorbereiden (15 min): fresh WordPress-install op een staging-subdomain of lokale Docker-container. Lege database, laatste stable WP-versie. Ik gebruik Local by Flywheel voor 90% van de drills.
2. Meest recente offsite-backup downloaden (variabel): vanuit Backblaze B2 via b2 CLI of de UpdraftPlus remote-restore-functie. Voor een 2 GB backup: circa 30 minuten op een 100 Mbit-verbinding.
3. Restore uitvoeren (20-45 min): via UpdraftPlus “Upload backup files” of via WP-CLI (zie code-blok verderop). Klok de daadwerkelijke tijd bij: dit is je gemeten RTO.
4. Functionele verificatie (20 min): loop de checklist af. Frontend laadt zonder errors, admin-login werkt, checkout-flow compleet (leg een testorder van €0.01). Daarna: contact-form ontvangt daadwerkelijk email, media-library toont afbeeldingen, permalinks werken (geen 404’s op interne links).
5. Restore-tijd loggen: schrijf de gemeten tijden op in een simpel spreadsheet: datum, backup-datum, download-tijd, restore-tijd, verify-tijd, issues. Trend-analyse over 4 drills laat zien of je RTO daadwerkelijk haalbaar is.
6. Staging opruimen: verwijder de restored data, vernietig de container. Voorkomt dat oude test-data ooit in productie belandt.
7. Rapport aan klant: één A4 met concrete metrics (“Backup van 3 augustus, download 28 min, restore 34 min, total RTO 82 min, alle functies OK”) plus eventuele actiepunten.

Cost-benefit: 2 uur drill (€140) per kwartaal vs €18.000 hack-recovery zoals in de Antwerpen-case. Onbespreekbare ROI.

Code die je nodig hebt bij een echte restore

Ik documenteer hier de commando’s die ik minimaal 20 keer per jaar type. Copy-paste klaar.

UpdraftPlus WP-CLI backup en restore

# WP-CLI updraftplus package installeren (eenmalig per site)
wp package install wp-cli/updraftplus-cli

# Directe full backup nu (files + database)
wp updraftplus backup all

# Alleen database (snel, voor pre-migratie snapshots)
wp updraftplus backup db

# Lijst beschikbare backups
wp updraftplus list-backups

# Restore van een specifieke backup-set (nonce uit list-backups)
wp updraftplus restore-backup <nonce>

Backblaze B2 CLI voor server-side SSH-backup

Handig als je hosting geen backup-plugin aan wil of als je een raw server-level dump wil (buiten WordPress om). Draaien vanaf de server via SSH of cron.

# b2 CLI installeren (eenmalig)
pip install b2

# Authenticate met dedicated App Key (NIET master key)
b2 authorize-account $B2_ACCOUNT_ID $B2_APPLICATION_KEY

# Full site + DB dump, gpg-versleuteld, direct naar B2 gestreamd
mysqldump -u dbuser -p'pw' wordpress_db > /tmp/db.sql
tar czf - /var/www/html /tmp/db.sql \
  | gpg --symmetric --cipher-algo AES256 --passphrase-file /root/.backup-key \
  | b2 upload-file lypii-backups - "backup-$(date +%F).tar.gz.gpg"
rm /tmp/db.sql

Cron-jobs voor weekly full + monthly cleanup

# Elke zondag 02:00: full backup via WP-CLI
0 2 * * 0 cd /var/www/html && /usr/local/bin/wp updraftplus backup all

# 1e van de maand 03:00: opruimen backups ouder dan 180 dagen
0 3 1 * * find /home/backups -mtime +180 -type f -delete

PHP memory boost tijdens grote restore

Voor sites met een DB boven 1 GB moet je tijdelijk de memory-limits opschroeven, anders crasht het restore-script halverwege.

// Tijdelijk toevoegen aan wp-config.php tijdens restore, na afloop terugzetten
define('WP_MEMORY_LIMIT', '512M');
define('WP_MAX_MEMORY_LIMIT', '1024M');

// En in php.ini of .htaccess:
// php_value memory_limit 1024M
// php_value max_execution_time 600

Per-hostingpaneel: waar zet je Copy 1?

Hosting-native snapshots zijn je eerste verdedigingslinie. Hieronder per paneel wat de standaard is en waar je ‘m activeert.

DirectAdmin (Antagonist, Vimexx, mijn.host)

1. Log in cPanel → Files → JetBackup 5.
2. Ga naar Destinations → Add Destination → kies “Amazon S3 Compatible” of “Backblaze B2”.
3. Vul de credentials in (gebruik een dedicated App Key, geen master).
4. Ga terug naar Home Backups → Configuration → stel dagelijkse frequency in.
5. Test met Backup Now → verifieer in B2 dat het bestand aankomt.

Plesk (Argeweb, en op VPS bij TransIP en Combell)

1. Log in Plesk → Domains → jouwsite.nl → Websites & Domains → Backup Manager.
2. Remote Storage Settings → configureer S3, FTP, of Google Drive.
3. Schedule → dagelijks, houd 14 kopieën aan.
4. Content: “Websites” + “Databases” + “Mail” (indien van toepassing).

cPanel (o.a. Neostrada)

1. User-level → SystemBackup2 (moet als admin geactiveerd zijn).
2. Configureer FTP/SFTP-destination voor offsite kopie.
3. Cron: 0 2 * * * /usr/local/bin/da-backup-user user_name.

Hostinger hPanel

1. hPanel → Files → Backups.
2. Auto backups: 7-dagen retentie standaard, activeer expliciet.
3. Voor offsite: combineer met UpdraftPlus want hPanel-backups blijven op Hostinger.

Managed WordPress hosting

1. Kinsta: MyKinsta → Sites → jouwsite → Backups. Automatic daily (14-30 dagen retentie afhankelijk van plan), plus downloadable snapshots. Hourly-backups zijn een betaalde add-on.
2. WP Engine: User Portal → jouwsite → Backup Points. Automatic daily, 40-dagen retentie op alle plans, on-demand backups mogelijk.
3. Cloudways: Platform → Server Management → Backups. Hourly incremental (default 1-uur), on-demand, retentie tot 4 weken configureerbaar.

Nederlandse hosters specifiek

1. Antagonist: JetBackup 5 in cPanel, dagelijkse snapshots retentie 14 dagen op business-plans.
2. TransIP: Plesk zakelijk met eigen “Backup Service” (extra), plus hourly VPS-snapshots op Blade-VPS.
3. Combell: Plesk met ingebouwde Acronis-backup, retentie 30 dagen op higher-tier plans.

Deze snapshots zijn nooit je enige backup. Ze zijn Copy 1 in de 3-2-1 regel.

Encryption-strategie: doe dit voordat je er niet meer aan denkt

Encryptie is de stap die iedereen overslaat totdat het misgaat. Vier concrete richtlijnen die ik hanteer.

1. Client-side encryption bij voorkeur: encrypt de backup vóór upload naar cloud. UpdraftPlus Premium doet dit met AES-256. Server-side encryption door de cloud-provider (SSE-S3, B2’s default) beschermt tegen fysieke diefstal, niet tegen een gecompromitteerde cloud-account.
2. Key rotation jaarlijks: elk kalenderjaar nieuwe encryption-passphrase, oude passphrase blijft bewaard voor legacy backups. Documenteer welke key bij welke retention-periode hoort.
3. Password manager voor keys: 1Password Teams ($19.95/maand voor 10 users) of Bitwarden Teams ($6/user/maand). Nooit een key in wp-config.php, nooit in een plain-text file op de server, nooit in een e-mail.
4. Recovery-plan wanneer key verloren: er is geen recovery-plan. AES-256 is wiskundig onbreekbaar binnen realistische computer-tijden. Als je de key verliest, verlies je de backup. Bewaar dus minimaal twee onafhankelijke kopieën van de key.

De encryptie-tabel hieronder is de kortste manier om te kiezen welk mechanisme past bij welk scenario.

Drie concrete restore-scenario’s uit mijn praktijk

Scenario 1: Hack met dormant backdoor, recovery van 3 maanden oude backup

Klant: WooCommerce shop uit Gent, april 2026, EssentialPlugin-getroffen. Backdoor stond sinds augustus 2025 in een plugin die “veilig” leek. Alle backups van september t/m april waren geïnfecteerd. Enige clean referentie: juli-backup.

Aanpak:

1. Restore juli-backup naar staging, run Wordfence malware-scan → clean bevestigd.
2. Migreer alleen /wp-content/uploads/ (media) van laatste clean-backup vóór incident, filter op file-type (alleen images, geen PHP).
3. Bestellingen tussen september en april reconstrueren via Mollie API export en Stripe dashboard export. In Excel joinen op klant-email, importeren als WooCommerce orders via WP-CLI.
4. Content (blogs, product-updates) tussen augustus en april: waar mogelijk uit Google Search Console cache en Wayback Machine gerecupereerd.
5. Totale recovery-tijd: 14 uur werk verspreid over 3 dagen. Kosten voor klant: €980. Zonder oude offsite-backup: totaal verlies aan orderdata en bestandsstructuur.

Scenario 2: WooCommerce restore met 5 GB database

Klant: B2B-shop uit Terneuzen, database 5.2 GB na 4 jaar order-historie. UpdraftPlus web-restore crashte op 512 MB PHP memory. Fix in 4 stappen:

1. Verhoog WP_MAX_MEMORY_LIMIT naar 2048M in wp-config.php.
2. Verhoog max_execution_time naar 900 in php.ini (via hostingpaneel).
3. Restore via WP-CLI: wp updraftplus restore-backup met --skip-plugins --skip-themes om memory-druk te verlagen.
4. Grote SQL-imports: split het dump-bestand met split -l 500000 db.sql db-part- en import per file via wp db import.
5. Achteraf terug naar 512M memory-limit want anders trekken bots je server dicht.

Scenario 3: Encrypted backup zonder wachtwoord

Klant erfde een site na overname, oude webmaster onbereikbaar. AES-256 encrypted UpdraftPlus-backups in Dropbox, wachtwoord onvindbaar. Recovery: onmogelijk. Gebroken. AES-256 met een goed wachtwoord (>12 karakters random) is niet brute-forceable met realistische middelen.

Les: dit is exact waarom stap 4 in Roadmap 1 (encryption-key beheer via password manager, gedeeld met minimaal twee personen) niet optioneel is. In dit geval hebben we de site opnieuw opgebouwd vanaf de laatste onversleutelde hosting-snapshot van 4 maanden oud, met 4 maanden dataverlies als gevolg.

Long-term monitoring: hoe je backups op orde blijven

De setup is klaar in 4 uur. Onderhoud is 2 uur per kwartaal plus vier monitoring-praktijken.

1. Automated notification op failure: Better Uptime met keyword-check op je backup-log URL. Elke faal-status geeft direct SMS/push. Backup die “stil” is gestopt is de dodelijkste variant.
2. Monthly log-review: eerste maandag van de maand, 15 minuten. Zijn alle 30 dagen aanwezig? File-sizes consistent (plotselinge daling = corrupte backup)? Retention-regels correct toegepast?
3. Yearly disaster-recovery drill: één keer per jaar volledige rebuild-from-scratch. Nieuwe hosting, restore vanuit alleen offsite Copy 2 en Copy 3. Simuleert echte hoster-uitval. Duurt 4-6 uur en is de enige echte validatie van je 3-2-1 setup.
4. Retention-policy documentatie: één A4 met welke backups waar staan, wie de encryption-keys heeft, wat de RTO/RPO is, en de eerst-volgende drill-datum. Dit is wat de opvolgende webmaster ontvangt.

Wanneer je een webmaster inschakelt

Doe de 3-2-1 setup zelf als je comfortabel bent met hosting-panelen, cron-jobs en een cloud-provider dashboard. Bel iemand in als:

1. Je site draait op een custom stack (Laravel + WordPress, headless, multisite).
2. Je database boven 2 GB is en je nog nooit een restore hebt gedaan.
3. Je AVG-plichtig bent (klantdata, medische data, financiële data) en encryptie moet aantoonbaar zijn.
4. Je een lopende hack hebt en niet weet wanneer de infectie begon (dormant scenario).
5. Compliance-verplichtingen (ISO 27001, NEN 7510, PCI-DSS) waar backup-testing schriftelijk aantoonbaar moet zijn.

Voor mijn klanten kost een initiële 3-2-1 setup 3-4 uur (€210-340), en 2 uur per kwartaal voor de drill (€140 per kwartaal, €560 per jaar). Vergelijk dat met één hack-recovery: gemiddeld 8-16 uur werk (€560-1360) plus omzetverlies tijdens downtime.

Vast bij een restore of setup?

Zelf 3-2-1 opzetten is doenbaar in een middag als je hosting-panelen begrijpt. Vastlopen op memory-limits, gecompromitteerde backups, of AVG-conforme encryption-setup? Stuur me een mail via /contact/. Ik doe de initiële setup meestal in één sessie van 3-4 uur, en neem daarna de kwartaal-drills over. Je factuur is €70/uur, geen abonnement, geen minimum-afname.