“Er worden iedere nacht back-ups gemaakt.”
Dat klinkt geruststellend. Toch blijven er een paar belangrijke vragen liggen. Wat zit er precies in die back-up? Hoe oud mogen de gegevens zijn wanneer je ze terugzet? En hoelang duurt het voordat de website weer bruikbaar is?
Een reservekopie hebben en een bedrijf weer aan het werk krijgen zijn twee verschillende dingen.
Begin bij wat je kunt missen
Stel dat een webshop om vier uur ’s middags uitvalt. De laatste bruikbare back-up is van twee uur ’s nachts.
Als je uitsluitend die kopie terugzet, ontbreken de wijzigingen van de tussenliggende veertien uur. Denk aan bestellingen, voorraadwijzigingen en nieuwe klantgegevens. Misschien kun je een deel uit andere systemen reconstrueren, maar dat moet wel onderdeel zijn van het plan.
Daarom begint een herstelplan met twee afspraken: hoeveel gegevensverlies is acceptabel en hoelang mag de dienst onbeschikbaar zijn?
Technisch worden die doelen RPO en RTO genoemd. AWS beschrijft ze als uitgangspunten die je op de behoeften van het bedrijf moet afstemmen. Het zijn doelen, geen garanties die automatisch bij een back-up horen. Bron: AWS over hersteldoelen.
Een persoonlijke blog en een drukke webshop hoeven dus niet hetzelfde herstelplan te hebben.
Controleer wat er werkelijk wordt bewaard
Bij WordPress bestaat een volledige back-up normaal gesproken uit zowel bestanden als de database. De database bevat onder meer berichten en instellingen. Afbeeldingen, thema’s en plugins zitten in de bestanden. Alleen de WordPress-map downloaden is daarom niet hetzelfde als de volledige website veiligstellen. Bron: WordPress over back-ups.
Vraag dus niet alleen óf er een back-up wordt gemaakt. Vraag ook welke onderdelen erin zitten en van welk moment ze zijn.
Denk daarnaast aan de afhankelijkheden buiten WordPress. Wie kan bij het domeinbeheer? Waar staan de instellingen van externe koppelingen? Is de benodigde toegang nog beschikbaar als de gebruikelijke beheeromgeving niet werkt?
Zet in een herstelplan waar bevoegde beheerders die informatie veilig kunnen vinden. Zet er geen losse wachtwoorden in.
Oefen het terugzetten
Een praktische eerste hersteltest is een back-up terugzetten in een afgeschermde testomgeving.
Controleer vervolgens niet alleen of de homepage opent. Kun je inloggen? Zijn afbeeldingen aanwezig? Kloppen recente gegevens? Werken de onderdelen waarvoor bezoekers naar de website komen?
Voorkom daarbij dat de testkopie echte klantmails verstuurt, betalingen uitvoert of opdrachten naar gekoppelde systemen doorzet. Een oefening moet geen tweede productieomgeving worden.
Leg vast hoelang het herstel duurde en welke stappen ontbraken. Daarmee wordt het plan concreter dan een document dat alleen beschrijft hoe het zou moeten gaan. Ook AWS benadrukt dat herstelprocedures regelmatig moeten worden getest tegen de afgesproken hersteldoelen. Bron: AWS over hersteltests.
Spreek af wie beslist
Bij een storing moet iemand bepalen welke herstelversie wordt gebruikt en wanneer de omgeving weer open kan.
Dat is niet altijd alleen een technische keuze. Een oudere kopie kan een fout oplossen, maar tegelijkertijd recent werk terugdraaien. Bij een webshop moeten mogelijk ook bestellingen en betaalgegevens worden vergeleken voordat de normale verwerking verdergaat.
Leg daarom vooraf vast wie het herstel uitvoert, wie de inhoud controleert en wie akkoord geeft op hervatting. Zorg ook voor een vervanger. Een plan dat afhankelijk is van één beschikbare persoon heeft een kwetsbaar punt.
Stel een betere vraag aan je beheerder
“Hebben we back-ups?” blijft een nuttige vraag.
Maar deze levert meer op: “Wanneer hebben we voor het laatst getest of we hiermee kunnen herstellen, en wat kwam daaruit?”
Het antwoord hoeft geen ingewikkeld rapport te zijn. Een testdatum, het gebruikte herstelpunt, de gemeten hersteltijd en een lijst met openstaande problemen geven al veel duidelijkheid.
Een back-up bewaart gegevens. Een herstelplan beschrijft hoe je daar weer een werkende website en een bruikbaar bedrijfsproces van maakt.