WordPress backup-strategie: wat, hoe vaak en waar

De meeste WordPress-eigenaren denken dat ze backups hebben. Meestal hebben ze die niet. Ze hebben een vinkje in hun hostingpaneel dat ze ooit hebben aangezet, een plugin die ze hebben geïnstalleerd en daarna vergeten, of een mapje op dezelfde server waar de site op draait. Geen van die drie is een backup-strategie. Een echte strategie beantwoordt vier vragen op volgorde: wat je backupt, hoe vaak, waar je hem neerzet, en hoe je bewijst dat hij nog werkt als de rest in de fik staat. Dit artikel loopt ze alle vier door en geeft je een configuratie die je vandaag kunt uitrollen.

De inzet is hoger dan je denkt. Rollback voor auto-updates zit sinds WordPress 6.6 (juli 2024) in core voor plugin-auto-updates die crashen met een PHP fatal error, en WordPress 6.3 (augustus 2023) voegde al rollback toe voor mislukte handmatige plugin- en theme-updates. Die vangnetten pakken één specifieke klasse van "update brak de site"-problemen. Ze doen niets voor verwijderde content, ransomware, een gehackt admin-account of een host die drie dagen lang onbereikbaar is. Alleen een backup die je ook echt terug kunt zetten, doet dat wel.

In het kort

Als je maar vijf dingen uit dit artikel onthoudt, onthou dan deze:

1. Een backup is database plus bestanden. Geen van beide is alleen genoeg. De database bevat je posts, pagina's, reacties, instellingen en gebruikers. De bestanden bevatten je uploads, thema's, plugins, wp-config.php en .htaccess. Het ene herstellen zonder het andere geeft je een kapotte site.
2. Frequentie volgt de snelheid waarmee je site verandert. Een statische brochuresite met maandelijkse updates kan prima toe met een wekelijkse backup. Een blog dat dagelijks publiceert heeft dagelijkse backups nodig. WooCommerce en meerdere auteurs vragen om ieder uur of elke vier uur, want elke transactie of post is unieke data die je niet kunt reconstrueren.
3. Minstens één kopie staat buiten je hostomgeving. Backups op dezelfde server sterven met die server mee. De 3-2-1 regel is: drie kopieën, twee soorten opslag, één offsite.
4. Host-backups zijn een extra laag, geen strategie. Ze helpen wel, maar je hebt er geen controle over. Ze draaien op dezelfde infrastructuur als je site, met bewaartermijn en granulariteit die jij niet bepaalt.
5. Een backup die je nooit hebt teruggezet, is geen backup. Doe minstens één keer een restore-oefening naar een staging-omgeving voordat je hem echt nodig hebt.

De rest van dit artikel is de onderbouwing en de exacte configuratie die elk van die vijf regels in praktijk brengt.

Inhoudsopgave

• Waar een WordPress-backup uit bestaat
• Waarom host-backups niet genoeg zijn
• Hoe vaak je moet backuppen
• Waar backups horen: de 3-2-1 regel
• Een backup-plugin kiezen
• UpdraftPlus instellen voor een 3-2-1 setup
• Backuppen vanaf de command line
• Je backup testen door hem terug te zetten
• De absolute ondergrens: backup voor elke update
• Mythes die beter kunnen sneuvelen

Waar een WordPress-backup uit bestaat

Een WordPress-site is twee dingen die op twee plekken leven, en een echte backup kopieert ze allebei. De officiële WordPress backup-documentatie is er duidelijk over: je hebt de database én de bestanden nodig, en het een zonder het ander is niet genoeg.

De database is een MySQL- of MariaDB-database die je benadert via de gegevens in wp-config.php. Hij bevat elke post en pagina die je ooit hebt geschreven, elke reactie, elk gebruikersaccount en hun hashed wachtwoorden, de inhoud van wp_options (de tabel waar vrijwel elke plugin zijn configuratie opslaat), Customizer-instellingen, menu's, widgets, en voor WooCommerce-sites: elke bestelling, klant, productattribuut en voorraadniveau. Als iemand zegt "ik ben drie jaar aan blogposts kwijt", is de database het ding dat ze zijn kwijtgeraakt. Een databasedump is meestal één .sql of .sql.gz bestand van een paar megabyte tot een paar honderd.

