Een melding “back-up voltooid” zegt dat er een bestand is weggeschreven. Het zegt niet dat je site daaruit weer opstart, dat uploads meekomen of dat een formulier aankomt. Een back-up is pas bewezen wanneer je hem in een aparte omgeving herstelt en de functies controleert die je bedrijf nodig heeft. Doe die proef nooit over de live website heen.
Deze gids gaat over herstelbewijs, niet over een hostingwissel met DNS-omschakeling en niet over een onderhoudsabonnement. Download het invulbare herstelproefblad voordat je een omgeving verandert. Het werkvoorbeeld is fictief; er is geen klantsite hersteld.
1. Wat een herstelbare back-upset is
Voor een gebruikelijke WordPress-site horen bestanden en database bij elkaar. Thema’s, plugins, uploads, wp-config.php en .htaccess staan in de bestanden. Berichten, pagina’s, instellingen en veel plugin-gegevens staan in de database. Een mapkopie van alleen public_html bevat die database meestal niet. Een database-export zonder uploads mist afbeeldingen en bijlagen.
Behandel beide als één set: zelfde datum, zelfde label, bewaard buiten de omgeving die je wilt kunnen terugzetten. Officiële WordPress-documentatie raadt aan de database eerst te exporteren en daarna de bestanden, zodat de set bij elkaar past. Bij herstel is de gebruikelijke volgorde omgekeerd: eerst bestanden, daarna de database-import.
Noteer waar de set staat, hoe groot hij is en of je hem zonder de live server kunt openen. Een back-up die alleen op dezelfde schijf als de website ligt, valt samen met die website weg.
Zet geen wachtwoorden, tokens of databasegegevens in het CSV-blad. Verwijs naar de afgesproken veilige plek.
2. Kies een aparte omgeving, niet de live site
Herstel naar een bestemming die de productiesite niet overschrijft. Praktische opties zijn een lokale kopie op je computer, een extra database plus map bij dezelfde host, of een tijdelijke testlocatie die de uitvoerder daarvoor inricht. Het criterium is hetzelfde: de live URL, de live database en de live bestanden blijven onaangeraakt tot een later, apart besluit.
Een testkopie op een ander adres heeft eigen databasegegevens nodig. Als je de live wp-config.php ongewijzigd mee kopieert, wijst de testomgeving nog naar de live database. Dat is geen herstelproef; dat is een risico voor echte gegevens.
Scherm de testkopie af. Een noindex-instelling is geen toegangsbeveiliging. Voorkom dat de testkopie echte klanten mailt, betalingen verwerkt of dezelfde nachtelijk taak uitvoert als de live site. Gebruik testdestinations en testdata.
3. Herstel bestanden, daarna de database
Zet de bestanden in de lege testmap. Controleer dat thema, plugins en de uploadmap aanwezig zijn, niet alleen index.php. Importeer daarna de database-export in een nieuwe testdatabase. Een import in de live database maakt van de proef een productie-incident.
Mislukt de import, bewaar dan de volledige melding, de bestandsnaam van de export en het tijdstip. Een afgebroken import is geen “bijna geslaagde” back-up. Probeer niet het restant met de live tabellen te mengen.
Pas daarna de configuratie van de testkopie aan: databasenaam, gebruiker en wachtwoord van de testdatabase. Laat de live configuratie ongemoeid. Controleer dat je het live bestand niet per ongeluk hebt overschreven.
4. Laat de testkopie naar het testadres wijzen
Een herstelde WordPress-kopie bevat vaak nog de live site-URL in de database. Open je de testomgeving dan, dan kun je alsnog op de live site uitkomen of assets van de live site laden. Dat lijkt op een geslaagde proef terwijl je de back-up niet echt hebt gezien.
Pas siteurl en home van de testkopie aan naar het testadres, of gebruik een door de host ondersteunde previewmethode. Officiële migratiedocumentatie beschrijft die URL-wijziging juist om een kopie op een andere bestemming te laten werken. Doe dat in de testdatabase, niet in de live database.
Controleer daarna in de adresbalk dat je op het testadres zit. Sla een screenshot of URL met tijdstip op in het blad. Als de browser stilletjes naar het live domein springt, is de proef ongeldig.
5. Controleer gedrag, niet alleen de homepage
Kies vooraf de functies die aantoonbaar moeten werken. Een herstelde homepage bewijst niet dat het contactformulier, de media of de beheerlogin zijn meegekomen.
Praktisch startpunt voor een kleine zakelijke site:
| Test | Bewijs dat je bewaart | Reden om de back-up onbewezen te noemen |
|---|---|---|
| Homepage | URL van de testomgeving, tijdstip, herkenbare inhoud van de back-updatum | Lege pagina, installatiescherm of live URL |
| Bekende pagina of download | Bestand of tekst die je van tevoren hebt gekozen | Ontbrekende pagina of gebroken verwijzing |
| Beheerlogin | Bevoegde tester komt in de testkopie | Rechten of databaseklacht |
| Formulier | Testbericht komt op de testdestemming aan | Alleen een succesmelding, of live klanten gemaild |
| Media | Een bekend uploadbestand opent | Afbeeldingen ontbreken of wijzen naar live |
Vul in het CSV-herstelproefblad eigenaar, waarneming en open actie in. Open het als UTF-8 met komma als scheidingsteken als de kolommen niet vanzelf uit elkaar vallen.
6. Werkvoorbeeld: brochurewebsite van Atelier Noord
Stel: een fictief atelier heeft een WordPress-site met acht pagina’s, een contactformulier en een downloadbare brochure. Mailboxen staan bij een externe partij. De eigenaar bewaart wekelijks een map met bestanden en een SQL-export, allebei van zondagavond.
Op maandag zet de uitvoerder die set in een lokale testmap en een lege testdatabase. De live site blijft online. Na het aanpassen van de test-URL opent de homepage. De brochure ontbreekt: de uploadmap in de back-up is leeg. Het formulier toont een succesmelding, maar het testbericht komt niet aan omdat de testkopie nog de live maildienst zou gebruiken; die test wordt daarom niet live verstuurd en als niet aangetoond gemarkeerd.
Het blad krijgt de status back-up onbewezen: de database lijkt terug te komen, de media niet, de formulierketen is niet veilig getest. De eigenaar bewaart de live site en laat eerst een nieuwe, complete set maken. Dit is een tafeloefening, geen uitgevoerde klantrestore.
7. Stopmomenten en wat je niet bewijst
Stop de proef en raak de live site niet aan wanneer:
- de enige beschikbare back-up op dezelfde server staat als de website;
- niemand het verschil kent tussen bestanden en database;
- herstel alleen kan door de live map te overschrijven;
- de testkopie naar de live database of live URL wijst;
- een formulier- of betaaltest echte klanten zou bereiken.
Een geslaagde herstelproef bewijst die ene set, op dat moment, in die testomgeving. Het bewijst geen dagelijkse back-upkwaliteit, geen ransomwarebestendigheid en geen nul downtime. Hostingpanels, plugins en “één-klik-herstellen” kunnen helpen, maar vervangen deze acceptatie niet zolang je hun resultaat niet in een aparte kopie hebt gezien.
8. Leg het besluit vast en kies het vervolg
Wijs één persoon aan die zegt of de back-up herstelbaar is. Bewaar datum, gebruikte set, testadres en de uitkomst van elke functie. Ruim de testkopie daarna op of houd hem afgeschermd, zodat hij geen tweede live site wordt.
Is de proef nodig omdat je gaat verhuizen? Gebruik daarna de gids website verhuizen naar andere hosting. Die gaat over DNS, mailgrenzen en omschakelen; deze pagina blijft de herstelproef. Blijkt dat niemand eigenaar is van back-ups en controles, dan helpt websiteonderhoud en de kosten daarvan om die taak af te bakenen, zonder dat dit blad een abonnement wordt. De scorekaart voor een professionele website helpt als je daarna de kwaliteit van de hele site wilt beoordelen.
Wil je de site zelf vervangen in plaats van een kopie te bewijzen? Dat is een ander besluit. De pagina website laten maken beschrijft die opdracht. Een herstelproef is daarmee niet inbegrepen.