WordPress herstellen vanaf een backup

Een WordPress-site terugzetten vanaf een backup zoals het hoort: matchende bestanden en database, de officiële restore-volgorde, drie werkende methodes (hostingpaneel, UpdraftPlus, WP-CLI/SSH), en de WooCommerce HPOS-regels die de meeste shop-eigenaren verrassen.

De site is kapot en je hebt een backup. Vanaf hier is het werk: de juiste dingen in de juiste volgorde terugzetten, bewijzen dat de restore werkt, en onderweg geen nieuwe data verliezen. Er zijn drie werkende routes: via je hostingpaneel, via UpdraftPlus in het dashboard, of met de hand over SSH met WP-CLI. Dit artikel loopt ze alle drie door, plus de WooCommerce HPOS-regels die de meeste shop-eigenaren verrassen, en de checks na afloop die het verschil maken tussen "de pagina laadt" en "de site werkt echt".

Als je hier bent omdat je herstelt na een hack en niet na een mislukte update, is een restore maar één stuk van het verhaal. De volledige hack-recovery procedure staat in WordPress gehackt: een malware-redirect herkennen en opruimen. Lees dat artikel eerst, en kom dan terug voor de restore-mechaniek. Alleen de database terugzetten na een compromittering is geen herstel; de backdoors zitten in de bestanden en herinfecteren de site binnen een paar uur.

Voor je begint: weet wat voor backup je hebt

Een WordPress-backup bestaat uit twee dingen: een SQL-dump van de database, en een archief van de bestanden. De officiële WordPress backup-documentatie zegt het zonder omhaal: een filesystem-backup bevat geen database, en andersom. Open je backup en bevestig dat ze er allebei zijn voordat je verder gaat.

Wat je zoekt zijn twee artefacten:

Een SQL-dump, meestal met een naam zoals db-2026-04-07.sql, backup_2026-04-07_sitename_hash-db.gz of een .sql.bz2 bestand. Iets tussen een paar megabyte en een paar honderd is normaal.
Een bestandsarchief, meestal een .zip of .tar.gz. Het moet minimaal wp-content/ bevatten (themes, plugins, uploads, mu-plugins). Als WordPress core en wp-config.php er ook in zitten: nog beter.

Twee checks voor je verder gaat:

Bestanden en database moeten van hetzelfde moment komen. De database van vannacht terugzetten in de bestanden van gisterochtend (of andersom) levert een site op waar plugin-tabellen verwijzen naar plugins die niet meer bestaan, of order-rijen naar orders die nog niet geplaatst zijn. Altijd terugzetten vanuit één matchende set.
De WordPress-versie op disk moet kloppen met wat de database verwacht. Als je backup van voor een major core-upgrade is, heb je de bijbehorende WordPress-core erbij nodig. Een 6.7-database in een 6.5-installatie (of andersom) gooien levert je een "WordPress database update required"-loop op die je dan ook nog mag debuggen.

Als er iets ontbreekt in de set, stop dan en zoek een complete backup voordat je verdergaat. Een halve restore creëert problemen die langer duren om op te ruimen dan het oorspronkelijke incident.

Herstellen via je hostingpaneel

Dit is de snelste route als je host de backup heeft gemaakt en je de hele site wil terugdraaien naar een recente snapshot. De control panel-restore is in de meeste gevallen atomair: bestanden en database gaan samen terug, naar hetzelfde moment, in één klik.

Het exacte pad hangt af van je host:

cPanel met JetBackup: Files > JetBackup > Full Account Backups, kies een snapshot, klik Restore. Voor een gedeeltelijke restore heeft dezelfde JetBackup-interface losse tabs voor Files, Databases en Home Directory.
Plesk: Websites & Domains > Backup & Restore, kies de backup, kies "All objects (entire system)" of "Selected objects" als je alleen de WordPress-site wil, en draai.
WP Toolkit op Plesk: open de WordPress-installatie in WP Toolkit, klik Backup/Restore, kies een snapshot, klik Restore. De Plesk WP Toolkit-documentatie loopt de exacte flow door, inclusief wat wel en niet in een WP Toolkit-backup zit.
Managed WordPress-hosts (Kinsta, WP Engine, SiteGround): een Backups-tab in het site-dashboard, een lijst met snapshots, een Restore-knop. Sommige hosts zetten restore op goedkopere plannen achter een supportticket.

