Back-up processen zorgen nog vaak voor een te hoge belasting van de it-infrastructuur. In veel gevallen wordt er gekozen voor one size fits all-oplossing en dat is niet altijd de meest effectieve oplossing qua prestaties en kosten. Hoe kun je teleurstellingen voorkomen en maak je de juiste keuzes?
Stap 1: Breng je datalandschap in kaart
Het is van groot belang om een goed beeld te hebben van je datalandschap. Hoeveel data is er aanwezig? Bij welke bedrijfsprocessen hoort deze data? Welke applicaties maken gebruik van deze data? Wat is je groei? Vooral de groei is belangrijk om in kaart te brengen. Zo voorkom je bijvoorbeeld dat je te klein of te groot instapt. Vooral bij back-up naar disk kan dit voor verrassingen zorgen (een onmiskenbaar voordeel van tape is en blijft de schaalbaarheid in volume). De uitkomst van deze inventarisatie is de basis en essentieel voor alle volgende stappen.
Stap 2: Classificeer je data op basis van beschikbaarheid/herstelbaarheid
Het classificeren van de data is een van de meest tijdrovende klussen die er maar is. Als je namelijk aan de gebruikersorganisatie vraagt hoe belangrijk iets is, dan krijg je vaak te horen dat het allemaal belangrijk is en superkritisch. Maar als je vraagt hoeveel geld ze er voor over hebben, dan wordt het meestal al een heel ander verhaal. Dit is het eerste knelpunt in een ‘one size fits all’-aanpak. Het is daarom van groot belang dat je de dataclassificatie goed en gestructureerd oppakt, om te voorkomen dat de back-up een zorgenkindje wordt. Data classificeren naar het belang van de business wil zeggen dat je een aantal categorieën creëert op grond van eisen betreffende het herstel:
- Kritisch: verlies van deze data kan het einde van de bedrijfsvoering tot gevolg hebben
- Essentieel: verlies bedreigt de voortzetting van de bedrijfsvoering
- Ondersteunend: verlies is vervelend, maar bedreigt voortzetting van de bedrijfsvoering niet
- Archief: data die bewaard moet worden, maar weinig invloed heeft op de bedrijfsvoering
Een nog veel gemaakte fout is dat de back-up niet ontworpen wordt voor herstel. Per groep dienen dan ook recover point objective (rpo) en recover time objective (rto) bepaald te worden. Met name deze twee waarden bepalen uiteindelijk de technologiekeuze. De recovery point objective is bepalend voor het maximale verlies aan informatie. Zo verliest bijvoorbeeld een organisatie met een rpo van twaalf uur dus één dag aan wijzigingen. De recovery time objective bepaalt hoe snel de data in geval van een escalatie weer beschikbaar moet zijn. Met name tape heeft hier een slechte reputatie: algemeen genomen duurt het teruglezen een factor twee tot drie langer dan het schrijven.
Pas na het vaststellen van bovenstaande zaken zou er gekeken moeten worden naar een passende technische oplossing om te voorkomen dat er een one size fits all-oplossing gekozen wordt die niet alleen inefficiënt is in kosten, maar ook ineffectief als het om dataprotectie gaat. Nu is classificatie één van de meest tijdrovende processen binnen een organisatie. Het is een discussie waar de ict-afdeling om de tafel moet met de gebruikers om duidelijkheid te scheppen.
Stap 3: Manier van veiligstellen
De uitkomsten van stap 1 en 2 dienen als basis gebruikt te worden voor de technologiekeuze. Tijdens het maken van een back-up is een organisatie kwetsbaar, zeker als dit proces langer dan acht tot twaalf uur duurt. Het is daarom belangrijk om voor de eerder vastgestelde groepen de juiste keuzen te maken op het gebied van technologie, waarbij er in hoofdlijnen twee werkwijzen zijn om de data veilig te stellen: volledig of incrementeel. Oftewel iedere keer een back-up maken van alle data of alleen van de wijzigingen ten opzichte van de vorige back-up. Met name hier komt het voordeel van disk versus tape sterk naar voren door de mogelijkheid om uit verschillende incrementele back-up’s een volledige back-up te maken.
Stap 4: Bepaal het medium
De rpo en rto bepalen samen de keuze voor het medium. Tape is zeker nog een valide optie, want als je iets jaren ongewijzigd moet bewaren dan heeft dit medium nog altijd een goede business case. Nu wordt opmerkelijk vaak de back-up nog als archief misbruikt. Een dubbele last, omdat hierdoor niet alleen de kosten beduidend hoger worden, maar ook de hersteltijden langer. Een opkomend back-up medium is de cloud, die een kostenefficiënt alternatief biedt voor back-up, maar meestal niet de snelheid die nodig is om te herstellen. Vrijwel geen enkele provider biedt een sla aangaande de rto. Dat wil nog niet zeggen dat dit medium oninteressant is, want met name aan de kant van de gebruiker groeit het volume aan data hard.
Stap 5: Kennis en beheer
In de markt leeft nog wel eens de perceptie dat de technologie vaak de spelbreker is en zorgt voor onsuccesvolle back-ups. De waarheid die ik vaak tegen kom bij klanten is totaal anders. Lange doorlooptijden zijn niet altijd zichtbaar. Niet alles wordt even effectief gedaan omdat investeringen in modernisatie van de back-up vaak een lage prioriteit hebben. Vaak wordt er achter de feiten aangelopen en is het hoogst onzeker of alle data wel hersteld kan worden, laat staan binnen de gestelde eisen. Dit terwijl de back-up onderdeel uitmaakt van het informatiebeveiligingsplan en dus een onderdeel is van de disaster recovery. Hierbij moet trouwens niet alleen gedacht worden aan de data maar ook aan ip-adressen, dns-aanpassingen, netwerkrouteringen, naamgeving et cetera.
Conclusie
Een back-up dien je in omgekeerde volgorde te ontwerpen, op basis van hoe belangrijk de data is voor de business. Vind de juiste technologie bij de wensen en eisen en niet andersom. Niet alles is even bedrijfskritisch en essentieel. Dus classificeer eer ge begint. Pas dan kun je de meest effectieve en passende oplossing(en) voor het veiligstellen van je data vinden. In mijn volgende artikel zal ik nog meer uitweiden over de verschillende technologieën die er op het gebied van back-up beschikbaar zijn.
Da’s weer een helder stappenplan. zo ben ik ze van je gewend, Ruud.
Wat je wel kort aan stipt maar niet verder uitwerkt is het belang van het onderkennen van het verschil tussen back-up en archief. Omdat de functie verschilt (doel bewaren versus doel repareren) is ook de oplossing en het beslissingstraject niet per definitie het zelfde.
Guido,
Dank voor je reactie.
Ik heb hier in het verleden al wel eens iets over geroepen. Maar het is zeker een valide punt wat je aan haalt.
Tijdens het classificeren van je data is het van groot belang om ook te kijken naar welke data mogelijk gearchiveerd kan worden. Door deze archiefdata uit je reguliere back-up te halen en alleen nog maar veilig te stellen als er echt iets veranderd, verlaag je de belasting op je back-up omgeving aanzienlijk.
En ja, de beslissingstrajecten wijken ietwat van elkaar af in mijn optiek. Maar beide hebben dezelfde raakvlakken omdat je rekening moet houden met beleid,SLA’en regelgeving. Dataclassificatie dient als basis voor beide.
Mijn ervaring met archiveren is wel dat het politiek vaak wat gevoeliger ligt. Als je tegen een gebruiker zegt dat het langer duurt voor dat hij historische data kan opvragen, dan wordt dit niet altijd gewaardeerd.
Ik kan uit ervaring vertellen dat ik ooit eens project gedaan heb, waar in de organisatie niet ingelicht werd. En men had de 1e dagen helemaal niets door. Tot dat het iemand op viel dat de icoontjes ietwat gewijzigd waren. Het desbetreffende archiefprogramma wijzigde dit ietwat van kleur en voegde een embleem toe. Qua performance was het niemand opgevallen. Zo zie je maar weer dat informeren niet altijd nodig is.
De mening van de gebruikers is 1, de eisen van de regelgevers zijn 2.
Waar back-up vooral een antwoord geeft op de behoefte om een integer informatiesysteem te hebben en houden is het archief vooral bedoeld om historische data niet kwijt te raken (maar wel weg te zetten).
Een verschil is doel maakt dat er ook andere criteria gelden die weer voor andere keuzes zullen zorgen.
Guido,
Je hebt helemaal gelijk. Maar back-up is wel degelijk ook om aan regelgeving te voldoen. Het niet terug kunnen zetten van data is in sommige gevallen strafbaar.
Helemaal waar, Ruud. In je auto zijn een rem en een handrem nodig en verplicht, ze doen veel het zelfde maar toch ook weer niet alles en je moet ze vooral niet door de war halen bij het gebruik 😉
Weer een goed artikel Ruud.
Dank voor deze bijdrage.
Ruud,
Goed en sterk artikel. Kan het alleen maar bevestigen tov mijn ervaringen. Goed om te delen, dank voor je bijdrage.
@ Peter,
Dank voor je reactie en compliment.
Ik ben blij dat het herkenbaar is. In mijn 2e deel zal ik wat meer de keuzes die je op het gebied van back-up technologie kan maken toelichten.
Maar zonder bovenstaande voorbereidingen kan je nooit de juiste keuzes maken qua technologie.
Als eerste ga ik een Rezaatje doen door te verwijzen naar een eerdere opinie die ik over dit onderwerp geschreven heb: ‘Back-ups zijn als vliegende olifanten’
In reactie stelde ik al dat met name het archief een steeds groter probleem wordt, veel organisaties misbruiken de back-up hiervoor waardoor RPO/RTO op verschillende manieren onder druk komt te staan. Gelijk gaf ik naar aanleiding van vragen ook cijfers over het belang van een back-up. Cijfers over een succesvolle restore zijn nog schokkender, zeker als het een volledige rebuild van een systeem betreft.
Ik wil dan met name aandacht vragen voor de conclusie, wie bepaald nu precies wat wel en niet belangrijk is?
Zo vraag ik me af hoe erg het is als een factuur 5 dagen later verstuurd wordt versus hoe erg het is als een bepaalde bestelling 1 dag later verstuurd wordt. Ik haal met name deze vraag aan omdat ik nog weleens constateer dat IT manager beslissingen neemt aangaande de back-up in plaats van de business. En ik denk niet dat ik een geheim vertel dat de meeste IT managers geconditioneerd zijn om op de kosten te letten.
Bovenstaande komt uit praktijk voorbeeld waar eindeloos over relatief kleine investering getwijfeld werd door IT terwijl de schade van onderbreking van de service een factor 100 groter was. Wie op de kleintjes let verliest namelijk nog weleens het grotere geheel uit het oog.
Een beetje uit de lucht gegrepen cijfer is dat 9 van de 10 organisaties een risico lopen aangaande herstel. De onderbouwing van voorgaande stelling is dat IT vaak geen enkel idee heeft van wat ze nu eigenlijk allemaal veiligstellen terwijl de business weer geen idee heeft van de onderliggende techniek.
Benieuwd naar vervolg wat in gaat op de technologie omdat deze dus sneller voortschrijdt dan het proces.
In het land der blinden is eenoog koning en dus verbaas ik me ik me al niet eens meer over een praktijkcase die een concurrent hier publiceert waarbij de back-up als basis voor het zaakgericht werken gepresenteerd wordt maar ik had geloof ik al wat gezegd over back-up misbruiken als archief.
Vooral in de classificatie essentieel zie ik nog weleens een ‘onderverzekering’ doordat een in eerste instantie als ondersteunend geclassificeerd systeem stilletjes essentieel of zelfs kritisch is geworden. Daarmee wil ik benadrukken dat gehele classificatie zeker ook geen ‘one-size-fits-all’ proces is.
Ewout,
Dank voor je uitgebreide reactie. Je haalt een aantal zeer valide punten aan. Het classificeren van de data dient samen met de business gedaan te worden. IT heeft daar in een ondersteunende taak en moet de wensen en eisen vanuit de business vertalen naar de juiste techniek. Tenminste zo kijk ik er tegen aan.
Juist bij de classificatie gaat het nog te vaak fout. IT doet dat vaak op basis van aannames. En hier door kan het voorkomen dat data verkeerd geclassificeerd wordt. Ook heeft de business vaak geen benul wat de impact van het back-up proces is en wordt daarom te vaak gekozen voor een one size fits all oplossing. Die is nu eenmaal gemakkelijk te beheren.
Het kan ook nlg veel erger. IT gaat vaak nooit deze dataclassificatie discussie aan, omdat deze als lastig en tijdrovend wordt gezien.Uit deze discussie kan namelijk komen dat de door IT gebouwde en geadviseerde huidige omgeving alles behalve voldoet. Het classificeren van data zorgt er ook voor dat je toch in zekere mate een prestatie verplichting aan gaat. En ook dat geeft nog wel eens koudwatervrees.
Dataclassificatie is mijn optiek dus veelal een politiek proces wat uiteindelijk vertaald wordt in de juiste technische oplossingen.