Het moment waarop u een back-up nodig heeft, is zelden een rustig moment. De site is kapot na een update, er staat iets vreemds op de homepage, of een collega heeft per ongeluk twintig pagina’s verwijderd. U weet dat er ergens een back-up is. De vraag is alleen: hoe zet u die terug, en gaat daarbij niet nog meer verloren?
Een WordPress-back-up terugzetten is technisch niet ingewikkeld, maar er zijn een paar beslissingen die u vooraf moet nemen. Welke back-up? Alleen de bestanden of ook de database? En wat gebeurt er met alles wat sinds die back-up is veranderd? Dit stappenplan loopt door de drie gangbare manieren om te herstellen en de valkuilen die wij in de praktijk het vaakst tegenkomen.
Eerst: is terugzetten wel de juiste oplossing?
Een back-up terugzetten is een grove ingreep. Alles wat sinds het moment van de back-up is gebeurd, gaat verloren: nieuwe bestellingen, reacties, formulierinzendingen, tekstwijzigingen. Bij een bedrijfssite die eens per maand wordt aangepast, is dat meestal geen probleem. Bij een webshop met dagelijkse bestellingen kan het pijnlijk zijn.
Stel uzelf daarom eerst deze vragen. Is het probleem misschien met een kleinere ingreep op te lossen, bijvoorbeeld door één plugin uit te schakelen? Wanneer is de laatste back-up gemaakt, en wat is er sindsdien veranderd? Is het probleem een gevolg van een hack? In dat laatste geval is terugzetten alleen zinvol als de back-up van vóór de besmetting is, en zelfs dan blijft het lek dat de hack mogelijk maakte bestaan.
Bij twijfel: maak eerst een back-up van de kapotte situatie. Dat klinkt tegenstrijdig, maar zo kunt u later altijd nog gegevens terughalen die u anders kwijt zou zijn.
Manier 1: via uw back-upplugin
Gebruikt u een plugin als UpdraftPlus, BlogVault of een vergelijkbare oplossing, dan is dit meestal de eenvoudigste route, mits u nog in het beheer kunt inloggen.
- Ga naar de pagina van de back-upplugin en bekijk de lijst met beschikbare back-ups. Let op de datum en tijd.
- Kies de back-up van vlak vóór het probleem. Niet automatisch de nieuwste; die kan het probleem al bevatten.
- Kies wat u terugzet: plugins, thema’s, uploads, database, of alles. Bij een kapotte update volstaat vaak alleen de map met plugins of thema’s. Bij verwijderde pagina’s alleen de database.
- Start het herstel en wacht. Sluit het browservenster niet.
- Controleer daarna de site, leeg de cache en log opnieuw in.
Kunt u niet meer inloggen, dan valt deze route meestal af, tenzij de plugin een externe herstelfunctie heeft die buiten WordPress om werkt. Sommige betaalde diensten bieden dat.
Manier 2: via het hostingpaneel
Veel Nederlandse hostingpartijen maken dagelijkse snapshots en bieden in het klantenpaneel een knop om een eerdere versie terug te zetten. Dit werkt ook als WordPress zelf niet meer bereikbaar is, wat het een goed vangnet maakt.
Let hier op twee dingen. Ten eerste: een snapshot van de hosting zet vaak de complete webruimte terug, dus ook andere sites of mailinstellingen die daar staan. Lees goed wat er precies hersteld wordt. Ten tweede: hostingback-ups worden meestal een beperkte tijd bewaard, ruwweg een week tot een maand. Als het probleem al langer speelt, is de bruikbare versie er mogelijk niet meer.
Manier 3: handmatig, met bestanden en database
Dit is de route voor als u een losse back-up heeft (bijvoorbeeld een zip met bestanden en een .sql-bestand van de database) of als u een site verhuist. Het vraagt toegang via FTP of SFTP en tot phpMyAdmin of een vergelijkbaar databasehulpmiddel. In grote lijnen:
- Zet de bestanden terug in de webmap, met overschrijven van wat er staat.
- Importeer het databasebestand, na het legen van de bestaande database.
- Controleer wp-config.php: de databasenaam, gebruiker en het wachtwoord moeten kloppen met de huidige omgeving.
- Controleer of het domein in de database overeenkomt met het echte domein. Bij een herstel op dezelfde plek is dat zo; bij een verhuizing niet.
De meeste ondernemers laten dit liever door iemand doen die het vaker heeft gedaan. Eén verkeerde stap in de database en de site is er slechter aan toe dan ervoor.
De valkuilen die wij het vaakst zien
- Alleen de database terugzetten terwijl het probleem in de bestanden zit, of andersom. Weet wat u herstelt en waarom.
- De cache niet legen. Na het herstel ziet u de oude, kapotte versie nog en denkt u dat het niet gewerkt heeft.
- Een back-up terugzetten die zelf al besmet was. Na een hack is het belangrijk te weten wanneer de besmetting begon.
- Vergeten wat er sinds de back-up is gebeurd. Bij webshops verdwijnen zo bestellingen. Noteer vooraf wat u handmatig moet overnemen.
- Nooit getest of de back-up werkt. Een back-up die al maanden faalt, ontdekt u op het slechtst denkbare moment. Waarom de opslaglocatie daarbij ook meetelt, leest u in het artikel over back-ups buiten de server.
Een voorbeeld uit de praktijk
Een makelaar in Utrecht kreeg na een plugin-update een wit scherm. De hostingback-up van de nacht ervoor werd teruggezet, alles werkte weer. Wat over het hoofd was gezien: die ochtend waren er drie nieuwe woningen ingevoerd, die nu weg waren. Gelukkig was er wel een back-up van de kapotte situatie gemaakt, waaruit die drie objecten later alsnog konden worden teruggehaald. De les: eerst noteren wat er sinds de back-up is veranderd, dan pas herstellen.
Wie dit soort momenten liever niet zelf meemaakt, kan het herstellen onderbrengen bij een partij met een vast onderhoudsabonnement, waar back-ups vóór elke wijziging worden gemaakt en periodiek worden getest. WebMaintor werkt bijvoorbeeld zo, met versleutelde back-ups die binnen de EU worden bewaard.
Volgende stap
Zoek vandaag op waar uw back-ups staan, van wanneer de laatste is en hoe u hem zou terugzetten. Als u die drie vragen niet binnen vijf minuten kunt beantwoorden, is dat het eerste wat u regelt. Niet als de site kapot is, maar nu, terwijl alles nog werkt.
