Wanneer is een back-up eigenlijk geen back-up?
Je belt op een maandagochtend. Je website is weg. Of erger: hij staat er nog, maar iemand heeft er drie weken geleden rommel in gestopt en je hebt het pas nu door. Je hostingpartij zegt: "We hebben back-ups." En dan komt de zin die ik inmiddels te vaak heb gehoord: "Maar die staan op dezelfde server."
Op dat moment is een back-up geen back-up. Het is een kopie van een probleem.
De meest gemaakte fout: back-up op dezelfde plek als je website
Dit klinkt logisch als je het uitlegt, maar toch doet een groot deel van de goedkopere hostingpakketten het precies zo. Je back-up staat op hetzelfde systeem als je live website. Als die server crasht, gehackt wordt of fysiek kapotgaat, ben je alles tegelijk kwijt. Beide versies. In één klap.
Een externe back-up, op een apart systeem of locatie, is geen luxe. Het is het minimale dat telt.
Zonder hersteltest is het een aanname, geen zekerheid
Dit is de fout die ik het meest onderschat zie worden, ook door mensen die wél externe back-ups hebben. Ze nemen aan dat de back-up werkt. Ze hebben hem nooit teruggezet.
Ik snap de redenering: het voelt raar om iets te "kapotmaken" om te testen of je het kunt herstellen. Maar een back-up die je nooit hebt hersteld, is een belofte zonder bewijs. Bestanden kunnen corrupt zijn. De herstelomgeving kan veranderd zijn. De database-verbinding werkt misschien niet meer zoals verwacht. Je weet het pas als je het probeert, en je wil dat niet voor het eerst doen als het écht misgaat.
Bij Webplace4u testen we back-ups periodiek. Niet omdat we er lol in hebben, maar omdat je anders gewoon niet weet wat je hebt.
Hoe oud is je back-up eigenlijk?
Stel: je website wordt gehackt en de aanvaller heeft drie weken geleden al een achterdeurtje geïnstalleerd. Je back-up van gisteren bevat dat achterdeurtje ook. Die van eergisteren ook. En die van vorige week ook.
Dit is geen hypothetisch scenario. Malware op WordPress-sites zit vaak wekenlang slapend voordat er iets zichtbaars gebeurt. Als je dan terugzet naar "gisteren", zet je het probleem mee terug.
Meerdere herstelpunten over een langere periode, minimaal 30 dagen, zijn daarom geen overkill. Ze zijn het verschil tussen een werkende terugzet en een cirkel waar je niet uitkomt.
Wat je minimaal geregeld moet hebben
Geen ingewikkeld verhaal. Dit is wat werkt:
- ✓Dagelijkse back-ups, opgeslagen buiten je eigen server
- ✓Meerdere herstelpunten, minimaal 30 dagen terug
- ✓Een hersteltest, minimaal één keer per kwartaal
- ✓Weten wie je belt als het misgaat en hoe snel die persoon kan handelen
Dat laatste punt wordt onderschat. Een back-up zonder iemand die hem snel kan terugzetten, is technisch gezien compleet, maar praktisch gezien waardeloos als je webshop op een vrijdagmiddag plat ligt.
Wat dit in de praktijk kost
Goede back-upoplossingen zijn niet duur. In onze WordPress-hostingpakketten zit externe back-upopslag standaard inbegrepen, met dagelijkse snapshots en meerdere herstelpunten. Dat is geen extra optie die je moet aanvinken, het zit er gewoon in.
Wat het kost als je het niet hebt geregeld, is lastiger te begroten. Een paar uur downtime voor een webshop met €500 gemiddelde dagomzet is snel €200 verlies, plus de tijd die je kwijt bent aan uitzoeken wat er is misgaan, plus de reputatieschade als klanten een foutpagina zien.
Ik zeg dit niet om je bang te maken. Ik zeg het omdat ik het te vaak zie en het gewoon zonde is.
Wat Arjan zou doen als hij jou was
Check drie dingen. Eerst: waar staat je back-up fysiek? Als het antwoord "op dezelfde server als mijn site" is, los dat vandaag nog op. Tweede: wanneer is de back-up voor het laatst hersteld, ook al was het alleen een test? Als je het antwoord schuldbewust moet zoeken, is het te lang geleden. Derde: hoe ver terug kun je? Als het antwoord "24 uur" is, is dat voor de meeste aanvallen niet ver genoeg.
Als je dit uitzoekt en het klopt allemaal, prima. Dan heb je iets waar je rustig op kunt slapen. Als het niet klopt, weet je nu waarom dat gevoel van "ik heb toch een back-up" je vroeg of laat in de steek laat.