Door alle hedendaagse digitale criminaliteit, kun je wel zeggen dat een Disaster Recovery een verzekering is voor gebeurtenissen die je niet mee wilt maken. Om ervoor te zorgen dat jouw organisatie niet is onderverzekerd is het raadzaam om een Disaster Recovery Plan (DRP) te maken.
Bij het maken van een DRP zijn er eigenlijk slechts twee parameters waar alles om draait, te weten de RPO en de RTO.
Beide parameters beschrijven de doelen die je met het Disaster Recovery Plan wilt bereiken. Hierbij moet wel worden opgemerkt dat het jouw bedrijfsdoelen zijn. Met andere woorden, deze bedrijfsdoelen worden niet door de IT afdeling bepaald, maar zullen wel door de IT afdeling worden gerealiseerd.
Het is zeer belangrijk om periodiek, bijvoorbeeld jaarlijks, te beoordelen of de gekozen RPO en RTO nog steeds valide zijn.
Met het toenemend belang van informatietechnologie, is het aannemelijk dat de RPO en de RTO in de toekomst kleiner worden. Denk hierbij aan verlies van data dat steeds minder gewenst is, het online komen na een storing moet steeds sneller, enzovoorts. Daarnaast groeien IT omgevingen gestaag door.
Een DRP voor je omgeving kon vorig jaar, een RPO en RPO hebben die binnen de gekozen grenzen viel, maar door de groei van deze omgeving, kan het zomaar zijn dat het nu niet meer aansluit.
Nadenken over het DRP begint al bij het ontwerp van je omgeving. In het ontwerp zitten al randvoorwaarden die bepalen of de gekozen RPO en RTO haalbaar zijn.
Wij geven je een voorbeeld. In het verleden maakte vrijwel elke organisatie de back-up op tape.
In de situatie dat er een disaster optreedt, waarbij de tapes de basis vormen van het herstel, kun je al op voorhand een tijdlijn bepalen voor je Disaster Recovery.
De hoeveelheid data en de snelheid waarmee de data van de tape kan worden gehaald, bepalen de minimale tijd (RTO) die nodig is om de omgeving weer beschikbaar te maken.
Het moment waarop de tape gevuld is, ten opzichte van het moment van een disaster, bepaalt de RPO (de hoeveelheid data die de organisatie is kwijt geraakt).
De minimale RTO bereken je als volgt: aantal te herstellen GB gedeeld door GB/s herstelsnelheid. De uitkomst is de tijd die minimaal nodig is voor het herstel.
Vaak zijn daarna nog additionele acties nodig om de omgeving weer online te brengen.
Tapes zijn niet heel snel. In de huidige tijd zijn tapes, naar onze mening, dan ook niet meer een middel dat heel erg geschikt is voor een bijdrage aan Disaster Recovery. Bedenk eens wat de RPO doet als je éénmaal per dag een back-up naar een tape maakt en tijdens het maken van de back-up treedt er een disaster op. Dan moet je terug naar de tape van gisteren en dat betekent dat de RPO al minimaal 24 uur is.
Tegenwoordig bevat het ontwerp van een IT omgeving met kritische data redundant opgeslagen gegevens. Dit betekent, dat de data op minimaal twee datacenters is opgeslagen in bijvoorbeeld een database cluster. Valt er een deel van de omgeving in het éne datacenter uit, dan blijven de gegevens beschikbaar op het andere datacenter.
Let wel: Een gebruiker, die in staat is om data te verwijderen op een database cluster, kan door één actie zomaar de data in beide datacenters verwijderen.
Als een cluster, over meerdere datacentra, een oplossing is voor de uitval van een datacenter of voor de uitval van hardware, dan zullen procedures ervoor moeten zorgen dat de gebruikers dergelijke fouten niet maken.
Naast de procedures zijn er ook andere opties die bescherming bieden tegen dit soort gebruikersfouten. Er zijn moderne databaseoplossingen die de mogelijkheid bieden om transacties opnieuw af te spelen. Daarbij kan een database back-up als uitgangspunt worden genomen. Daarna kan de transactielog worden afgespeeld, met als startpunt de database back-up, om weer uit te komen op een bepaald punt in de tijd. Kijk wél naar de tijd die hiermee gemoeid is!
Zorg dat de database back-up en de transactielogs op een veilige plek staan en niet geraakt worden door een disaster. Je zult er ook voor moeten zorgen dat de data, die op een veilige plek staat, benaderbaar is als er een Disaster Recovery nodig is.
Gebruikersfouten kun je ook vermijden als je toegangsprotocollen en rollen goed ingeregeld hebt. Hiermee kun je op zichzelf al een disaster voorkomen.
Het maken van een plan is belangrijk, maar even belangrijk is het testen ervan!
Is het plan niet van te voren gemaakt en getest dan is het bijna onmogelijk om, op het moment dat het nodig is, goede keuzes te maken. Er is dan een enorme druk en veel stress.
Op zo’n moment wil je een document kunnen pakken waar letterlijk in uitgespeld is wat er moet gebeuren.
Het testen is nodig om te kijken of de tijdlijnen en de aannames over de werking kloppen met de werkelijkheid.
Zo kregen we eens de vraag waarom er over een gigabit verbinding maar 30 Mbps verkeer liep. Dat had te maken met latency in de orde van 30 ms naar het betreffende datacenter. Verwachten dat je met
1000 Mbps data kan verplaatsen, terwijl de realiteit een factor 33 minder is, dan is het duidelijk dat de RTO flink lager wordt. Een dergelijke situatie had voorkomen kunnen worden door vooraf het plan te testen.
Wij hebben in dit blog een beperkte blik op Disaster Recovery geworpen. Zo is hardware die volledig weg is als het datacenter is afgebrand, niet aan bod gekomen. Maar ook capaciteit van personeel is niet besproken. Heeft jouw organisatie voldoende capaciteit om een Disaster Recovery uit te voeren als het nodig is?
Denk van te voren na over wat er allemaal stuk kan gaan, speel advocaat van de duivel en bedenk voor alle scenario’s antwoorden. Test de plannen, die gemaakt zijn, om te kijken of ze werken en om vaardigheid op te doen. Dan is een disaster minder schadelijk voor je bedrijf!
Wil je meer weten over Disaster Recovery of met één van onze specialisten sparren over dit onderwerp? Neem dan vrijblijvend contact met ons op!
Neem contact op