De eerlijke beperking van deze route: je herstelt naar de snapshot van de host, op het schema van de host, met de bewaartermijn van de host. Als de slechte verandering 40 dagen geleden gebeurde en je host bewaart 30 dagen, kan het paneel je niet helpen. Dat is precies het gat dat je eigen off-host backup hoort te vullen. Weet je niet zeker wanneer het probleem begon? Zet eerst terug op een staging-omgeving, controleer of de snapshot schoon is, en push pas dan naar productie.

Als het paneel "restore voltooid" zegt, ga door naar Post-restore checks. Ga er niet vanuit dat de pagina laden betekent dat de site werkt.

Herstellen via UpdraftPlus (eerst bestanden, daarna database)

UpdraftPlus is de meest geïnstalleerde backup-plugin in de WordPress-directory en de realistische keuze voor de meeste mensen die een klikbare restore willen. De plugin handelt de volgorde automatisch af en de TeamUpdraft restore-documentatie loopt de UI in detail door. Eén ding om zuiver over te zijn: de interne volgorde van UpdraftPlus is eerst bestanden, daarna database, dus niet andersom. Het TeamUpdraft-team legt de reden simpel uit: "By migrating files first and the database last, UpdraftPlus minimises the risk of a failed restore or migration." Als de restore halverwege stukgaat, is "oude bestanden met een halve database" makkelijker te herstellen dan andersom.

Vereisten:

WordPress is bereikbaar via het dashboard. Zo niet, spring direct naar de handmatige restore-sectie.
UpdraftPlus is geïnstalleerd en actief (dezelfde versie of nieuwer dan de versie waarmee de backup is gemaakt).
De backup-bestanden staan al op de remote storage die je hebt ingesteld (Google Drive, Dropbox, S3, enz.) of je hebt ze op je laptop en kunt ze uploaden.
Een PHP memory_limit van minstens 512MB en max_execution_time van minstens 900 seconden. Het TeamUpdraft-team noemt deze als de aanbevolen minima voor stabiele restores, en lagere waarden zijn de meest voorkomende oorzaak van restores die halverwege sterven.
Een uur waarin niemand anders aan de site zit.

Stappen:

Zet de site eerst offline, of in elk geval in maintenance mode. Een lopende restore op een live site is een open raam voor nieuwe orders, reacties of registraties die de restore stilletjes overschrijft.
Ga naar Instellingen > UpdraftPlus Backups > Existing Backups. Staat je backup op remote storage, klik dan op Rescan remote storage zodat UpdraftPlus hem oppakt. Heb je de bestanden op je laptop, klik op Upload backup files en sleep de vijf UpdraftPlus-archieven (-db.gz, -plugins.zip, -themes.zip, -uploads.zip, -others.zip) in het uploadveld.
Zoek de regel van de snapshot die je wil hebben en klik op Restore.
Vink in het dialoogvenster de componenten aan die je wil terugzetten. Voor een volledige restore: Plugins, Themes, Uploads, Others en Database. Voor "de database van vanochtend is corrupt maar de bestanden zijn prima": alleen Database. Voor "ik heb een plugin verwijderd en wil hem terug": alleen Plugins.
Klik op Next. UpdraftPlus haalt de bestanden op van remote storage als ze er nog niet lokaal zijn, pakt ze uit en valideert ze. Deze stap kan een paar minuten duren bij een uploads-archief van meerdere gigabytes.
Lees de waarschuwingen op het volgende scherm en klik dan nogmaals op Restore om te bevestigen. Het restore-log streamt in de browser. Sluit het tabblad niet.
Houd het log in de gaten. UpdraftPlus draait elk component op volgorde: plugins, themes, uploads, others, dan database. Een geslaagde restore eindigt met een groene Restore successful! melding.

