Een WordPress backup is een kopie van alle bestanden en de database van je website. Je slaat deze gegevens op een veilige plek op, zodat je de site exact kunt herstellen als er iets misgaat door een foutieve update, een hack of een servercrash.
Technische werking
- De software scant je installatiemap op de server. Hierbij worden alle PHP-bestanden, thema’s en plugins verzameld in een archiefbestand.
- Er wordt een export gemaakt van de MySQL database. De software haalt alle tabellen met teksten, instellingen en gebruikersgegevens uit de database en zet dit om in een tekstbestand, meestal een .sql bestand.
- De verzamelde bestanden en de database-export worden gebundeld in een compressieformaat, zoals .zip of .tar.gz. Dit scheelt ruimte en maakt het verplaatsen van de data sneller.
- Het resulterende backupbestand wordt naar een gekozen locatie gestuurd. Dit kan de eigen server zijn, maar vaker is dat externe cloud opslag om risico’s te spreiden.
- De software legt een logboek aan van de actie. Zo weet je of de kopie volledig is gemaakt of dat er bestanden zijn overgeslagen door rechtenbeperkingen op de server.
Belangrijke begrippen
MySQL database
Hier staat alles wat niet in een fysiek bestand op de server staat. Denk aan je blogposts, productomschrijvingen en alle configuraties van je plugins. Zonder deze database is je site een lege huls.
Document root
De hoofdmap op je server waar alle WordPress-bestanden in staan, vaak de httpdocs map genoemd. Een goede backup pakt alles in deze map op, inclusief de wp-content map waar je afbeeldingen en uploads staan.
Incrementele backups
Een methode waarbij alleen de wijzigingen sinds de laatste volledige backup worden opgeslagen. Dit bespaart veel schijfruimte en tijd, maar maakt het herstelproces iets complexer omdat je de basisbackup plus alle kleine stapjes nodig hebt.
Dump exporteren
Het proces waarbij de database wordt omgezet in een leesbaar bestand. Dit is een belangrijke stap; zonder een correcte dump kun je de database niet terugzetten op een andere server.
Cloud opslag
Een externe locatie zoals Google Drive of Amazon S3. Het is onverstandig om je backups op dezelfde schijf als je website te bewaren, want als die schijf kapotgaat, ben je beide kopieën kwijt.
Praktijkvoorbeeld
Stel je voor dat example.nl een webshop is die een nieuwe plugin installeert om de verzendkosten te berekenen. Tijdens de activatie gaat er iets fout en krijgt elke bezoeker een kritieke foutmelding in beeld. De site is volledig onbereikbaar.
Je opent het control panel van de hosting of de backup plugin en zoekt naar de meest recente kopie van gisteravond. Je selecteert de database-export en het bestandspakket. Met één druk op de knop overschrijf je de huidige, defecte bestanden op de server met de gezonde versie van gisteren.
// Voorbeeld van een database-export regel in een .sql bestand:
INSERT INTO `wp_posts` (`ID`, `post_author`, `post_date`, `post_content`)
VALUES (123, 1, '2023-10-27 10:00:00', 'Dit is de tekst van mijn productpagina');
Binnen enkele minuten is example.nl weer online en zijn de foutieve instellingen van de nieuwe plugin volledig gewist.
Veelgemaakte fouten
- Backups op de eigen server bewaren. Als de hostingprovider een storing heeft of je account wordt geblokkeerd, heb je geen toegang tot je bestanden én je backups.
- Vertrouwen op de hostingbackup zonder controle. Veel hosts maken automatische kopieën, maar die zijn vaak bedoeld voor hun eigen herstel en niet voor jou als gebruiker. Soms zijn deze kopieën ook verouderd of incompleet.
- Alleen de database veiligstellen. De database bevat de teksten, maar je afbeeldingen en uploads staan in mappen op de server. Zonder die bestanden ziet je site er na een herstel uit als een skelet zonder huid.
- Geen test-restore uitvoeren. Een backup is pas echt een backup als je hebt bewezen dat hij werkt. Vaak wordt pas ontdekt dat een automatische backup al maanden faalt op het moment dat deze echt nodig is.
- Te grote bestanden via FTP uploaden. Bij zeer grote sites kan een handmatige backup via FTP halverwege afbreken. Hierdoor krijg je een corrupt bestand dat onbruikbaar is bij een crash.
Gebruik en afwegingen
Je gebruikt een volledige backup altijd voordat je een grote update uitvoert aan WordPress zelf of aan een zwaar thema. De afweging is hier simpel: het kost je vijf minuten extra tijd, maar het voorkomt urenlang stress als de site in elkaar stort.
Gebruik je realtime backups? Dat is alleen zinvol bij sites met een enorme hoeveelheid transacties of content die elke minuut verandert. Voor een gemiddelde zakelijke site is een dagelijkse of wekelijkse kopie meer dan voldoende.
Je gebruikt geen backup als je alleen een kleine tekstuele wijziging doet in een bestaand artikel. Dat is overkill en onnodig belastend voor je servercapaciteit.
Controlelijst voor werking
- Check de bestandsgrootte. Een backup van 0 KB of een bestand dat veel kleiner is dan de vorige, wijst direct op een fout tijdens het proces.
- Verifieer de locatie. Log in op je externe cloud opslag en controleer of het bestand daar daadwerkelijk staat en niet alleen in de plugin-interface wordt getoond.
- Sla een kopie lokaal op. Download af en toe handmatig een set bestanden naar je eigen computer. Zo ben je onafhankelijk van zowel je host als je cloudprovider.
- Voer een proefherstel uit. Zet een kopie van je site op een lokale testomgeving of een staging-site om te zien of de database en bestanden correct koppelen.
- Controleer de datumstempel. Kijk of de automatische planning nog steeds loopt en dat de laatste kopie niet ouder is dan de afgesproken termijn.
Koppel je backups aan een externe locatie zoals Google Drive of Amazon S3 om echt veilig te zijn.
Kijk nu in je WordPress dashboard of je laatste automatische backup daadwerkelijk is voltooid.
