Als we het over data recovery hebben denken we het liefst aan het gecontroleerd terugzetten van gemaakte back-up data, na bijvoorbeeld een systeemcrash, volgens een zorgvuldig en van te voren opgesteld draaiboek.
We noemen dit simpelweg data recovery of disaster recovery. De it-afdeling kan zich in het algemeen, en dat zal bij professionele bedrijven zeker het geval zijn, heel goed voorbereiden op dergelijke eventuele situaties. De ‘data recovery of de disaster recovery’ waar ik het hier over wil hebben gaat echter over iets anders. Het gaat hier over situaties waar we ons niet met (nog meer)it-systemen op kunnen voorbereiden.
Voorbeelden: de overdracht van de ene op de andere systeembeheerder is niet goed verlopen, er zijn fouten gemaakt, er zijn dingen vergeten of verzwegen, er is te weinig onderhoud gepleegd, er is verzuimd een back-up te maken, bij het terugzetten van de back-up is iets misgegaan wat niet mis had mogen gaan, er is te veel vertrouwd op de redundancy van raidsystemen of san’s, et cetera.
Maar denk ook aan fouten die meer aan de kant van het management liggen: nooit uitgevoerde risico analyses, geen budget vrijgemaakt voor disaster recovery planning, het document voor bedrijfscontinuiteit dat nog steeds in de la ligt, geen echte interesse voor alles wat zich in de ‘it-kelder’ afspeelt, het kennisniveau van de it-medewerkers matcht niet meer met de laatste ‘stand van de techniek’. Denk aan virtualisatie. Het gaat in alle gevallen over menselijke fouten. Heel vaak verwijtbare fouten. Maar ook vermeende menselijke fouten zoals het niet hebben van de juiste kennis en kunde.
Ook wordt vaak geconstateerd dat het management te laat of helemaal niet op de hoogte wordt gebracht van storingen en/of incidenten. Ook niet als diezelfde storingen en/of incidenten potentiële bedrijfsrampen zijn. De oorzaak is dat het bij dit soort type incidenten/storingen om menselijke fouten gaat. Verwijtbare fouten. Al dan niet terecht verwijtbaar, maar er speelt een schuldvraag. Deze incidenten en problemen probeert men uiteraard zo lang mogelijk op eigen niveau op te lossen. Proberen om de ramp terug te brengen tot een storing. Men houdt het liever even voor zichzelf of binnen de afdeling. Alles beter dan een discussie aan te moeten gaan over de schuldvraag.
Dit kost een heleboel tijd die er niet is en maakt het probleem in veel gevallen groter en soms zelfs catastrofaal. En de oplossing verder weg. Bij disaster recovery moet juist worden samengewerkt, open kaart gespeeld, en snel geschakeld. Het gaat niet om de schuldvraag, maar om de oplossing.
Het gaat er, als het spannend wordt, niet meer om hoeveel it-systemen we hebben, maar in hoeverre we kunnen samenwerken en snel en transparant kunnen handelen. Oók met hulptroepen van buiten af. En juist als een dergelijke situatie zich voordoet is het zaak dat men weet wat er te doen staat. En dat men zulke hulptroepen kent. Het is dan geen schande om niet alle specialistische kennis in eigen huis te hebben of om fouten gemaakt te hebben. Voor bijzonder complexe problemen zoals raid- en VMWare-recoveries zijn zeer bedreven specialisten beschikbaar. Die specialisten kunnen veel meer voor elkaar krijgen als zij in een zo vroeg mogelijk stadium bij het ‘incident’ betrokken worden.
Data recovery specialisten kunnen een zeer goede aanvulling zijn op je eigen team. Al is het maar om precies te weten waar jouw kennis ophoudt en die van hen begint.
Ga eens kennis maken, zodat het hele team weet wat hen (niet) te doen staat als het zover komt!
Kees Jan,
Je slaat de spijker op zijn kop. Je kan wel de meest fantastische technologie in huis hebben, maar als men niet weet hoe er mee omgegaan wordt heb je er nog steeds niets aan.
Het is daarom van belang om het DR draaiboek een x aantal keer per jaar te testen en waarbij nodig aan te passen en up to date houden.
Ook blijft opleiding en training van de mensen die er mee moeten werken van cruciaal belang.
Doe je dat niet dan is de kans op een teleurstelling groot en loopt de mogelijk ook de continuïteit van je organisatie gevaar.
Een kernwaarde van DHPA deelnemers is een open bedrijfscultuur waarin de het maken van menselijke fouten eerder wordt gezien als een kans om te verbeteren dan als een aanleiding voor zoeken van schuldigen. Dat is een essentiele voorwaarde voor veiligheid en continuiteit, want bij een cultuur waarin bestraffen voorop staat, zullen de betrokkenen eerder hun fouten verdoezelen.
Het maken van fouten is menselijk. Maar het gaat erom hoeveel veerkracht, redundantie en oplossend vermogen de organisatie heeft geregeld. Een continuiteitsoplossing zoals voor Kees geschetst zal daarbij zeker helpen. Een vangnet “voor het geval dat”
Kan me goed inleven bij de inhoud, maar ik ben het niet eens met de titel.
Governance, Risk & Compliance (GRC) zijn in mijn ogen taken die niet bij de IT afdeling liggen, maar bij de business. De IT is in dit opzicht dus uitvoerend en werkend voor GRC.
Zeker in tijden dat we ook dingen naar de “cloud” toebrengen dienen dit soort zaken op een breder niveau te liggen dan bij IT.
Kees Jan,
Data recovery is onderdeel van disaster recovery, een detail binnen een groter plan. Een bedrijf dat alle data keurig op tape heeft maar niet de (sleutel)personen om deze beschikbaar te maken op systemen heeft net zo goed een probleem als vice versa.
Nu gaat dit stuk daar natuurlijk helemaal niet over maar om het terug halen van data van gecrashte schijven waar geen back-up van is. Iets dat tegenwoordig ook niet ondenkbaar is nu steeds vaker vertrouwd wordt op disk als vervanger van tape. En het is ook wel herkenbaar omdat ik zelf de ervaring opgedaan heb dat ISP misschien wel een backup maakt maar deze niet altijd op een andere RAID array zet.