Verwachte uitvoer: Het log toont per component voortgangsregels. Een typische regel ziet er uit als Files have been successfully copied into the original location, gevolgd door Restoring with backup set timestamp 1712534400. De laatste regel is Restore successful! Actions: Return to UpdraftPlus configuration.

Als de restore halverwege sterft: Dit is een gedocumenteerde failure mode en de oorzaak is bijna altijd een te lage PHP max_execution_time, een out-of-memory die het proces afschiet, of een Cloudflare/webserver-proxy timeout (HTTP 524) die de verbinding kapt terwijl de restore op de server gewoon nog draait. De restore-troubleshooting pagina van TeamUpdraft zet de mitigaties op een rij. De meest betrouwbare oplossing als je de PHP-limieten niet kunt verhogen: start de restore opnieuw, maar kies één component tegelijk. Eerst alleen Plugins. Dan alleen Themes. Dan Uploads. Dan Others. Dan Database. Elke request blijft ruim onder de tijdslimiet en de restore loopt stuk voor stuk door.

Verificatie van het eindresultaat: Als het log Restore successful! toont, ga je terug naar het WordPress-dashboard, hard-refresh, en spring je door naar Post-restore checks. Eén belangrijke kanttekening die de TeamUpdraft-docs expliciet noemen: "UpdraftPlus only backs up what is specific to your site: database, media, plugins and themes. It does not back up [WordPress core] files." Met andere woorden: een UpdraftPlus-restore is geen herinstall van WordPress core. Als je core-mappen (wp-admin/, wp-includes/) corrupt of weg zijn, moet je daarnaast nog een verse kopie van WordPress core op de site zetten, en dat doet UpdraftPlus niet voor je.

Handmatige restore: database importeren met WP-CLI of mysql

Dit is de meest betrouwbare route voor developers met SSH-toegang, en de enige werkbare route als het WordPress-dashboard onbereikbaar is. Geen PHP-tijdslimieten waar je tegen vecht; MySQL handelt de import direct af.

De officiële restore-volgorde uit de WordPress Advanced Administration backup-guide is eerst bestanden, dan database. Die volgorde doet ertoe omdat de database verwijst naar plugins, themes en uploads die op disk moeten staan voordat WordPress ze probeert te laden.

Vereisten:

SSH-toegang tot de server, met schrijfrechten in de WordPress-root.
WP-CLI 2.10 of nieuwer geïnstalleerd op de server (wp --info om te checken). Heb je geen WP-CLI, dan werken dezelfde stappen met de mysql-client direct; allebei staan hieronder.
MySQL- of MariaDB-credentials die overeenkomen met wat wp-config.php verwacht. Zit wp-config.php in de backup, dan gaat dat automatisch. Zo niet, dan moet je DB_NAME, DB_USER en DB_PASSWORD weten.
De backup-bestanden naar de server overgezet. scp, rsync of ophalen vanaf S3 met aws s3 cp is allemaal prima.

Stap 1: importeer de database met WP-CLI

Het WP-CLI wp db import commando leest credentials uit wp-config.php, gooit de dump in de database en is voor de meeste gevallen de makkelijkste route. Draai vanuit de WordPress-root:

# Importeer een ongecomprimeerde SQL-dump met de credentials uit wp-config.php.
wp db import /home/deploy/restores/db-2026-04-07.sql

Voor een gzipped dump pipe je hem door gunzip en geef je - mee om van STDIN te lezen:

# Decomprimeer on the fly en importeer via STDIN.
gunzip < /home/deploy/restores/db-2026-04-07.sql.gz | wp db import -

