July 9, 2021

Het best bewaarde geheim van Disaster Recovery

Natuurrampen, ongelukken, pandemie’s, ze gebeuren. Gelukkig zelden, maar kan je het risico uitsluiten? Als zo’n ramp zich voltrekt, dan heb je een zogenaamd noodherstelplan, ofwel ‘Disaster Recovery’ (DR) plan nodig om het werk weer (snel) te kunnen hervatten. Los daarvan is een noodherstelplan voor bepaalde branches, zoals financiële dienstverleners, verplicht vanuit wet- en regelgeving. Als er dan bijvoorbeeld een windhoos, zoals recent in Leersum, een hele regio ontregelt en je bent als organisatie niet voorbereid, dan kan dat leiden tot juridische en financiële consequenties.

Een voorbeeld ter illustratie:

Stel je voor, jouw organisatie biedt een aantal applicaties online beschikbaar aan. Uiteraard heeft het team de back-ups ingeregeld en is er een noodherstelplan (DR). Klaar om elk realistisch rampscenario aan te kunnen, en je voldoet aan alle compliance vereisten. Althans, dat denk je.

Een jaar later valt je primaire datacenter uit; de stroomtoevoer is onderbroken door wateroverlast en iemand is vergeten de generator bij te vullen. Tijd om je rampherstelstrategie uit te voeren. Je teamlead haalt het noodherstelplan tevoorschijn, hierin staat beschreven hoe jullie de back-ups dienen te restoren en de herstelfunctie in je infrastructuur moeten gebruiken om deze op een nieuwe locatie te herstellen.

Het begin gaat perfect want het herstelplan is beschikbaar omdat deze keurig buiten de productieomgeving opgeslagen is. Echter ineens voel je een stressgevoel opkomen, want: Welke expertisegebieden heb je eigenlijk allemaal nodig om het plan uit te voeren? Wanneer hebben we dit voor het laatst getest? Is het plan nog up-to-date? Hebben we mensen beschikbaar? En de benodigde toegangscodes? Al snel staan de juiste mensen paraat om de procedure uit te voeren. Gelukkig zijn er offside back-ups beschikbaar en staat er een omgeving klaar waar de back-ups op teruggelezen kunnen worden. Tot zover verloopt het volgens plan. Echter dan verschijnt de melding; ‘time remaining: 72 hours 18 minutes and 23 seconds’. Tja, we vonden een dag hersteltijd bij de implementatie acceptabel, echter de eisen omtrent beschikbaarheid zijn nogal toegenomen én de omgeving is ruim 3x zo groot geworden.

Uiteindelijk wordt alles op alles gezet, worden de meest elementaire onderdelen hersteld en staat de omgeving binnen 48 klaar voor gebruik. Maar, je raadt het al, het werkt niet. De database blijkt niet consistent geback-upt en na de herstelactie niet bruikbaar. Een van de vele dingen die mis kunnen gaan in een rampherstelscenario. Dit is het moment dat een team zich realiseert vergeten te zijn de belangrijkste regel van rampherstel te volgen:

Het hebben van een noodherstelplan (DR) dat niet regelmatig getest wordt is hetzelfde als het hebben van geen noodherstelplan.

Hoe ‘redundant’ jullie omgeving ook is, wat een derde partij mogelijk ook beweert dat hun oplossing voor je doet, zonder testen blijft het gissen. Het uitvoeren van een niet getest noodherstelplan zal in een echt rampscenario, in het meest gunstige geval, alleen maar heel erg lang duren. Succesvol snel online is zelden het eindresultaat. Voeg vervolgens de adrenaline van zo’n situatie toe aan de stress van een ramp scenario en het recept voor ellende is compleet. Met het investeren in het periodiek uitvoeren van noodherstelprocedures is enorm veel winst te behalen. Hierdoor wordt bijvoorbeeld inzichtelijk of inderdaad alle gegevens geback-upt worden. En of hetgeen geback-upt wordt inderdaad te herstellen is. En als het te herstellen is, of de data dan inderdaad bruikbaar is. Je team krijgt na iedere test meer vertrouwen in het proces, het draaiboek wordt steeds beter, het proces wordt sneller doorlopen en je bent niet afhankelijk van die ene super specialist.

Daarnaast weet je hoeveel tijd het duurt voordat de omgeving weer online is (Restore Time Objective: RTO) en hoeveel data er maximaal verloren gaat (Restore Point Objective: RPO) ten gevolge van een calamiteit (voor meer informatie over de RTO en RPO, zie onze blog.). Wij pretenderen niet dat de maximale tijd voor het uitvoeren van een noodherstelprocedure extreem kort dient te zijn of dat er geen data verloren mag gaan. Ons advies is te testen en op deze manier inzichtelijk te maken wat de impact van een calamiteit is. Aan de hand van deze gegevens kan er weloverwogen geconcludeerd worden of de noodherstelprocedure past binnen de door jouw organisatie gemaakte risicoafwegingen.

Download hier de whitepaper: RTO en RPO toepassingen voor maximale continuïteit en lees je in over belangrijke zaken zoals oplossingen die downtime voorkomen of tot een minimum beperken en vijf mogelijkheden om RTO en RPO te beheersen.

Verder is rouleren natuurlijk een goede tip. Dus, laat bijvoorbeeld ieder nieuw teamlid een DR uitvoeren, dan ben je er snel achter hoe goed het proces gedocumenteerd is en of het inderdaad overdraagbaar is. Ook het automatiseren van het testen van de herstelprocedure helpt enorm. Enerzijds geeft een geautomatiseerd proces een voorspelbaar resultaat, anderzijds helpt het de inspanningen die nodig zijn voor het testen aanzienlijk te verminderen. Ons advies is het proces voor een deel van de omgeving te automatiseren. Het controleren en afvinken of het geautomatiseerde proces goed verloopt én het actief uitvoeren van DR op het overige gedeelte van de omgeving blijft namelijk noodzakelijk om de vaardigheden van de teams actueel te houden. Daarnaast worden dan ook de laatste wijzigingen in de IT-omgeving in de test meegenomen en komen er, zo blijkt in de praktijk, toch altijd weer kansen naar boven om het proces verder te stroomlijnen. En ultieme automatisering en minimalisering van kansen op menselijke fouten is waar ons IT hart uiteindelijk altijd sneller van gaat kloppen ;-).

Graag een keer sparren over jullie specifieke disaster recovery plan en hoe daarin zoveel mogelijk geautomatiseerd kan worden? Stuur mij een bericht via LinkedIn.

In deze blog ‘estafette’ behandelen we de volgende keer ransomware en hoe je jezelf als organisatie ineens in een gijzeling bevindt; hoe werkte dat vroeger en hoe werkt dat nu?

Deel deze post
Merijn Plaisier
Merijn is Lead Engineer en tevens Partner bij ACC ICT. Merijn is vanaf 2010 werkzaam bij ACC ICT in verschillende rollen en maak je blij met de meest technische vraagstukken waar hij zich in vast kan bijten. Merijn schrijft graag over ontwikkelingen in de IT-branche.