De bestanden zijn de PHP, CSS, JavaScript, afbeeldingen en configuratie die in de WordPress-map op schijf staan. Een echte file-backup dekt minimaal:

• wp-content/uploads/: elke afbeelding, PDF, videothumbnail en media-upload die iemand ooit heeft geüpload. Meestal de grootste map en de enige die je niet ergens anders vandaan kunt halen.
• wp-content/themes/: je actieve thema, child theme en alle aanpassingen die buiten de Customizer om zijn gemaakt. Als je een developer hebt betaald voor een custom theme, zit je investering hier.
• wp-content/plugins/: alle plugins, ook de betaalde. Gratis plugins kun je terugvinden op wordpress.org, betaalde plugins vragen om een license lookup en soms een supportticket. Backup ze gewoon.
• wp-content/mu-plugins/: must-use plugins worden automatisch geladen en worden vaak gebruikt voor host-specifieke hooks en custom drop-ins. Als er iets in staat, heb je het nodig.
• wp-config.php: database-credentials, secret keys en omgevingsconstanten. Backuppen, maar versleuteld of buiten de webroot bewaren want het bevat geheimen.
• .htaccess: op Apache-hosts staan hier custom rewrite-regels, security headers en redirects. Makkelijk te vergeten en irritant om opnieuw op te bouwen.
• robots.txt en favicon.ico: klein en triviaal, maar als je ze hebt aangepast, neem ze mee.

De WordPress database backup guide verwoordt het kort: database-backups "do NOT back up your WordPress files (themes, plugins, uploads, wp-config.php, etc.)". Als je alleen je database backupt, backup je de helft van je site.

Waarom host-backups niet genoeg zijn

De meeste managed WordPress-hosts maken backups. Shared hosts zoals Hostinger of SiteGround doen het. Managed platforms zoals WP Engine en Kinsta ook. Dat is waar en echt nuttig, en deze sectie zegt niet dat host-backups waardeloos zijn. Ze zegt dat het een laag is, geen strategie, en dat je er niet op moet bouwen als je enige plan.

Er zijn drie dingen die misgaan als host-backups je enige backup zijn.

Ze staan op dezelfde infrastructuur als je site. Een host-backup is meestal een server-snapshot of een block-level image die bij dezelfde provider staat, soms in hetzelfde datacenter, af en toe op dezelfde fysieke machine. Als het misgaat door hardwareverlies, een ransomware-infectie die het host-account heeft versleuteld, of de provider die failliet gaat, ben je de backup tegelijk met de site kwijt. De UpdraftPlus-auteurs rekenen het uit in hun artikel over offsite backups, en de conclusie staat los van welke plugin je gebruikt: redundantie binnen één provider is geen redundantie.

Bewaartermijn en granulariteit bepaal je niet zelf. Hosts bewaren meestal 7 tot 30 dagen, op goedkope plannen soms maar de laatste 3. Als je 40 dagen later een compromittering of stille datacorruptie ontdekt (en dat is vaak, want aanvallers proberen juist stil te blijven), is de schone versie weg. Host-backups zijn ook vaak hele-site snapshots in plaats van per-tabel of per-bestand restores, dus één per ongeluk verwijderde pagina herstellen betekent de hele site terugdraaien en alles kwijtraken dat sindsdien is gebeurd. Eén product in een WooCommerce-catalogus terugzetten zonder nieuwe orders te verliezen is via het host-panel vaak gewoon onmogelijk.

Je bent afhankelijk van het interface en de support van de host. Sommige hosts laten je "restore" klikken in een dashboard. Andere vragen om een supportticket, een wachtrij en een kostenpost. Tijdens een incident is onderhandelen met een support desk precies het moment waarop je het niet moet hebben van iemand anders' reactietijd.

De WordPress backup-documentatie is mild maar ondubbelzinnig: automatische backups hoor je aan te vullen met handmatige backups "to guarantee that the process is working". Vertaling: je hebt een eigen, off-host backup nodig waar jij zelf over gaat. Gebruik host-backups als snelle route voor "de site brak tijdens een update, zet me terug naar een uur geleden" en gebruik je eigen backups voor al het andere.

Hoe vaak je moet backuppen