Een paar feiten om zuiver over te zijn. Het commando maakt de database niet aan; het verwacht dat de database die in wp-config.php staat al bestaat. Standaard past WP-CLI optimalisaties toe (auto-commit en key checks uitzetten) die grote imports flink versnellen. De vlag --skip-optimization zet die uit en is zelden nodig. Loop je tijdens een grote restore tegen een specifiek compatibility-probleem aan, probeer hem dan.

Verwachte uitvoer: Eén korte status-regel per bestand: Success: Imported from '/home/deploy/restores/db-2026-04-07.sql'. Dat is de enige succes-indicator. Print WP-CLI iets anders, beschouw het dan als een fout en lees de melding voordat je verdergaat.

Stap 2 (grote databases): mysql direct met max_allowed_packet

Voor heel grote dumps waar WP-CLI tegen een max_allowed_packet-plafond loopt of waar je een progress indicator wil, val je terug op de mysql-client. De MySQL packet-too-large reference legt het uit; het praktische commando is:

# Restore een grote dump met een expliciete packet size override.
mysql -u DB_USER -p DB_NAME --max_allowed_packet=256M < /home/deploy/restores/db-2026-04-07.sql

Of met een progress bar via pv (pipe viewer):

# Toon MB/s en percentage tijdens het terugzetten van een gecomprimeerde dump.
pv /home/deploy/restores/db-2026-04-07.sql.gz | gunzip | mysql -u DB_USER -p DB_NAME

De default voor max_allowed_packet in MySQL 8.4 is 64 MB. Als één rij in je dump groter is (een lange wp_posts.post_content, een geserialiseerde option-blob, één grote WooCommerce-order met een lange itemlijst), valt de restore om met ERROR 1153 (08S01): Got a packet bigger than 'max_allowed_packet' bytes. Hem ophogen naar 256 MB of meer aan de client-kant lost het in vrijwel alle gevallen op. Als de server-kant ook laag staat, zet max_allowed_packet=256M in de [mysqld]-sectie van my.cnf en herstart MySQL.

Voor dumps die over meerdere per-tabel SQL-bestanden zijn gesplitst (de export-stijl van sommige mysqldump-configuraties), loop je er gewoon doorheen in de shell:

# Importeer een map met per-tabel SQL-bestanden in alfabetische volgorde.
for DUMP in /home/deploy/restores/sql/*.sql; do
  wp db import "${DUMP}"
done

Geen SSH en het dashboard ligt eruit? Dan is BigDump de klassieke browser-based chunked importer voor heel grote dumps. Behandel hem als laatste redmiddel, niet als standaard.

Handmatige restore: wp-content terugzetten via SSH/rsync/FTP

De file-restore is rechttoe rechtaan, maar de volgorde doet ertoe. Zet de bestanden voor de database terug, zodat als WordPress straks weer laadt, elke plugin en elk theme waar de database naar verwijst ook echt op disk staat.

Stappen:

Zet de site offline. De simpelste manier over SSH: een maintenance.html in de webroot zetten en een .htaccess rewrite toevoegen, of de site via het host-paneel in maintenance mode zetten.
cd naar de WordPress-root (de map waar wp-config.php in staat).
Verplaats de bestaande wp-content/ opzij in plaats van hem te overschrijven. Je hebt hem misschien nog nodig voor forensics, vooral na een hack:
```
# Bewaar de huidige wp-content voor referentie voordat je hem vervangt.
mv wp-content wp-content.broken-2026-04-07
```

Pak het bestandsarchief uit. Voor een tar.gz:

# Pak het backup-archief uit in de WordPress-root.
tar -xzf /home/deploy/restores/files-2026-04-07.tar.gz

Voor een zip-archief (UpdraftPlus en veel host-backups):

# Pak elke UpdraftPlus-zip uit in de juiste bestemming.
unzip /home/deploy/restores/backup_2026-04-07-plugins.zip -d wp-content/
unzip /home/deploy/restores/backup_2026-04-07-themes.zip -d wp-content/
unzip /home/deploy/restores/backup_2026-04-07-uploads.zip -d wp-content/
unzip /home/deploy/restores/backup_2026-04-07-others.zip -d wp-content/

Zet ownership en permissies recht. De webserver-user (www-data, nginx, apache, of wat je host gebruikt) moet eigenaar zijn en de mappen moeten 755 zijn, bestanden 644:

# Herstel de standaard WordPress ownership en permissies.
chown -R www-data:www-data wp-content
find wp-content -type d -exec chmod 755 {} \;
find wp-content -type f -exec chmod 644 {} \;

Bevat de backup wp-config.php en zijn de database-credentials op deze host anders dan op de bron? Bewerk dan wp-config.php zodat hij klopt vóórdat je de database importeert. De officiële WordPress backup-guide noemt dit expliciet: als de database-credentials wijzigen, moet wp-config.php na de file-restore en vóór de database-import worden bijgewerkt.
Draai daarna de database-import uit de WP-CLI-sectie hierboven.

Verwachte uitvoer: Na de file-restore toont ls -la wp-content/ de verwachte mappen themes/, plugins/, uploads/ en mu-plugins/ met actuele timestamps. Na de database-import geeft wp option get siteurl de URL van de bron terug, en wp post list --format=count het aantal posts uit de backup.

Verificatie van het eindresultaat: Spring door naar Post-restore checks. Zet de site pas weer live als die checks slagen.

Een WooCommerce-site met HPOS terugzetten (de vier-tabellen-regel)

Sla deze sectie over als je geen WooCommerce draait. Doe je dat wel, dan is dit het verschil tussen een schone restore en een shop met corrupte orders waar je drie dagen later achter komt.

WooCommerce's High-Performance Order Storage (HPOS) is stabiel sinds WooCommerce 8.2 in oktober 2023 en is op recente WooCommerce-versies de default voor nieuwe installs. HPOS slaat orders op in vier custom tabellen in plaats van in wp_posts/wp_postmeta:

wp_wc_orders (hoofd-orderdata en veelgebruikte kolommen)
wp_wc_order_addresses (factuur- en verzendadressen)
wp_wc_order_operational_data (operationele waarden zoals cart hash en download permissions)
wp_wc_order_meta (extension- en custom meta)

Welke tabel autoritair is, wordt bepaald door de optie woocommerce_custom_orders_table_enabled in wp_options. Staat hij op true, dan zijn de vier wc_order* tabellen autoritair en zijn wp_posts/wp_postmeta sync-targets. Staat hij op false of ontbreekt hij, dan zijn de legacy-tabellen nog autoritair.

Er zijn drie restore-scenario's voor een WooCommerce-shop met HPOS:

Scenario 1: volledige database-restore. De hele database gaat terug, zowel de legacy-tabellen als de vier HPOS-tabellen, naar hetzelfde moment. Geen speciale actie nodig. Draai de restore zoals hierboven beschreven en ga door naar de verificatie.

Scenario 2: selectieve restore van alleen orders. Dit is de gevaarlijke. Als HPOS aan staat en je zet alleen de legacy wp_posts/wp_postmeta rijen voor orders terug, lopen de HPOS-tabellen uit de pas met de legacy-tabellen, en de shop leest uit HPOS, dus je herstelde orders zijn onzichtbaar. Je moet dan alle vier wc_order* tabellen terugzetten naast eventuele legacy order-data en daarna opnieuw syncen:

# Sync HPOS-tabellen opnieuw met de legacy-tabellen na een selectieve order-restore.
wp wc hpos sync
# Verifieer daarna dat beide kanten het over elke order eens zijn.
wp wc hpos verify_data --verbose

De WooCommerce HPOS CLI tools-documentatie beschrijft wat sync en verify_data precies doen. Behandel de verify-stap als verplicht, niet als optioneel.

Scenario 3: een backup terugzetten van vóór HPOS aan stond. Als je backup van vóór de HPOS-migratie is, bestaan de vier wc_order* tabellen niet (of zijn ze leeg) in de dump, en is woocommerce_custom_orders_table_enabled in de teruggezette wp_options false of afwezig. WooCommerce valt dan automatisch terug op legacy-mode. Daarna heb je een keuze: op legacy blijven en later opnieuw migreren naar HPOS, of HPOS opnieuw aanzetten via WooCommerce > Instellingen > Geavanceerd > Features en WooCommerce opnieuw laten migreren. HPOS opnieuw inschakelen triggert een verse sync vanuit de legacy-tabellen; reken op tijd bij een grote catalogus.

Waarom de verify_data-stap niet optioneel is: WooCommerce heeft de afgelopen periode gedocumenteerde HPOS sync-bugs gehad in de issue tracker, waaronder issue #53307 over metadata-verlies wanneer HPOS autoritair is en sync aan staat. Of die op jouw specifieke WooCommerce-versie volledig zijn opgelost, kan wp wc hpos verify_data in een paar seconden bevestigen en jij niet met het blote oog. Draai hem.

Post-restore checks

De pagina die laadt is niet hetzelfde als de site die werkt. Loop alle onderstaande checks af voordat je de site weer voor verkeer openzet.

Voorpagina en een diepere pagina: laad de homepage en daarna een blogpost of productpagina waarvan je weet dat hij voor het incident op de live site stond. Renderen ze allebei en bevatten ze content, dan praat de database goed met de bestanden.
Beelden renderen: open de voorpagina in een browser met DevTools, kijk in de Network-tab en bevestig dat geen enkele image-request 404 oplevert. Een veelvoorkomende failure na een restore: "de database komt uit een snapshot waar de uploads-map nog een maand aan extra bestanden bevatte die de teruggezette uploads-zip niet heeft".
wp-admin login: log in. Lukt dat niet, dan is de meest waarschijnlijke oorzaak een mismatch in wp_options.siteurl tussen de teruggezette database en de URL waar de site nu draait. Open phpMyAdmin vanuit je hostingpaneel, selecteer de WordPress-database, open de wp_options-tabel en zoek de rijen waar option_name gelijk is aan siteurl en home. Klopt de option_value niet met de URL waar de site nu op draait, pas dan beide rijen aan naar de juiste URL en sla op.

Heb je SSH-toegang? WP-CLI doet hetzelfde en verwerkt ook geserialiseerde data in plugin-opties, wat phpMyAdmin niet kan:
```
# Bevestig welke URL de database verwacht.
wp option get siteurl
wp option get home
# Kloppen ze niet, werk ze dan bij. Gebruik search-replace, geen ruwe SQL,
# want plugin-options bevatten vaak geserialiseerde PHP-arrays.
wp search-replace 'https://oude-url.example' 'https://nieuwe-url.example' --skip-columns=guid
```
Plugins en thema laden: in wp-admin > Plugins controleer je of elke plugin die je verwacht in de lijst staat en actief is. In wp-admin > Weergave > Thema's controleer je of het juiste thema actief is. Mist er een plugin, dan was de file-restore incompleet.
WooCommerce-orders: open WooCommerce > Bestellingen en bevestig dat de meest recente order de order is die je verwacht op basis van het backup-tijdstip. Draai je HPOS, draai dan ook nog één keer wp wc hpos verify_data en lees de output. Iets anders dan "all checks passed" is een probleem.
Permalinks: ga naar Instellingen > Permalinks en klik één keer op Wijzigingen opslaan zonder iets te veranderen. Dat herschrijft de .htaccess (Apache) of ververst de rewrite rules in de database (nginx) en lost een hele klasse van "de homepage werkt maar geen enkele andere URL doet het" failures op.
Stuur een test-e-mail: trigger een wachtwoord-reset of een WooCommerce test-transactional. E-mail-bezorging breekt makkelijk na een serverwissel, vooral als wp-config.php van een andere host is teruggezet. Komt er niks aan, dan is dat een apart probleem; daar hoort de WordPress e-mail-subcategorie bij.
Check het error log: klik een minuut door de site en open dan de error log-viewer in je hostingpaneel (cPanel: Metrics > Errors, Plesk: Websites & Domains > Logs). Alles wat er voor de restore niet stond, is iets om uit te zoeken voordat je live gaat. Heb je SSH-toegang? tail -100 /pad/naar/php-error.log geeft je hetzelfde beeld, maar sneller.

Als alle acht checks slagen, haal je de site uit maintenance mode. Houd het error log en de serverload in de gaten in het eerste uur na live; als er iets gaat breken, gebeurt dat meestal dan.

Als de restore halverwege strandt

Lees je deze sectie, dan hangt de restore, geeft hij een fout, of is hij klaar met waarschuwingen. De drie meest voorkomende oorzaken:

PHP max_execution_time op. Veruit de meest voorkomende UpdraftPlus-failure. De fix is de TeamUpdraft component-voor-component aanpak: in plaats van één restore die alles probeert, draai je vijf kleinere restores op een rij (Plugins, Themes, Uploads, Others, Database). Kun je php.ini of .htaccess zelf aanpassen, zet dan eerst max_execution_time op 900 en memory_limit op 512M. Capt je host die waarden en wil hij ze niet verhogen, val dan terug op SSH en gebruik de handmatige route; PHP-limieten gelden niet als MySQL de import direct doet.

Cloudflare- of proxy-524 timeout. Een 524 betekent dat de server nog werkt, maar dat de proxy ervoor wachten heeft opgegeven. De restore loopt op de server vaak nog steeds. Wacht het uit, controleer dan het UpdraftPlus-log en de database op nieuwe tabellen voordat je opnieuw begint. Zit de restore echt vast, dan helpt dezelfde component-voor-component fix hierboven meestal, omdat elke request binnen het proxy-timeout-window past.

max_allowed_packet te klein voor de dump. Dit duikt op tijdens de database-importfase als ERROR 1153 (08S01): Got a packet bigger than 'max_allowed_packet' bytes. Herstart de import met --max_allowed_packet=256M op de mysql-client (en hoog hem zo nodig ook server-side op). De MySQL packet-reference heeft de volledige uitleg.

De restore "lukte" maar de site is kapot. Dit is de vervelendste categorie omdat de fout stil is. Loop de acht post-restore checks hierboven op volgorde af. De eerste die faalt vertelt je waar je moet graven. De meest voorkomende stille failures: incomplete file-extractie (sommige plugins ontbreken omdat de unzip de schijf vol kreeg), URL-mismatch in wp_options, verkeerde file-permissies waardoor de webserver de uploads niet kan lezen, en HPOS uit sync na een gedeeltelijke database-restore.

Loop je vast, dan zijn dit de gegevens die je bij de hand wil hebben voordat je hulp vraagt: de exacte restore-methode (host panel, UpdraftPlus, handmatig SSH), de leeftijd en herkomst van de backup, de WordPress- en PHP-versies, de WooCommerce-versie als die relevant is, de laatste paar honderd regels van het PHP error log, en welke post-restore checks zijn gefaald en hoe. Met die informatie is de diagnose meestal kort. Zonder is het giswerk.

Ben je liever niet degene die dit om 02:00 uur zit te debuggen, dan beschrijft mijn artikel over WordPress backup-strategie hoe je een backup-aanpak inricht die restores routinematig in plaats van stressvol maakt, en het artikel WordPress gehackt: een malware-redirect herkennen en opruimen dekt het geval waarin de restore onderdeel is van een security-cleanup en niet van een update-rollback.

Wil je dat dit niet steeds jouw probleem is?

Als storingen blijven terugkomen, is de 'fix' vaak consistent beheer: updates, backups en monitoring die niet versloffen.

Bekijk WordPress onderhoud