Een WordPress back-up maken is één van die taken die je pas echt belangrijk vindt op het moment dat het misgaat. Een plugin-update die een fout introduceert, een gehackte website, een menselijke vergissing in de media-bibliotheek of een hostingmigratie die net anders uitpakt dan verwacht: het zijn allemaal scenario’s waarbij een goede back-up het verschil maakt tussen snel herstellen en dagenlang schade beperken. In dit artikel leggen we uit wat je precies moet veiligstellen, welke back-upstrategieën er zijn, hoe je de kwaliteit van je back-ups beoordeelt en hoe je dit praktisch organiseert voor zowel kleine websites als zakelijke omgevingen.
Waarom WordPress back-up maken geen “nice to have” is
WordPress is populair, flexibel en daardoor ook een regelmatig doelwit voor aanvallen en misconfiguraties. Daarbij zijn problemen niet altijd het gevolg van kwaadwillendheid. Een foutieve plugin, een themawijziging, een conflict tussen PHP-versies of per ongeluk verwijderen van content komt in de praktijk veel voor.
Een WordPress back-up maken helpt je om gecontroleerd terug te gaan naar een werkende situatie. Dat verkleint downtime, beperkt omzetverlies en voorkomt dat je onder druk riskante “quick fixes” uitvoert. Zeker bij websites die leads, bestellingen of klantportals verwerken, is herstelbaarheid een onderdeel van je bedrijfscontinuïteit.
Wat moet er in een WordPress back-up zitten?
Veel problemen ontstaan doordat mensen denken dat “de bestanden” of “de database” genoeg is. In werkelijkheid heb je beide nodig, en soms meer. Een WordPress back-up maken betekent in de basis dat je de site zo vastlegt dat je hem aantoonbaar kunt terugzetten.
1) Database: content, instellingen en gebruikers
De database bevat onder andere pagina’s en berichten, gebruikers, wachtwoordhashes, instellingen, menu’s, WooCommerce-orders, formulierinzendingen en vaak ook configuratie van plugins. Als je alleen bestanden back-upt maar je database ontbreekt of is verouderd, mis je cruciale content of transacties.
2) Bestanden: WordPress core, thema’s, plugins en uploads
De map met uploads bevat afbeeldingen, PDF’s en andere media. Thema’s en plugins bepalen functionaliteit en styling. Hoewel de WordPress core opnieuw te downloaden is, is het in herstelscenario’s vaak handig om een complete set te hebben die overeenkomt met jouw werkende versie, inclusief specifieke aanpassingen.
3) Configuratie en “omgeving” (nuance voor zakelijke sites)
Bij grotere sites spelen ook serverinstellingen, cachinglagen, cronjobs en omgevingsvariabelen mee. Je hoeft dat niet altijd in dezelfde back-up te stoppen, maar je wilt wel documenteren wat er nodig is om een herstel betrouwbaar te laten slagen. Denk ook aan API-keys en integraties: die wil je niet in een back-up “lekken”, maar je wilt ze wel kunnen reproduceren.
WordPress back-up maken: veelgebruikte strategieën (en wanneer je welke kiest)
Er is niet één perfecte methode. De beste aanpak hangt af van hoe vaak je site verandert, hoeveel risico je accepteert en hoe snel je moet kunnen herstellen. Hieronder de meest gangbare strategieën om een WordPress back-up maken structureel te regelen.
Volledige back-ups op vaste momenten
Dit is de klassieker: dagelijks, wekelijks of per maand een volledige export van database en bestanden. Voor een eenvoudige site die weinig wijzigt kan een wekelijkse volledige back-up voldoende zijn. Voor sites met orders of dagelijkse contentupdates is dagelijks logischer.
Incrementele back-ups (alleen wijzigingen)
Incrementeel betekent dat je na een eerste volledige back-up alleen de veranderingen opslaat. Dat scheelt opslagruimte en is vaak sneller. De keerzijde: herstel wordt afhankelijker van een keten van back-ups. In professionele omgevingen is dat prima, zolang je controle hebt op integriteit en retentie.
Database vaker, bestanden minder vaak
Een praktische middenweg: de database meerdere keren per dag, bestanden bijvoorbeeld dagelijks of wekelijks. Dat past goed bij websites waar vooral data verandert (orders, inzendingen, content) en het bestandssysteem relatief stabiel is.
Pre-change back-ups (voor updates en deployments)
Voor veel incidenten geldt: het ging mis tijdens een wijziging. Daarom is het verstandig om vóór plugin-updates, thema-aanpassingen of grote contentmigraties een extra herstelpunt te maken. Zo kun je sneller terug als er direct na de wijziging problemen ontstaan.
RPO en RTO: de zakelijke manier om WordPress back-up maken te onderbouwen
Als je een website zakelijk gebruikt, helpt het om back-ups niet te baseren op gevoel, maar op twee simpele begrippen:
-
RPO (Recovery Point Objective): hoeveel data mag je maximaal kwijt zijn? Als je RPO 4 uur is, moet je back-ups (of databaseback-ups) minstens elke 4 uur hebben.
-
RTO (Recovery Time Objective): hoe snel moet je weer online zijn? Een RTO van 1 uur vraagt om snelle restore-processen, vaak met staging of snapshots en duidelijke procedures.
Door RPO en RTO te bepalen, wordt WordPress back-up maken een beheersmaatregel in plaats van een losse “toolkeuze”.
Waar gaat het vaak mis bij WordPress back-ups?
In de praktijk zien we dat back-ups regelmatig bestaan, maar niet bruikbaar zijn. Dat komt meestal door één van deze oorzaken:
-
De back-up bevat alleen de database of alleen bestanden, waardoor een restore incompleet is.
-
De back-up draait “groen”, maar niemand test ooit een terugzetactie.
-
Back-ups staan op dezelfde server als de website. Bij een incident ben je dan alles tegelijk kwijt.
-
Onvoldoende retentie: je ontdekt pas na weken dat er al lang een probleem of malware aanwezig was, maar je hebt geen schone herstelpunten meer.
-
Te grote back-ups zonder opschoning: media, logbestanden of cache-mappen maken back-ups onnodig zwaar en instabiel.
WordPress back-up maken en security: denk ook aan integriteit en herstelbaarheid
Een back-up is niet alleen een kopie, maar een herstelmechanisme. Bij security-incidenten is de vraag: kun je terug naar een schone versie? En kun je aantonen dat je back-up niet is gemanipuleerd?
Daarom zijn deze aandachtspunten belangrijk:
-
Bewaar back-ups gescheiden van je productieomgeving, bij voorkeur met eigen toegangsrechten.
-
Werk met versleuteling tijdens transport en opslag als je back-ups gevoelige data bevatten.
-
Gebruik sterke accounts, MFA waar mogelijk en minimaliseer toegang tot back-upopslag.
-
Test restores periodiek in een afgeschermde omgeving, zodat je geen risico loopt op herinfectie of datalekken.
Wil je security-risico’s rondom webapplicaties beter begrijpen, dan is de OWASP Top 10 een goede, gezaghebbende basis voor veelvoorkomende webrisico’s die ook WordPress-sites kunnen raken. Zie OWASP Top 10.
Hoe vaak moet je een WordPress back-up maken?
De juiste frequentie hangt af van mutaties en impact. Een brochurewebsite die maandelijks wordt aangepast heeft een ander profiel dan een WooCommerce-shop met doorlopende orders. Toch kun je met een paar vuistregels ver komen:
-
Statische of weinig veranderende site: wekelijks volledige back-up en extra back-up vóór wijzigingen.
-
Contentgedreven site (blog, nieuws, leadgeneratie): dagelijks volledige back-up, database mogelijk vaker.
-
E-commerce of portals: dagelijks volledig plus database meerdere keren per dag, afhankelijk van ordervolume en RPO.
Let op dat “vaker” alleen nuttig is als je ook retentie, opslag en restore-tests op orde hebt. Anders krijg je vooral meer data, zonder meer zekerheid.
Retentie en versies: hoe lang bewaar je back-ups?
Retentie is de periode waarin je back-ups bewaart. Kort bewaren is riskant bij onopgemerkte problemen. Te lang bewaren zonder beleid maakt het onoverzichtelijk en duur. Een praktisch model is een combinatie van kort cyclisch en langere archivering, bijvoorbeeld:
-
Dagelijks: laatste 7 tot 14 dagen
-
Wekelijks: laatste 4 tot 8 weken
-
Maandelijks: laatste 6 tot 12 maanden (afhankelijk van compliance en behoefte)
Voor organisaties met bewaarplichten of privacyvereisten is het verstandig om ook te kijken naar dataminimalisatie: bewaar niet langer dan nodig, en zorg dat je back-ups dezelfde beveiligingsstandaard hebben als productiegegevens.
WordPress back-up maken met plugins, hostingtools of handmatig: een genuanceerde vergelijking
Er zijn grofweg drie routes. Welke past, hangt af van je technische team, de gewenste controle en je hersteldoelstellingen.
Back-up plugins
Plugins zijn toegankelijk en snel op te zetten. Ze zijn vaak geschikt voor kleine tot middelgrote sites en voor teams die vooral in WordPress zelf willen werken. Let wel op resourcegebruik: back-ups kunnen CPU, geheugen en schijfruimte belasten, vooral bij grote media-bibliotheken.
Back-ups via hostingplatform of beheeromgeving
Veel hostingomgevingen bieden vormen van back-ups of snapshots. Het voordeel is dat dit buiten WordPress om kan draaien, wat bij een gecompromitteerde WordPress-installatie kan helpen. De invulling verschilt per provider, dus check altijd: wat wordt er precies geback-upt, hoe lang, en hoe herstel je?
Handmatige back-ups en exports
Handmatig kan nuttig zijn voor eenmalige migraties of specifieke herstelpunten, maar is gevoelig voor menselijke fouten. Het is zelden de beste structurele oplossing, tenzij je het automatiseert via beheerprocessen. Voor zakelijke continuïteit is “handmatig en af en toe” meestal onvoldoende.
Testen van restores: de vergeten helft van WordPress back-up maken
Een back-up is pas waardevol als je hem kunt terugzetten. Restore-tests hoeven niet wekelijks, maar wél periodiek, en zeker na grote wijzigingen. In de praktijk kun je denken aan een kwartaaltest of halfjaarlijkse test, afhankelijk van de kritikaliteit.
Waar let je op tijdens zo’n test?
-
Komt de site echt online met dezelfde functionaliteit?
-
Werken formulieren, e-mailverzending en betalingen nog correct?
-
Klopt de content tot het verwachte herstelpunt (RPO)?
-
Zijn er geen onverwachte bijeffecten door versieverschillen in plugins of PHP?
WordPress back-up maken vóór een hostingmigratie of platformwijziging
Een migratie is een typisch moment waarop je een extra, gecontroleerd herstelpunt wilt. Niet omdat migraties per definitie misgaan, maar omdat er veel verandert: DNS, caching, certificaten, versies en soms padstructuren of permissies. Een goede back-up is dan je vangnet.
Daarnaast is het verstandig om ook je domein en DNS-instellingen zorgvuldig te beheren. Een onjuiste DNS-wijziging kan downtime veroorzaken, zelfs als je back-up perfect is. In dat soort trajecten helpt het als hosting en techniek goed op elkaar afgestemd zijn.
Hosting en performance: indirecte impact op back-ups
Back-ups draaien op dezelfde omgeving als je website, tenzij je ze extern uitvoert. Bij een krappe hostingomgeving kunnen back-ups zorgen voor time-outs, trage admin-ervaring of zelfs fouten in het back-upproces. Andersom geldt ook: een goed ingerichte omgeving kan back-ups voorspelbaarder maken.
Als je WordPress zakelijk inzet, is het logisch om hosting te kiezen die past bij groei, beheerbaarheid en stabiliteit. Meer lezen over onze aanpak en mogelijkheden kan via onze pagina over WordPress website hosting.
WordPress back-up maken in teams: rollen, verantwoordelijkheden en controle
In veel organisaties is onduidelijk wie eindverantwoordelijk is voor back-ups. Marketing beheert WordPress, IT beheert hosting, development doet deployments, en niemand “bezit” het back-upbeleid. Dat is precies waar risico ontstaat.
Een werkbare aanpak:
-
Wijs één eigenaar aan voor RPO en RTO: iemand die beslist wat acceptabel is.
-
Leg vast wie back-ups monitort en wie restores uitvoert.
-
Documenteer waar back-ups staan, welke retentie geldt en hoe je een herstel test.
-
Beperk toegang tot back-ups en log herstelacties, zeker bij gevoelige data.
Veelgestelde vragen
1) Hoe vaak moet ik een WordPress back-up maken voor een webshop?
Voor een webshop verandert de database vaak continu door orders, klantaccounts en voorraadmutaties. Daarom is het verstandig om vaker dan één keer per dag te back-uppen, in elk geval voor de database, afhankelijk van je RPO. Daarnaast wil je vóór updates of campagnes een extra herstelpunt, zodat je snel kunt terugdraaien als er direct iets misgaat.
2) Is een WordPress back-up maken met een plugin altijd voldoende?
Voor veel kleinere sites kan een plugin prima werken, mits je back-ups extern opslaat en periodiek een restore test. Bij grotere sites of strengere eisen kan een plugin alleen onvoldoende zijn, bijvoorbeeld door performance-impact of doordat je ook omgevingselementen buiten WordPress wilt afdekken. Kijk daarom naar je hersteldoel (RTO) en de hoeveelheid data die je mag verliezen (RPO), en kies dan de methode.
3) Wat is het verschil tussen een back-up en een snapshot?
Een back-up is meestal bedoeld als portable kopie die je los van de bron kunt bewaren en terugzetten. Een snapshot is vaak een punt-in-tijd vastlegging op platformniveau, die snel kan zijn maar soms minder geschikt is als langetermijnarchief of bij migraties. In de praktijk kunnen snapshots handig zijn voor snel herstel, terwijl back-ups beter zijn voor duurzame retentie en offsite opslag.
4) Hoe weet ik of mijn back-ups echt werken?
De enige betrouwbare manier is een hersteltest uitvoeren naar een aparte omgeving. Daarbij controleer je niet alleen of de site laadt, maar ook of kritieke processen werken, zoals formulieren, e-mail en transacties. Leg de resultaten vast, zodat je bij een incident niet hoeft te improviseren.
5) Moet ik ook mijn domein en DNS meenemen in een back-up?
DNS is geen onderdeel van je WordPress-installatie, maar wel essentieel voor bereikbaarheid. Bij incidenten of verhuizingen wil je weten welke DNS-records actief waren en waarom. Het is daarom slim om DNS-instellingen te documenteren of te exporteren waar mogelijk, zodat je bij herstel of migratie minder afhankelijk bent van geheugenwerk.
6) Wat zijn goede richtlijnen voor beveiliging van back-ups?
Zorg dat back-ups niet alleen op dezelfde server staan als je website en beperk wie erbij kan. Gebruik waar mogelijk versleuteling en sterke authenticatie, zeker als back-ups persoonsgegevens bevatten. Het NCSC biedt nuttige handvatten voor basismaatregelen rondom veilig beheer en incidentpreventie, zie NCSC basisprincipes van digitale weerbaarheid.
Praktische checklist: WordPress back-up maken zonder blinde vlekken
-
Check of je back-up zowel database als bestanden bevat.
-
Kies frequentie op basis van RPO en retentie op basis van detectietijd van problemen.
-
Bewaar back-ups offsite of gescheiden van productie.
-
Test restores periodiek in een afgeschermde omgeving.
-
Maak extra back-ups vóór updates, migraties en grote contentwijzigingen.
-
Documenteer DNS en externe koppelingen die nodig zijn voor volledig herstel.
WordPress back-up maken en toekomstbestendig hosten
Back-ups staan niet los van je hostingkeuze. Als je omgeving meegroeit met je website, wordt het makkelijker om back-ups betrouwbaar te laten draaien, wijzigingen gecontroleerd door te voeren en herstel te testen. Zeker als je meerdere sites beheert of afhankelijk bent van prestaties en uptime, loont het om hosting en beheer volwassen in te richten.
Werk je met WordPress en wil je een omgeving die past bij zakelijke eisen, dan kun je ook kijken naar onze WordPress hosting pagina voor achtergrond en opties.
Hulp nodig bij back-upbeleid, hersteltests of een verhuizing?
Als je serieus werk wilt maken van WordPress back-up maken, is het slim om niet alleen naar “een tool” te kijken, maar naar het hele plaatje: RPO, RTO, retentie, security, restore-tests en de hostingomgeving waar het op moet draaien. Daar helpen we je graag bij, op een manier die technisch klopt en tegelijk begrijpelijk blijft.
Neem contact met ons op en vertel kort hoe je site wordt gebruikt, hoe vaak er wijzigingen zijn en wat downtime je kost. Dan denken we met je mee over een praktische aanpak, of dat nu gaat om het aanscherpen van je back-upstrategie, het testen van restores, een veilige migratie of het verbeteren van je hostingopzet richting een schaalbare cloudomgeving.