De juiste frequentie is het tempo waarop je site verandert. De manier om erover na te denken is deze vraag: als de site nu zou breken, hoeveel nieuwe content ben ik bereid om handmatig opnieuw te maken? Het antwoord daarop is je maximum backup-interval. De WordPress docs geven de ruwe schets; hieronder staan de categorieën die de meeste echte sites dekken.

Twee details zijn hier belangrijk. Ten eerste kun je bestanden en database op aparte schema's zetten. De uploads-map van een WooCommerce-store verandert langzaam (nieuwe productfoto's), maar de database verandert continu (nieuwe orders). UpdraftPlus ondersteunt die splitsing standaard: bestanden op het ene schema, database op het andere, want ze als één geheel behandelen verspilt bandbreedte aan data die nauwelijks muteert.

Ten tweede is "backup voor elke update" geen onderhandelbare regel en staat hij boven op welk regulier schema je ook kiest. De WordPress upgrade guide noemt "Backup your database" en "Backup ALL your WordPress files in your WordPress directory" als vereiste stappen voor een upgrade. Hij is bot over wat er gebeurt als je ze overslaat: "without a backup of your entire site and your database, made prior to your upgrade attempt, a successful rollback is near impossible." Een nachtelijke backup van 22 uur geleden is niet recent genoeg als je op het punt staat een plugin aan te raken die bij elke request draait.

Waar backups horen: de 3-2-1 regel

De 3-2-1 regel is het oudste, meest geciteerde en meest genegeerde principe in backup-ontwerp. Hij zegt: drie kopieën van je data, op twee verschillende soorten opslag, met minstens één kopie offsite. Op WordPress toegepast ziet dat er zo uit:

• Kopie 1: de live site zelf.
• Kopie 2: een recente backup op een andere plek dan de live site. "Andere plek" betekent niet "een andere map op dezelfde server". Het betekent een andere provider, een ander account of een andere fysieke infrastructuur. Google Drive, Dropbox, Amazon S3, Backblaze B2 of een aparte server die jij beheert zijn allemaal geldig. Een map in wp-content/backups/ is dat niet.
• Kopie 3: een oudere backup, verder weg. Een lokale download op je laptop, een versleutelde externe schijf, of een tweede cloudprovider. Dit is de kopie die "mijn cloud-account is gekaapt" en "mijn enige provider had een factuurgeschil" overleeft.

De UpdraftPlus-auteurs schrijven er uitgebreid over in hun 3-2-1 backup-artikel, en ze passen het toe op hun eigen product. Praktisch vertaalt het zich eenvoudig: kies één cloudopslag-bestemming waar je backup-plugin automatisch naar toe pusht, en download één keer per maand de laatste backup naar je eigen apparaat. Vijf minuten frictie per maand koopt een herstelpad dat alles overleeft behalve een brand.

Bewaar de kopie die offsite staat niet onversleuteld als hij gebruikersdata bevat. Een WordPress-backup bevat hashed wachtwoorden, e-mailadressen, IP-adressen van reageerders, en voor WooCommerce-sites ook factuuradressen en bestelgeschiedenis. Dat is persoonsgegevens onder de AVG. UpdraftPlus, BackWPup en BackupBuddy bieden allemaal backup-versleuteling; zet het aan, bewaar de sleutel in een wachtwoordmanager en schrijf de sleutel ook ergens anders op voor het geval je die manager kwijtraakt.

Een backup-plugin kiezen

Drie plugins domineren de WordPress backup-markt en ze maken alle drie andere afwegingen. Hier is de eerlijke vergelijking.

UpdraftPlus is de meest geïnstalleerde backup-plugin in de WordPress.org directory met meer dan drie miljoen actieve installs. De gratis versie ondersteunt als backup-bestemmingen: Dropbox, Google Drive, Amazon S3 en compatible, Rackspace Cloud, FTP, DreamObjects, OpenStack Swift en e-mail. Gratis schema-opties: elke 2, 4, 8 of 12 uur, dagelijks, wekelijks, tweewekelijks en maandelijks, met losse schema's voor bestanden en database. Restores zijn component-selectief, wat betekent dat je alleen de plugins-map kunt terugzetten, alleen de database, of alleen uploads. De betaalde versie voegt Microsoft OneDrive, Azure, Google Cloud, Backblaze B2, SFTP, SCP, pCloud en WebDAV toe, plus incrementele backups, automatische backup voor elke update, tegelijkertijd naar meerdere bestemmingen pushen, en backup-versleuteling. De huidige stabiele versie in april 2026 is 1.26.2, en de plugin wordt sinds 2011 onafgebroken onderhouden.

