Het lijkt alsof het veiligstellen van data erg naar de achtergrond is verplaatst. Op zich is dat niet verrassend. In het storagelandschap is dit immers het meest complexe onderwerp. Organisaties worden niet erg geholpen. Iedere fabrikant richt zich op het kunnen veiligstellen van eigen belangen. Het kan ook komen doordat het een van de weinige IT-onderwerpen is die afdelingoverschrijdend is en het gehele bedrijf raakt. Dit, terwijl liever niemand de eigenaar ervan wil zijn.
Even om de basis te zetten. Back-up is de technische inrichting voor het veilig stellen van data om, aan de door de afdeling en organisatie gestelde eisen, (ver)storingen, data corruptie en het verliezen van data te kunnen herstellen. Hier gaat het direct al mis.
De eigenaren van de data (gebruikers, afdelingen, informatie- en securitymanagers en de organisatie zelf) zijn eigenlijk verantwoordelijk om te bepalen welke data van hun belangrijk is, hoe lang dit bewaard moet worden en vooral hoe snel data hersteld moet worden. Dit is praktisch onmogelijk, omdat de data die door gebruikers worden gegenereerd eigendom zijn van de organisatie waar ze voor werken. Daarbij is het inmiddels onduidelijk aan welke wet- en regelgeving en kwaliteit- of certificeringseisen voldaan moet worden, nu de data niet alleen meer lokaal wordt opgeslagen. Ook is het lastig om de verschillende dataformaten en koppelingen op een en dezelfde manier veilig te stellen.
Fabrikanten van storage oplossingen, virtualisatie platformen en databases en applicaties bouwen allemaal eigen back-up tools in om te zorgen dat hún spullen herstelbaar zijn. Ook de grote hoeveelheid data vormt een uitdaging bij het snel veilig te stellen. Hierdoor moeten we gebruikmaken van tussenoplossingen. Tot slot – er zijn nog veel meer uitdagingen voor het veiligstellen van data – wordt het IT-team aangesteld om de back-up in te richten, te verzorgen, te controleren en om de data juist te bewaren zodat wordt voldaan aan de wet- en regelgeving. En daar komt ook nog bij dat we de back-up gebruiken voor herstel en het bewaren van een archief. Resultaat: We proberen alles te standaardiseren en alles maar gewoon op te slaan voor een tijdje, hopende dat er nooit een uitdaging komt. Neem in ieder geval een duidelijk besluit om back-up en archief los van elkaar te koppelen.
Wat als het zover komt dat een herstelactie moet worden uitgevoerd?
Een herstelactie is nodig door een menselijke fout of door een calamiteit waardoor een groot gedeelte van de organisatie (of de gehele organisatie) niet verder kan werken. Het herstellen van een enkel Word of Excel documentje is geen probleem, als het maar veiliggesteld is voordat het mis ging en op tijd kan worden hersteld voor het weer gebruikt moet worden. Maar wat als het om meerdere gelijktijdige herstelverzoeken gaat, waarvan de data ook nog van elkaar afhankelijk is. Wie mag eerst en hoe snel moet dit gebeuren? Wellicht het meest belangrijk is een andere vraag. Hoeveel geld hebben we beschikbaar voor de “herstel verzekering”? In de wetenschap dat we misschien nooit gebruik maken van een restore en het dan gewoon veel geld kost.
Voordat we hier een antwoord op te kunnen geven zetten we de basis voor herstel.
Restore (Recovery) is het herstellen van data naar een opgegeven punt in tijd binnen een gestelde hersteltijd. Dit met als doel zo min mogelijk dataverlies en improductiviteit te hebben.
Hoe vaker en sneller data wordt veiliggesteld, des te minder dataverlies je hebt en des te sneller deze data kunnen worden hersteld en de organisatie weer aan de slag kan. De gehanteerde hersteld waardes zijn RTO (recovery Time objective). Hoe lang mag je over een herstel doen? En RPO (recovery point objective) – naar welke situatie moet hersteld worden.
Voor een documentje is de RPO eenvoudig, want je gaat meestal naar de laatst veiliggestelde versie terug. Bij een database en applicatie kan je terug naar een situatie waar het nog werkte. Maar als je database een link naar een plek heeft waar bestanden zijn opgeslagen wordt het al complex. Hetzelfde geldt voor het herstellen van een (virtuele) server. Het besturingssysteem kan wel eenvoudig worden hersteld (en soms is het zelfs sneller om een server opnieuw te installeren), maar de koppeling met de data volumes en applicaties vraagt al bijna om een onmenselijke beslissing.
Als voorbeeld; U heeft een datawarehouse en een online webshop en er gaat iets mis. De data in het ERP-systeem raakt corrupt. Wat doet u dan? Zet u de gehele organisatie terug naar het moment dat het ERP-systeem nog werkte? Waar zijn alle leveringen die het warehouse al zijn verlaten en wat is de actuele voorraad? Kunnen we alle verloren transacties nog herproduceren? Het verwerken van de meest recente transacties is menselijk nog tot een uur terug accuraat te herstellen, maar alles daarvoor wordt al onbetrouwbaar, laat staan transacties van de dag of week ervoor.
Moet je chronologisch exact herstellen of mag klant 001 bij het herstellen ook aan een inkoop opdracht b worden gekoppeld en klant 002 aan inkoop opdracht a. Hoe controleer je of de bestellingen en facturen die zijn uitgestuurd niet nog een keer worden uitgestuurd en wat doe je als na een paar dagen of weken klanten beginnen te klagen over verkeerde leveringen die niet meer in het systeem terug te vinden zijn. Gaat u het zo goed mogelijk proberen te herstellen of probeert u zoveel mogelijk te herstellen in de huidige situatie en neemt u het verlies.
RTO (recovery time objective) wordt meestal verward tussen de wenselijke hersteltijd (zoals door het Centre Technologies genoemde Maximum Tolerable Downtime) van de getroffen gebruiker, afdeling of organisatie en de technische duur voor het fysiek terug zetten van de data.
Het gebeurt te vaak dat de RPO (vooral bij fabrikanten van de storage, back-up en recovery oplossingen) wordt gebruikt voor de technische duur van het fysiek terug zetten van de data.
Bij grote calamiteiten duurt het meestal even voordat wordt opgemerkt dat data corrupt of verdwenen zijn. Pas dan wordt de impact duidelijk en kan er vanuit de directie of het managementteam een besluit worden genomen om te gaan herstellen. Hier komt de IT-organisatie in beeld. Op welke servers en storagenetwerken kan je herstellen? Moet je uitwijken of nieuw aanschaffen? Je moet een doellocatie hebben om te kunnen aanvangen met het herstellen van fysieke data, alvorens de functioneel beheerder zijn herstel kan uitvoeren en er getest kan worden door de gebruikers. Tot slot dienen de verloren data handmatig hersteld of opnieuw ingevoerd te worden – als dat dan nog mogelijk is – voordat de organisatie weer normaal kan functioneren.
Uitgaande van enkele “goed doordachte” RTO-uitgangspunten voor bijvoorbeeld het binnen vier uur herstellen van een database, kom je er in de praktijk al snel achter dat je dan helemaal niet meer uitkomt met het technisch kunnen veiligstellen en kunnen herstellen binnen deze tijd. En dat de directie nu al vast een besluit moet nemen voor een escalatie die nog niet plaats heeft gevonden.
Het IT-team wordt voor een onmogelijke klus verantwoordelijk gemaakt, terwijl de eigenaren van de data voor de verantwoordelijkheid en de continuïteit van de organisatie weglopen. Op zich nog geen probleem, want het is gewoon een lastig onderwerp, maar beperk dan niet het budget van IT om het zo goed mogelijk te doen.
Er is tegenwoordig technisch al veel mogelijk. Er is niet slechts één een oplossing voor alles. Laat staan dat er al een antwoord is voor alle hypes als Cloud, IOT, Digitale Transformatie en Big Data waarmee organisaties en IT-teams geconfronteerd worden.
Virtualisatie en Automation helpen om het inrichten van het data center te versnellen omdat je altijd een actueel draaiboek en templates van de virtuele servers tot je beschikking hebt. Maar volgens mij werkt het gewoon het beste als IT de complexiteit en impact van de gegokte hersteltijden van de organisatie begrijpelijk uitlegt en bespreekbaar maakt. Om dan gezamenlijk tot een werkbaar functioneel herstelscenario te komen. Daarop wordt dan pas de technische inrichting afgestemd met het budget dat vereist is.
Laten we eens beginnen met alle data weg te gooien die voor de organisatie echt niet relevant meer of sterkt verouderd zijn. Dat scheelt aanzienlijk aan opslagcapaciteit en geld en de tijd voor het veiligstellen en herstellen van belangrijke data. Vraag bij je leverancier naar een data asset management tool(tje) om snel inzichtelijk te krijgen hoeveel data inactief of dubbel zijn.
Maar richt je bij de back-up op die enkele simpele opdracht: “Het kunnen herstellen van data binnen de door de organisatie realistische hersteltijd” dan wordt de rest makkelijk.