fbpx

Business Continuity & Disaster Recovery (deel 1)

Is uw IT omgeving goed voorbereid op een calamiteit? Een vaak gehoord tegenargument is dat bij een eventuele natuurramp of luchtvaartongeval “er wel andere dingen zijn om ons druk over te maken”. De recente grote stroomstoring en de uitval van het datacenter van ProRail laten echter zien dat we ook te maken kunnen hebben met minder zichtbare calamiteiten, waarbij de kans groter is dan men doet vermoeden.

In deze tweedelige blogserie zal getracht worden om duidelijkheid te creëren omtrent de onderwerpen Business Continuity (BC) en Disaster Recovery (DR). Het eerste deel zal in het teken staan van begripsbepaling en afbakening van de termen BC en DR. Door middel van een helikopterview wordt duidelijk hoe we deze begrippen het beste kunnen plaatsen in de organisatie. Het tweede deel zal concreet ingaan op bestaande oplossingen van twee bekende spelers binnen dit vakgebied, Microsoft en VMware.

Door: Attila Nickl van Nikelsberg

Maar laten we van start gaan met waar het uiteindelijk allemaal om te doen is. Met Business Continuity en Disaster Recovery is het zaak om goed voorbereid te zijn op verstorende gebeurtenissen. Het is echter zo dat 75 % van de organisaties niet of slecht voorbereid is op herstel van IT functionaliteit en dienstverlening in geval van een grote calamiteit of ramp. Verschillende andere statistieken geven daarnaast aan dat de kans op overleven van een bedrijf na een calamiteit of ramp snel afneemt naarmate er minder is nagedacht over BC/DR. Bewustwording van BC/DR is dus van essentieel belang en de eerste stap.

Binnen veel bedrijven zijn Business Continuity en Disaster Recovery wel een hot topic, maar tegelijkertijd ook een heet hangijzer. Er zijn hier verschillende (begrijpelijke) redenen voor aan te wijzen. Ten eerste is het zo dat BC/DR terminologie lastig te doorgronden is omdat definities vaak alle kanten uitwaaieren of juist overlappende betekenissen toegewezen krijgen. Zo komen verschillende mensen of organisaties tot verschillende begripsomschrijvingen wat de helderheid niet ten goede komt. Ten tweede is het zo dat bepalingen vanuit buitenaf door middel van wet- en regelgeving, richtlijnen of standaarden en normen soms onbekend, onduidelijk of gewoonweg niet aanwezig zijn. Tot slot zijn er de vele interne afspraken, aangegane verplichtingen en overeenkomsten (SLA’s) die invloed kunnen uitoefenen bij de invulling van BC/DR.

Als we naar de definitie van Business Continuity kijken zien we eigenlijk al snel dat Disaster Recovery een onderdeel is van Business Continuity. Dit vertaalt zich als volgt:

Business Continuity is een verzameling van standaarden en voorzorgsmaatregelen met als doel het voorkomen of minimaliseren van onderbreking in bedrijfskritische diensten. Business Continuity bestaat uit drie onderdelen:

  1. Resilience: het herstelvermogen en hoge beschikbaarheid op component of systeem niveau, door middel van redundantie of fout tolerantie.
  2. Recovery: het herstelproces inclusief procedures van bedrijfsdata op lokaal niveau, door middel van backup/restore.
  3. Contingency: het plannings- en herstelproces inclusief procedures van (kritische) bedrijfsdiensten op regionaal niveau na een calamiteit of ramp, door middel van Disaster Recovery.

Business Continuity kan zelf ook weer onder een groter organisatorisch geheel geplaatst worden, namelijk Governance, Risk en Compliance (GRC). Grafisch ziet de relatie tussen de verschillende processen er als volgt uit:

blog_tabel_1-GRC_BC_DR

Continuïteit van het bedrijf moet dus op meerdere niveaus en vanuit meerdere invalshoeken ingevuld worden. De technische invulling van Disaster Recovery is dus maar een onderdeel van een groter geheel en zeker niet allesomvattend. Het is juist van belang dat de organisatie leading is en blijft bij het bepalen van de inhoud van Business Continuity en daarmee Disaster Recovery.

De twee belangrijkste Disaster Recovery onderdelen die door de organisatie bepaald moeten worden zijn RPO en RTO. RPO staat voor Recovery Point Objective en geeft de maximale hoeveelheid dataverlies aan (uitgedrukt in tijd) die mag optreden bij een calamiteit of ramp. RTO staat voor Recovery Time Objective en geeft de maximale hersteltijd (downtime) aan waarbinnen bedrijfsdata of een bedrijfsdienst hersteld moet worden. Welke waarden gekozen worden hangt natuurlijk van de bedrijfskritische processen af en kan per bedrijfsonderdeel of bedrijfsdienst bepaald worden. Men kan zelfs zover gaan dat per bedrijfsapplicatie verschillende RPO en RTO waarden bepaald worden. Het uitvoeren van een Business Impact Analysis (BIA) helpt een bedrijf bij het maken van de juiste keuzes.

Nu we het groter geheel hebben geschetst zullen we in het tweede deel van deze blogserie dieper ingaan op specifieke Disaster Recovery oplossingen van twee belangrijke IT marktspelers, te weten Microsoft en VMware.