BackWPup is de op een na populairste gratis optie en voelt comfortabeler voor gebruikers die Dropbox, S3, FTP en SugarSync al bij naam kennen en een sobere interface willen die meer technische knoppen laat zien. Hij is minder gepolijst dan UpdraftPlus en de gratis versie heeft minder vangnetten, maar hij is helemaal gratis en heeft geen feature-gating op de kern van de backup-flow.

Duplicator is de keuze als je primaire use case clonen of migreren is, niet terugkerende backups. Hij pakt de hele site in één installer-archief dat op een nieuwe host wordt neergezet en zichzelf daar reconstrueert. Voor pure terugkerende backups is UpdraftPlus of BackWPup een betere match; voor "ik moet deze site dit weekend verhuizen naar een nieuwe host" is Duplicator de juiste tool.

Mijn standaardadvies voor vrijwel elke site is UpdraftPlus op de gratis versie, met Google Drive of Dropbox als cloudbestemming voor kleine sites, en S3 of Backblaze B2 voor grotere sites waar de hoeveelheid bestanden of de opslagkosten Google Drive onpraktisch maken. De reden is pragmatisch: UpdraftPlus heeft de grootste installbase, wat betekent dat er de meeste community-troubleshooting omheen zit, de meest geteste restore-paden, en de grootste kans dat degene die je tijdens een incident helpt het probleem al een keer heeft gezien.

Eén detail om zuiver over te zijn. UpdraftPlus-versies 1.24.x en 2.24.x (medio 2024) hebben hun Google Drive-integratie aangepast om te voldoen aan Google's Granular Consent requirement, die op 17 juni 2024 in werking trad. De update voegt scope-level permissiechecks toe tijdens authorisatie en voorkomt een PHP deprecation warning na een geslaagde Google Drive-auth. Het is geen nieuw OAuth2-systeem; UpdraftPlus gebruikt OAuth2 via een geregistreerde Google-app al sinds versie 1.13.6 in september 2017. Als je Google Drive opnieuw autoriseert na een upgrade naar UpdraftPlus 1.24 of later, kan het zijn dat je een aangepast Google consent-scherm ziet. Dat is verwacht en geen probleem.

UpdraftPlus instellen voor een 3-2-1 setup

Hier is de exacte configuratie voor een site met dagelijkse backups en Google Drive als offsite bestemming. Pas het schema aan je contenttempo aan volgens de tabel hierboven.

Vereisten:

• WordPress 6.0 of nieuwer (UpdraftPlus 1.26.x vereist minimaal WordPress 5.6, maar 6.0+ geeft je de actuele featureset).
• PHP 7.4 of nieuwer (UpdraftPlus 1.26.x ondersteunt geen oudere PHP).
• Een Google-account met minstens een paar gigabyte vrije Drive-opslag, of een andere bestemming als je die liever hebt.
• FTP/SFTP of file-manager toegang tot je site, voor het geval de plugin-pagina zelf niet bereikbaar is tijdens een herstel.
• Administrator-toegang tot het WordPress-dashboard.

Stappen:

1. Ga in het WordPress-dashboard naar Plugins > Nieuwe plugin toevoegen, zoek op UpdraftPlus en installeer de plugin van UpdraftPlus.Com, DavidAnderson. Activeer hem.
2. Ga naar Instellingen > UpdraftPlus Backups. Klik op de tab Settings.
3. Zet Files backup schedule op Daily en Retain this many scheduled backups op 14. Dat geeft je twee weken aan bestands-backups, wat voor contentsites de minimale zinvolle bewaartermijn is.
4. Zet Database backup schedule op Daily en Retain this many scheduled backups op 30. Databasebackups zijn klein genoeg dat een maand goedkoop is, en de extra historie helpt als je stille corruptie pas laat opmerkt.
5. Kies bij Choose your remote storage voor Google Drive. Een Google Drive authenticatielink verschijnt verderop op de pagina nadat je op Save Changes klikt.
6. Laat alle file-type vinkjes aangevinkt onder Include in files backup: Plugins, Themes, Uploads en Others onder wp-content. Zet Others alleen uit als je precies weet wat erin zit en een reden hebt.
7. Scroll naar onder op de pagina en klik op Save Changes.
8. Boven in de Settings-tab zal Google Drive nu een gele waarschuwing tonen met het verzoek om te authentiseren. Klik op de link, doorloop de Google OAuth-flow, geef UpdraftPlus toegang tot zijn eigen app-folder (niet tot je hele Drive), en bevestig de redirect terug naar je WordPress-site.
9. Ga terug naar de tab Current Status en klik op Backup Now. Vink in het dialoogvenster zowel Include the database in the backup als Include any files in the backup aan en bevestig. De eerste backup kan een paar minuten duren, afhankelijk van de grootte van je site.
10. Als de backup klaar is, scroll je naar Existing Backups. Je hoort daar één regel te zien met kolommen Database, Plugins, Themes, Uploads en Others, elk met een groen vinkje en een downloadlink. Klik op het refresh-icoon naast Google Drive; de backup hoort als geüpload naar Google Drive weergegeven te worden.

Verwachte uitvoer: Een nieuwe map in je Google Drive met de naam UpdraftPlus waarin vijf bestanden per backup staan: backup_YYYY-MM-DD-HHMM_sitename_hash-db.gz, en -plugins.zip, -themes.zip, -uploads.zip, -others.zip. Als er een bestand mist, is de backup incompleet en moet je uitzoeken wat er misgaat voordat je hem vertrouwt.

Verificatie van het eindresultaat: Draai Backup Now direct nog een keer na de eerste backup om te bevestigen dat het schema on demand werkt, wacht dan 24 uur en controleer of er automatisch een nieuwe backup verschijnt. Vertrouw het schema pas als je het minstens één keer vanzelf hebt zien draaien.

Backuppen vanaf de command line

Voor developers en iedereen die meerdere sites beheert, is de command-line route korter en scriptbaar. Het WP-CLI wp db export commando wraps mysqldump met de credentials uit wp-config.php, dus je hoeft geen los MySQL-wachtwoord bij te houden.

Vereisten:

• WP-CLI 2.10 of nieuwer geïnstalleerd op de server (wp --info om te controleren).
• SSH of lokale shell-toegang tot de WordPress-root.
• Een doelmap voor backups buiten de webroot, zodat een aanvaller met schrijfrechten in WordPress ze niet kan verwijderen. /home/deploy/backups/ is een gangbare keuze op een single-tenant server.

Stappen:

1. SSH naar de server en cd naar de WordPress-root (de map waarin wp-config.php staat).

2. Exporteer de database naar een gezipt SQL-bestand met datum:

   # Exporteer de volledige database naar een gzipped SQL-bestand met datum.
   # --add-drop-table zorgt dat de dump ook over een bestaande database hersteld kan worden.
   wp db export - --add-drop-table | gzip > /home/deploy/backups/db-$(date +%F).sql.gz

3. Archiveer de WordPress-bestanden. wp-content is de enige map die data bevat die je niet opnieuw kunt installeren, maar wp-config.php en .htaccess meenemen maakt de restore schoner:

   # Tar de hele WordPress-boom, zonder caches en de backup-map zelf.
   tar -czf /home/deploy/backups/files-$(date +%F).tar.gz \
     --exclude='wp-content/cache' \
     --exclude='wp-content/uploads/cache' \
     --exclude='.git' \
     wp-content wp-config.php .htaccess 2>/dev/null

4. Push de archieven naar een offsite bestemming. Met de AWS CLI naar Amazon S3:

   # Upload beide backup-bestanden naar een S3-bucket in de opgegeven regio.
   # Vereist aws configure of IAM role credentials.
   aws s3 cp /home/deploy/backups/db-$(date +%F).sql.gz s3://my-wp-backups/yoursite/
   aws s3 cp /home/deploy/backups/files-$(date +%F).tar.gz s3://my-wp-backups/yoursite/

