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.
3.b
Veiligstellen door de backup te verifiëren.
Wat Ewout ook al aanhaalde. En regelmatige backup zonder een regelmatig geteste restore is vragen om moeilijkheden.
De technologie is dan niet de bottleneck maar het menselijk inzicht en toepassing van een onderbouwde risicospreiding.
Dit hoort bij elke ICT organisatie/afdeling gemeengoed te zijn. Als dat niet het geval is dan heeft u of een goede reden of loopt u onnodig risico.
Johan,
Dank voor je toevoeging.
Helemaal mee eens. Veilig stellen van data is leuk. Maar daar ben je er nog niet mee. De data die je veilig gesteld hebt, moet consistent zijn en terug te zetten zijn.
Dat laatste is natuurlijk iets wat geregeld getest moet worden. Dit is veelal een organisatorisch proces wat in gegereld dient te worden. De technologie is hier veelal ondersteunend aan. Al moet ik wel onderkennen dat er steeds meer technologie beschikbaar komt die het 1 en ander kan simuleren en automatiseren.
Echter ben ik nog steeds van de oude stempel en van het zien is pas geloven. Het echt goed testen of je back-up consistent en goed is, is en blijft een tijdrovende aangelegenheid.
@Ewout,
Fijn te zien dat je ook iets van andere mensen aanneemt/overneemt. Dat zie ik meer als een compliment. Maar het verbaast me dat je dit pas nu aan mij relateert terwijl je dit al eerder in je reacties gedaan hebt! Maar nogmaals bedankt voor je compliment eb houd het vast 🙂
Ruud,
Leuk artikel. Ik zie het meer als een samenvatting van een aantal zaken die je als reactie eerder op deze site achtergelaten hebt. Dus niks nieuws voor mij maar misschien interessant voor mensen die je niet eerder gevolgd hebben. Ik probeer even hierop te reageren anders oogt dit artikel als een Unisys feestje 😉
Ik ben het eens met de zaken die je in stap 1 en 2 benoemd hebt. Maar……
1- Als het goed is heb je al je datalandschap, groei, dataclassificatie etc etc tijdens het ontwerp van je storage in kaart gebracht. Dus dat nog een keer doen lijkt me overbodig.
2- Heb je dat niet eerder gedaan in punt 1 hierboven? Geen punt, classificatie en indeling kom je nog een keer tegen als je je DR-draaiboek gaat maken. In dat proces kom je beschikbarstellen van je services en hieraan gerelateerde zaken zoals data(bronnen/soorten/ volgorde/RPO-RTO en nog meer) tegen. Daarom vind ik stap 1 en 2 niet echt nodig als je al je BC/DR plan opgesteld en getest hebt. Voordeel van deze aanpak is dat je je BC/DR ook tets!
3- De uitvoering volgens je aanpak in stap 1 en 2 zie ik persoonlijk, in de termen gesproken van je collega Ewout Dekkinga hoogleraar taal en wollige communicatie, als “de gebruikelijke zeemeeuwen consultancy”. Want we weten heel goed dat de inrichting en indeling van je storage en dus je datalandschap circa 1 jaar na de implementatie totaal anders gaat worden dan in het begin. Ik denk dat je veel zaken hieromtrent eerder, voordeliger en slimmer kunt oplossen als je begint met het opstellen van een BC/DR draaiboek.
Ik sla punt 3,4,5 over. Daar hebben we eerder in andere artikelen over gesproken.
Wat ik wel interessant vind is een duidelijke vergelijking tussen back-up naar cloud vs traditionele back-up!
Reno van de Looij heeft vorige week op een andere site hierover een artikel geplaatst. Je gaf in het kort een aanvullende reactie op mijn reactie op dat artikel. Het lijkt me zeer interessant als je als expert in je volgende artikel op Computable op een aantal punten die ik daar benoemd heb verder in te gaan.
Ik kijk uit naar je volgende artikel!
Reza,
Dank voor je reactie. En ja Unisys is erg actief in de discussies op Computable. En aangezien je ons hier actief volgt kan je ook zien dat we het niet altijd met elkaar eens zijn. Jouw collega’s zijn natuurlijk hier ook meer dan welkom om zich in alle discussies te mengen. Hoe meer zielen, hoe meer vreugd. En van elkaars inzichten leer je natuurlijk alleen maar.
Even terug komen op je punten:
1. Uitgaan van “als het goed is” doe ik nooit. Aannames zijn in ons vak dodelijk. Je zal verbaasd zijn hoeveel organisatie geen enkel idee hier van hebben of na een paar jaar het inzicht totaal verliezen. Vaak is alleen de totale capaciteit duidelijk. En ook die cijfers zijn vaak niet accuraat.
Er wordt nog te vaak door onduidelijkheid en gebrek aan inzicht gekozen voor een one size fits all oplossing. Die natuurlijk alles behalve toereikend en kosteneffectief is.
Je geeft zelf ook al aan dat je datalandschap onderhevig is aan veel verandering. Dus in mijn optiek is deze stap een continu proces die zeer hevig is aan verandering. Dit doe je niet alleen maar bij het ontwerpen van je storage omgeving.
Als je dat eenmalig doet loop je in mijn optiek achter de feiten aan en loopt je continuïteit als organisatie zijnde mogelijk gevaar.De eisen en regelgeving op het gebied van het beschikbaar hebben van je data zijn onderhevig aan veranderingen. Wat vandaag belangrijk is en perse bewaard dient te worden kan over een x aantal weken,maanden, jaren totaal veranderd zijn.
Echter zie ik wel vaak dat de classificatiegroepen niet dagelijks veranderen. Alleen is het wel zaak om deze groepen zo nu en dan tegen het licht te houden. Is de RPO/RTO nog toereikend? Zit de data wel in de juiste groepen? Voldoe ik aan alle regelgeving? etc. etc.
2. Je brengt eerst je data in kaart. Dan verdeel je het in groepen en dan pas stel je per groep een RPO/RTO op. Dit combineren in 1 stap maakt het er niet duidelijk op. En kost vaak te veel tijd. Verschillende seperate iteraties vergroot de kwaliteit en dus ook het succes. En zoals ik hier boven al schreef dit blijft een dynamisch proces wat je geregeld even tegen het licht moet houden.
3. Dat je storage omgeving dynamisch is, is mij natuurlijk wel duidelijk. Gelukkig wel, anders zou mijn vakgebied wel heel erg saai worden. Je moet deze oefening natuurlijk geregeld doen en up to date houden. Zie dit als periodiek onderhoud. Data verandert namelijk dagelijks qua omvang en performance. Ik zie daarom het vergelijk met ” Zeeleeuwen consultancy” totaal niet.
En ja er zit wel wat herhaling in van artikelen die ik eerder geschreven heb. Maar de kracht van herhaling kan nooit geen kwaad. Over cloud vs traditioneel heb ik in het verleden al wat geschreven:
https://www.computable.nl/artikel/opinie/storage/4635530/1277017/wijze-van-opslaan-bepalend-bij-veiligstellen-data.html
Mijn volgende stuk zal wat meer op de technologie keuzes in gaan. Dit is ook het logische vervolg aangezien dit artikel op de voorbereiding gaat.
Ik vind het een weer sterk stukje, goed gedaan Guido. In het verleden heb ik verschillende premigrationele trajecten opgetuigd en daar was het echt wel one size fits all.
1. Resize data
Geef te kennen dat data gaat worden gereduceerd en dat data van langer dan moment (X) zal worden gebackupt doch niet langer bereikbaar. De bedoelde data werd slechts onzichtbaar gemaakt voor gebruikers voor een gelimiteerde periode en wanneer er geen reactie kwam, -> Archive. We hebben het hier over gemiddeld 80% van data die niet meer werd aangesproken. (Eyeopener???)
2. Dismiss data
U kent dat wel, onzinnige data die iedereen wel eens verzameld. JPG/GIF/BMP etc die men ‘wel eens gebruikte’ Overigens, surveys leerde ook dat menig niet te vies is van het neerzetten van MP3/4 of complete films op corporate shares. Ook een echte eyeopener.
3. Mailfiles
Niet veel mensen denken er aan maar mailfiles doen een enorme aanslag op je ruimte en performance doch weinig zie je daar echt oog op hebben. (Natuurlijk, u als lezende professional niet, I know…)
4 Duidelijk protocol
Lijkt een overbodige luxe maar 75% van de organisaties hebben werkelijk geen eenduidige richtlijn van de ‘do’s en dont’s’ van data. Begin er eens over want ook dat scheelt je enorm veel.
De stap voor die backup zou volgens mij gewoon datasupervision kunnen zijn…. als er natuurlijk iets ‘as such’ bestaat.
Goeie Guido. Dank.
NumoQuest,
Dank voor je compliment. Alleen was het niet Guido maar ik die het artikel geschreven heb 😉
Je haalt zeer herkenbare punten aan. Waar voor dank!
1. Herkenbaar. Niet alles is even kritisch en wordt echt gemist. Dit is een leuk trucje om zo nu en dan te doen. Archivering op welke manier dan ook is een erg mooie oplossing om de back-up te ontzien.
2. Non business data zou in mijn optiek zou in mijn optiek preventief geruimd /tegen gehouden moeten worden. Maar ik deel je mening dat dit niet altijd even secuur gebeurt.
3. De logge en grote PST files nemen vaak te veel capaciteit en performance in beslag.
4. And last but not least. Alles begint in het leven met een goede opvoeding/educatie. Dus dat geldt hier ook zeker.
Ruud,
Helder verhaal zoals vaker. Veel is gelegen in het feit dat organisaties te weinig resources vrij maken om classificatie vorm te geven. Ergens is data altijd belangrijk zeker als de eigenaar onbekend is. Ervaringscijfers leren dat 60% van de data nooit meer wordt aangeraakt welke ooit opgeslagen is. Als ik niet struikel over de schoenen van de kinderen als ik de deur binnenkom dan ruim ik ook niet op. Misschien is de pijn toch niet zo groot en geven we graag extra geld uit aan opslag en back-up.
Frank,
Op zich zeer herkenbaar wat je schrijft. Waar voor dank.
Alleen is binnen iedere organisatie de back-up omgeving vaak een groot verbruiker op het gebied van resources en capaciteit. Echter is dat niet bij iedere organisatie altijd even helder en inzichtelijk. Ik heb wel eens assessments gedaan waar in men schrok van het feit dat er tig jobs langer dan 36 uur duurde. En dan waren dat niet alleen de periodieke fulls.
Juist het preventief opruimen en classificeren van je data zorgt er voor dat je RTO aanzienlijk verlaagd kan worden. Of te wel hoe minder je moet terug zetten na aanleiding van een incident/escalatie, des te sneller je weer in de lucht bent. Het is erg belangrijk om bijvoorbeeld bij het verliezen van een locatie vooraf duidelijk te hebben wat essentieel/kritisch is om ergens anders weer de lucht in te gaan. Alles terug zetten kost namelijk veel tijd.
Door het goed managen van je data ( lees archiveren/ opschoning ) creeer je ook vaak extra capaciteit. En die capaciteit kan mooi ingezet worden voor groei of voor het verbeteren van je RPO.
Of te wel om een lang verhaal kort te maken. Opruimen en bijhouden van je data en back-up omgeving levert een hoop voordelen op.
Sterk artikel. Kan het alleen maar bevestigen, ik heb dezelfde ervaringen.
Dank NumoQuest, ik vond ook dat het artikel bijna mijn niveau had 😉