Disaster recovery planning die een echte storing overleeft
Een disaster recovery plan is pas iets waard als het is teruggezet, geoefend en bijgewerkt. Deze pagina zegt wat er in zo’n plan hoort, hoe je een recovery time objective vaststelt en hoe disaster recovery zich verhoudt tot business continuity planning.
De vier grootheden waar een plan op staat
Wie deze vier per systeem kan invullen, heeft een plan. Wie dat niet kan, heeft een back-up.
Wat er in een disaster recovery plan staat
Een disaster recovery plan beschrijft hoe de IT terugkomt na uitval: welke systemen eerst, vanaf welke kopie, door wie, en hoe je weet dat het klaar is.
- Een lijst van systemen, op volgordeNiet alles hoeft tegelijk terug. Het plan zet de systemen in de volgorde waarin het werk ze nodig heeft, en die volgorde komt uit het bedrijf en niet uit de serverkast. Wat er niet in staat, komt later terug — en dat weet iedereen dan van tevoren.
- Per systeem een RTO en een RPOHoe lang het uit mag zijn en hoeveel werk er verloren mag gaan. Die twee bepalen wat de techniek moet kunnen; andersom werkt het niet. Een uur RPO vraagt om iets anders dan een nacht.
- Waar de kopie staat en hoe je erbij komtEen back-up die alleen bereikbaar is via het systeem dat plat ligt is geen back-up. Het plan noemt de plek, de manier om erbij te komen en wie de sleutels heeft — ook als het netwerk eruit is en niemand kan inloggen.
- Wie wat doet, met naam en telefoonnummerRollen in plaats van namen alleen, want mensen zijn met vakantie. Wie beslist dat er wordt overgeschakeld, wie de leverancier belt, wie de organisatie informeert. Op papier, want een intranet ligt er in dit scenario ook uit.
Hoe wij zo’n plan opbouwen
Vijf stappen, in deze volgorde. De eerste twee gaan over het bedrijf, de laatste drie over de techniek — andersom bouw je iets wat niemand nodig had.
Uitzoeken wat er stil valt
Welke processen staan stil als een systeem eruit ligt, en na hoe lang gaat dat pijn doen. Dat gesprek voeren we met de mensen die het werk doen en niet alleen met IT, want de afdeling die het hardst piept is niet altijd de afdeling die het eerst terug moet.
Per systeem een RTO en RPO vastleggen
We zetten de getallen naast wat ze kosten aan techniek en aan werk. Vrijwel altijd schuift er iets: een RTO van een uur klinkt goed tot je ziet wat ervoor nodig is, en dan blijkt vier uur voor de helft van de systemen prima.
De techniek erop inrichten
Onveranderbare back-ups, replicatie of uitwijk — wat past volgt uit de getallen hierboven. We richten het in en zorgen dat een besmet systeem de kopie niet mee kan nemen; dat is het scenario waar de meeste plannen op stuklopen.
Terugzetten, echt
Een herstel dat is uitgevoerd op een aparte omgeving, met de tijd erbij gemeten. Pas dan weet je of de RTO klopt. Bijna elke eerste keer levert een verrassing op — een certificaat, een licentie, een koppeling die niemand had opgeschreven.
Oefenen en bijhouden
Een keer per jaar de knop echt omzetten, en het plan bijwerken zodra er een systeem bij komt of afgaat. Een plan van twee jaar oud beschrijft een omgeving die er niet meer is, en dat merk je op het slechtste moment.
Disaster recovery en business continuity planning
Ze worden door elkaar gebruikt en het is niet hetzelfde. Business continuity planning gaat over doorwerken; disaster recovery gaat over de IT die daarvoor terug moet komen.
- Business continuity planning is brederEen BCP beschrijft hoe de organisatie doorgaat als er iets uitvalt: mensen, gebouwen, leveranciers, communicatie. Uitval van IT is daar één scenario in. Zonder BCP is een disaster recovery plan een technisch document zonder opdrachtgever.
- Disaster recovery is het IT-deelHet disaster recovery plan is het hoofdstuk dat zegt hoe de systemen terugkomen en hoe snel. Het krijgt zijn opdracht uit het BCP: daar staat welk proces hoe lang stil mag liggen, en daar volgt de RTO uit.
- De terugvaloptie zonder ITVoor de uren dat er niets draait: waar liggen de papieren orders, hoe blijven klanten bereikbaar, wie zegt wat. Dat hoort in het BCP en niet bij ons, maar wij vragen ernaar — want een RTO van acht uur is alleen acceptabel als er acht uur te overbruggen valt.
- Melden hoort erbijValt de organisatie onder NIS2, dan loopt er naast het herstel een klok voor de melding. Die twee door elkaar laten lopen kost tijd op het verkeerde moment; het plan zet ze daarom naast elkaar, met wie welke doet.
Wat wij doen, en wat bij jullie blijft
Continuïteit is geen product dat je inkoopt. Dit is de verdeling die wij waarmaken, en het deel dat bij de organisatie zelf hoort te blijven.
- Wat wij doenHet plan schrijven en onderhouden, de back-up en de uitwijk inrichten, het herstel uitvoeren en meten, en meedraaien in de oefening. In Nederland en België doen we het werk op locatie met eigen mensen; we besteden dat niet uit.
- Wat wij vastleggenWelke kopie waar staat, wanneer er voor het laatst is teruggezet en hoe lang dat duurde. Dat is het materiaal waar een auditor, een verzekeraar of een toezichthouder naar vraagt, en het is precies het deel dat er niet meer is als je het achteraf moet reconstrueren.
- Wat bij jullie blijftHet besluit om over te schakelen, en de afweging welk proces hoe lang stil mag liggen. Dat is een keuze over het bedrijf en niet over de techniek; wij rekenen door wat hij kost en wat hij oplevert.
- Wat niemand kan belovenDat er niets misgaat. Wat er wél kan is dat de uitval voorspelbaar verloopt: bekende volgorde, bekende tijd, bekende verantwoordelijkheden. Dat is het verschil tussen een incident en een crisis.
Werkt jullie herstel echt? De enige manier om daarachter te komen is het uitvoeren. Bel +31 85 060 9347 of mail info@itproposal.com en we lopen door wat er nu staat.
Verder lezen
De pagina’s uit dit cluster, en waar ze op aansluiten.
Vragen die we hierover krijgen
De vragen die het vaakst langskomen, kort beantwoord.
Wat is het verschil tussen een disaster recovery plan en een back-up?
Een back-up is een kopie van je gegevens. Een disaster recovery plan beschrijft hoe complete systemen daarmee terugkomen, in welke volgorde, binnen welke tijd en door wie. Een back-up zonder plan levert een kopie op waarvan niemand weet hoe lang het terugzetten duurt.
Hoe vaak moet een disaster recovery plan geoefend worden?
Minstens één keer per jaar de knop werkelijk omzetten, en daarnaast bijwerken bij elke wijziging die een systeem toevoegt of weghaalt. Een plan van twee jaar oud beschrijft een omgeving die er niet meer is, en dat merk je op het slechtste moment.
Kunnen jullie een disaster recovery plan maken voor een omgeving die iemand anders beheert?
Ja. We schrijven het plan, meten het herstel en oefenen mee, ook als het dagelijks beheer bij een andere partij ligt. Wat we dan wel vragen is toegang tot de feiten: welke kopieën er zijn, waar ze staan en wanneer er voor het laatst is teruggezet.
Valt continuïteit onder NIS2?
Continuïteit staat met zoveel woorden in de zorgplicht van de richtlijn, samen met de meldplicht die in uren wordt gerekend. Of jouw organisatie eronder valt is een juridische kwalificatie die wij niet maken; wat wij leveren is de techniek en de vastlegging waar zo’n oordeel op rust.
Weten of jullie plan houdt?
Vertel wat er draait en wat er nu geregeld is. We lopen de systemen langs, zetten er RTO’s en RPO’s naast en zeggen welke er niet gehaald worden — voordat een storing het zegt.
Praktische IT-kennis in je inbox
Nieuwe gidsen over beheer, beveiliging en de werkplek, geschreven door de mensen die het werk doen. Geen verkooppraat, en afmelden kan met één klik.