5. Wikkel de hele reeks in een shell-script en plan hem in met cron. Een redelijke cron-regel voor een nachtelijke backup om 02:30 is:

   # m h dom mon dow command
   30 2 * * * /home/deploy/scripts/wp-backup.sh >> /home/deploy/logs/wp-backup.log 2>&1

Verwachte uitvoer: De databasedump comprimeert meestal tot 10–30 procent van de ruwe SQL-grootte voor typische WordPress-content. Een site met een 200 MB database levert een gzipped dump van 20–60 MB op. Het bestandsarchief varieert meer omdat het afhangt van de uploads-map. Beide bestanden horen na de upload zichtbaar te zijn in de S3-bucket, met de verwachte groottes en de datum van vandaag. Schrijf de groottes de eerste week ergens op en houd het verloop in de gaten; een plotselinge daling betekent meestal dat de backup stuk is.

Verificatie van het eindresultaat: Draai het script één keer handmatig en bekijk de uitvoer. Wacht dan op de volgende cron-run en controleer de S3-bucket. Pak daarna één van de archieven uit in een scratchmap (tar -tzf files-2026-04-08.tar.gz | head en zcat db-2026-04-08.sql.gz | head -50) om te bewijzen dat de archieven niet leeg of corrupt zijn.

Je backup testen door hem terug te zetten

Dit is de sectie die de meeste guides overslaan en het is de sectie die een backup-strategie onderscheidt van een backup-gewoonte. Een backup die je nooit hebt teruggezet, is hoop, geen controle. Restore-oefeningen maken van hoop een controle.

De oefening. Kies een staging-omgeving die je mag slopen: een lokale Docker-installatie, een tweede WordPress op een test-subdomein, een DevKinsta of Local by Flywheel instance, of een wegwerp-VPS. Zet de eerste keer niet terug op productie. Zet terug op een wegwerp-omgeving. Daarna:

1. Kies je recentste backup uit de opslagbestemming.
2. Installeer een schone WordPress op de staging-omgeving met dezelfde PHP- en MySQL-versies als productie.
3. Zet eerst de databasedump terug: wp db import db-2026-04-08.sql.gz met WP-CLI, of via de UpdraftPlus Upload backup files flow gevolgd door Restore als je de plugin gebruikt.
4. Zet daarna de bestanden terug: pak wp-content/ uit het archief in de wp-content/ van de staging-WordPress, of gebruik de component-restore van UpdraftPlus.
5. Draai wp search-replace 'yoursite.nl' 'staging.yoursite.nl' --dry-run en dan zonder --dry-run om de URL's in de database aan te passen zodat de herstelde site werkt op de staging-URL. Sla dit niet over; geserialiseerde PHP in WordPress-options breekt als je URL's met een ruwe SQL-query probeert te vervangen.
6. Open de staging-site en klik door de homepage, een blogpost, het wp-admin dashboard en een plugin-instellingenpagina die je herkent. Als hij eruit ziet als productie, werkt de backup. Als er iets mist, zoek dan nu uit wat, niet tijdens een echt incident.
7. Klok hoe lang de hele procedure duurde. Schrijf het getal op. Dat is je recovery time voor deze backup-strategie. Als het langer is dan je kunt verdragen, is dat een probleem om nu op te lossen, niet tijdens een incident. Als de restore-drill een migratie naar een andere host inhoudt, staat de volledige procedure in WordPress verhuizen naar een nieuwe host.

Herhaal deze oefening elk kwartaal. Sites veranderen, plugins stoppen hun state op nieuwe plekken, en een oefening die vorig kwartaal werkte is geen bewijs dat je backups vandaag werken.

De absolute ondergrens: backup voor elke update

Als je niks anders uit dit artikel meeneemt, neem dan dit mee: maak een verse backup vlak voor elke plugin-, theme- of WordPress core-update. Niet die van gisteren. Niet de nachtelijke automatische backup. Een verse backup, vijf minuten voor de update, zodat je bij een kapotte update terug kunt naar de staat van dertig seconden voor de fout.

De WordPress upgrade guide vereist dit voor major core-upgrades en de logica is voor elke andere update dezelfde: zodra een plugin tijdens zijn upgrade-routine in de database heeft geschreven, kun je dat vaak niet meer ongedaan maken zonder een backup van voor de upgrade. Plugin A voegt een kolom toe aan zijn tabel. Plugin B hernoemt een optie. De functions.php van een custom theme crasht op PHP 8.3 terwijl hij op 8.2 werkte. Al die gevallen herstel je met een backup van vijf minuten eerder. Zonder zo'n backup ben je aan het debuggen op productie.

De gratis versie van UpdraftPlus doet dit niet automatisch; het is een betaalde feature genaamd Backup before update. De workaround op de gratis versie is om handmatig op Backup Now te klikken voor elke sessie waarin je updates doet. Voor sites met meer dan een handjevol plugins verdient de betaalde versie zich terug bij de eerste update die hij redt.

De WP 6.3 handmatige rollback-feature en de WP 6.6 auto-update rollback vangen alleen het specifieke subset updates dat tijdens de update zelf een PHP fatal error triggert. Ze vangen geen updates die schoon installeren en pas twee dagen later iets stukmaken. Ze vangen geen updates die database-schema's aanpassen op een manier die een volgende plugin breekt. Een backup vangt dat allemaal wel, en dat is de controle die je wil.

Mythes die beter kunnen sneuvelen

Een korte lijst met wijdverspreide overtuigingen die niet kloppen, en waarom niet.

"Mijn host maakt backups, dus ik zit goed." Je host heeft een laag, geen strategie. Je bepaalt de bewaartermijn niet zelf, je kiest niet hoe fijnmazig je herstelt, en je herstelt geen los bestand zonder een supportticket. De officiële WordPress docs zeggen expliciet dat geautomatiseerde backups aangevuld moeten worden met handmatige om "to guarantee that the process is working". Maak je eigen backup.

"De database is het enige dat telt." De database bevat je content, maar als je hem terugzet in een WordPress zonder je uploads is elke afbeelding op elke post kapot. Zonder je actieve theme lijkt de site nergens meer op. Zonder je plugins renderen de helft van je custom blocks als lege placeholders. Bestanden en database zijn één backup, geen twee prioriteiten.

"Backups in wp-content/backups/ zijn prima, want de site is betrouwbaar." Prima totdat het niet meer prima is. Elke compromittering die een aanvaller schrijfrechten geeft in wp-content/ geeft hem ook de mogelijkheid je backups te verwijderen. Elke host-failure die de server meeneemt, neemt de backups mee. De regel is simpel: backups staan ergens waar de site niet bij kan, en de site draait ergens waar de backups niet bij kunnen.

"WordPress 6.6 heeft rollback toegevoegd, dus backups heb ik niet meer nodig." WordPress 6.6 voegde rollback toe voor plugin-auto-updates die tijdens de installatie crashen met een PHP fatal error. Dat is een klein, specifiek vangnet. Het rollbackt geen succesvolle update die later toch iets breekt. Het herstelt geen verwijderde content. Het helpt niet na een compromittering. Een backup doet alle drie.

"Ik backup één keer per maand, dat is genoeg voor een kleine site." Genoeg als je een maand aan werk comfortabel met de hand kunt reconstrueren. Voor de meeste sites, zelfs rustige, komt een maand aan verdwenen reacties, veranderde plugin-instellingen, registraties van nieuwe gebruikers en kleine content-edits neer op meer werk dan de schrijver van het backup-schema had bedacht. Dagelijks voor actieve sites, wekelijks voor statische, en altijd voor een update.

Waar je verder kunt lezen

Nu je een backup-strategie hebt, zijn de logische vervolgvragen over het herstelpad en de bredere security-houding. Begin bij WordPress security hardening, dat bestandspermissies, 2FA, wp-config.php constants en de andere controls dekt die de kans verkleinen dat je een backup überhaupt nodig hebt. Als je dit artikel leest omdat een update je site al heeft gesloopt, staat het herstelpad in critical error on this website en white screen of death in WordPress, die er allebei van uitgaan dat je een backup hebt om op terug te vallen. Herstel je van een compromittering in plaats van een codefout, dan loopt het artikel over WordPress gehackt / malware-redirect opruimen de volledige incident response door, waarbij een schone pre-compromise backup het verschil maakt. (Eerder gelinkt: white screen of death in WordPress, die beide ervan uitgaan dat je een backup hebt om op terug te vallen.