Back-up en disaster recovery, vooral kleine en middelgrote bedrijven worstelen ermee. De forse investeringen in extra hardware en een uitwijklocatie, maar ook het extra beheer komen vaak ongelegen. Vijf back-up-uitdagingen, die eenvoudig te tackelen zijn.
1. Verstrikt in tape
Is tape als back-upmedium dood? In 2013 gaf 94 procent van de kleinere bedrijven aan dat ze nog tape gebruiken. Bij middelgrote en grote bedrijven was dit 56 procent. Sterker nog, een cloudgigant als Google maakt ook gebruik van tape. Waarom is dit? Omdat tape onmiskenbaar voordelen biedt als opslagmedium. Een back-up-tape op de plank kost geen geld meer, een draaiende harde schijf (spinning disk) vraagt continu stroom. Zeker voor de langetermijnback-ups is tape kosteneffectiever.
Maar er zijn ook nadelen. Voor de dagelijkse back-up is een tape-oplossing veel te arbeidsintensief. Zowel het back-uppen, archiveren, restoren als verplaatsen naar een uitwijklocatie kost aanzienlijk meer tijd. Tapes kunnen daarnaast beschadigen, waardoor ze onbruikbaar worden of de kwaliteit achteruit gaat.
Omdat een uitwijklocatie vaak niet aanwezig is bij kleine en middelgrote bedrijven, neemt de systeembeheerder of directeur de back-uptapes mee naar huis. Vaak wordt vergeten om deze mee terug te nemen naar het werk, of de verkeerde tape wordt meegenomen. Hierdoor ziet de systeembeheerder door de tapes de data niet meer.
Tape is niet dood, maar gebruik de oplossing waar deze het meest geschikt voor is: de lange bewaarplicht. Voor de korte termijn is disk een oplossing die kosteneffectiever is, betrouwbaarder en een ondersteuning voor de bedrijfsprocessen en continuïteit. En maak back-up redundant, dus op disk op de bedrijfslocatie en een in de cloud.
2. Complex beheer
Veel bedrijven hebben op verschillende momenten back-upproducten aangeschaft. Vaak een voor hun fysieke en een voor de virtuele servers. Daarnaast sluiten de verschillende back-upproducten meestal niet op elkaar aan. Dit vergt onnodig extra beheer op het gebied van updates en patches, licenties en hardware. Terwijl juist bij veel middelgrote bedrijven de it-beheerder al druk genoeg is.
3. Budgetbeperkingen
Veel bedrijven zijn zich wel bewust van het belang van hun kritische bedrijfsdata en applicaties. Het ontbreken van voldoende budget is vaak de reden dat een goede off-site back-up- en disaster recovery-strategie er niet is. Vergelijk het met een auto. Als je de garantie wilt hebben dat je elke dag op tijd op je werk komt, dan moet je een tweede auto kopen mocht de eerste uitvallen. Investeren in een tweede, complete back-up- en disaster recovery-infrastructuur is echter voor veel bedrijven te duur. Vooral ook omdat deze infrastructuur de hele dag stilstaat en alleen in noodgevallen wordt gebruikt. Een tweede back-up en disaster recovery in de cloud zijn de Green Wheels van de it. Geen investering in hardware, geen zorgen over onderhoud en toch altijd beschikbaar als de nood aan de man komt.
4. ‘Dom’ back-upproces
Het datavolume groeit en dus kost het steeds meer tijd om de productiedata te back-uppen. Zeker wanneer een bedrijf werkt met oudetapetechnologie, wordt er vaak nog tijdens kantoortijden de back-up van de vorige dag gemaakt. Voor bedrijven die meerdere locaties hebben in andere landen, is dit nog lastiger. Omdat medewerkers beginnen te werken als de back-up gemaakt wordt. Ook thuiswerkers willen steeds vaker bij bestanden buiten kantooruren.
Hoe kun je ‘slimmer’ back-uppen? Door te inventariseren welke data verouderd is en dus gearchiveerd kan worden. Dan hoef je daarna alleen nog maar de actuele data te back-uppen. En hoe zit het met data die al een tijd niet aangepast is? Daarnaast wordt er in organisaties veel back-updata meerdere keren weggeschreven, dit terwijl door deduplicatie (ontdubbeling) van de back-updata, het back-upvolume aanzienlijk te verkleinen is.
Slimme back-up-software maakt een snapshot van de bedrijfsdata, zeg maar een dataselfie. Vanuit die snapshot gaat het systeem back-uppen. Dit betekent een minder grote belasting van de productieserver en het netwerk. Bovendien is het mogelijk om hiermee meerdere malen per dag een back-up te maken van de belangrijkste data of applicaties.
5. Traag netwerk door back-up
Een snapshot is snel, waardoor het back-upproces het systeem niet belast en de productiviteit geen hinder ondervindt. Toch maakt tachtig procent van de bedrijven geen back-upselfie, omdat de back-upsoftware deze mogelijkheid niet heeft, of omdat er geen integratie is met de storage en/of virtualisatielaag. Er zijn back-up- en data recovery-producten die een vloeiend datatransport garanderen. Producten die zichzelf in korte tijd terugverdienen.
Ik lees enkel open deuren. Dergelijke artikelen hebben geen nieuwswaarde en beschrijven de situatie van vijf tot tien jaar geleden.
Dag Ruud,
“Alles in de cloud zetten gaat bij veel organisaties nog niet gebeuren.”
Dat is zeker waar, en uiteraard leg ik het er lekker dik bovenop.
Voor mij is het heel simpel, het is mijn opinie dat praktisch ieder bedrijf in mijn ogen beter af is door te stoppen met on-premises. Ik geloof oprecht niet dat data veiliger is on-premises. Maar goed, mijn primaire business bestaat niet uit het “verkopen” van cloud computing. Mijn bedrijf is gewoon een cloud computing consumer en ik deel mijn enthousiasme hierover en af en toe doe ik wat advies trajecten, workshops en presentaties.
Wat betreft back-up en restore: Wanneer moeten er nu echt TB’s verplaatst worden? Ik zie een aantal scenario’s voor me die gevoelsmatig het overgrote deel van de werkelijkheid beslaan:
– User gooit bestand/map/email weg
– database corrupt of ongewenst aangepast
– virtuele server faalt, moet teruggezet worden
Als je het hebt over “fact finding”. Bijvoorbeeld voor een strafrechtelijk onderzoek, dan is cloud computing helemaal “the place to be”. Ik geloof dat de manier van back-uppen en aanverwant het restoren vaak niet handig gebeuren. Nu heeft ieder scenario wel zijn eigen werkwijze om dit optimaal te doen.
Databases maken incrementele backuppen ieder kwartier en gaan tot een week/maand terug.
E-mails worden ook opgeslagen in een juridische vault.
Bestanden laat je met life-cycles subtiel “afzakken” naar high latency storage (maar zeker geen tape!)
Zo heb je sinds kort ook onbeperkte data opslag die wat trager is bij Amazon (niet Glacier). Je betaald daar 1 cent per GB per maand. Die kun je nog steeds direct benaderen, alleen duurt het iets langer voordat je het bestand opgehaald hebt. Mind me, dit is volledig met eigen certificaten versleutelde data. Dus als je de sleutels niet hebt ben je kansloos de data in te zien.
Uiteraard heb je nog een last resort scenario, bijvoorbeeld als je de toegang tot de cloud provider wordt ontzegt. Tja, recovery time objective is in zo’n geval een uitdaging, maar ook daar valt wel een (duurdere) mouw aan te passen.
Dus ja, niet ieder bedrijf is er klaar voor of heeft de ballen om de stap te maken, maar zouden dit wel moeten doen. Maar goed, dat is mijn onderbouwde mening. Voor bedrijven die vasthouden aan on-premises, dat zijn niet mijn klanten.
Henri,
Ik wil even terug komen op een paar van je uitspraken. Maar op zich ben ik het een keer gematigd met je eens. Alleen onderschat je het wel een beetje.
“Wat betreft back-up en restore: Wanneer moeten er nu echt TB’s verplaatst worden? Ik zie een aantal scenario’s voor me die gevoelsmatig het overgrote deel van de werkelijkheid beslaan:
– User gooit bestand/map/email weg
– database corrupt of ongewenst aangepast
– virtuele server faalt, moet teruggezet worden”
Je vergeet nog virussen, slechte patches, beheer(s)fouten te vermelden. Of nog erges locatie brand af en er is geen DR. Maar zo zijn er tig scenario’s te verzinnen. En dan kunnen de TB’s best nog wel eens oplopen. Dat verschilt ook per organistie (omvang).
“Als je het hebt over “fact finding”. Bijvoorbeeld voor een strafrechtelijk onderzoek, dan is cloud computing helemaal “the place to be”. Ik geloof dat de manier van back-uppen en aanverwant het restoren vaak niet handig gebeuren. Nu heeft ieder scenario wel zijn eigen werkwijze om dit optimaal te doen”
Zit wat in. En ja als bulk archief kan cloud zeker een optie zijn. Maar wil je wel bepaalde “kritieke/gevoelige” data wel in de Cloud hebben? Veel organisaties hebben nog last van “cloudwatervrees”. En niet iedereen doet dat even snel.
“Zo heb je sinds kort ook onbeperkte data opslag die wat trager is bij Amazon (niet Glacier). Je betaald daar 1 cent per GB per maand. Die kun je nog steeds direct benaderen, alleen duurt het iets langer voordat je het bestand opgehaald hebt. Mind me, dit is volledig met eigen certificaten versleutelde data. Dus als je de sleutels niet hebt ben je kansloos de data in te zien”
1 Cent per GB? Is dat alles of zijn er nog verborgen kosten zoals bandbreedte gebruik, aantal lees of schrijf acties per GB wat je doet? Anders is het met de bandbreedte beperkingen in het achterhoofdhoudend zeker een leuke optie voor een bulkarchief.
“Uiteraard heb je nog een last resort scenario, bijvoorbeeld als je de toegang tot de cloud provider wordt ontzegt. Tja, recovery time objective is in zo’n geval een uitdaging, maar ook daar valt wel een (duurdere) mouw aan te passen”
Dus ook hier moet je hoe je het wendt of keert een stukje data classificatie toepassen.Al is het alleen maar om de juiste technologie bij de datastroom te vinden.
Hoi Ruud,
Ja er zijn nog genoeg haakjes. En vanuit je ervaring kom je met een aantal scenario’s waar ik nog niet over heb nagedacht. Maar goed, niets onoverkomelijks.
Overigens denk ik dat er maar weinig echt gevoelige informatie bestaat, de meeste opwerpingen die ik hoor komen vooral uit de onderbuik. Daarnaast, ik geloof dat je met de juiste provider hogere veiligheid kunt realiseren dan 95% van de bedrijven.
De 1 cent is overigens voor de data-opslag en niet voor het verkeer. Strekking blijft wel dat het peanuts blijft en zoals ik eerder zeg: Als je alles bij een provider verlaat data het datacentrum niet en betaal je dus niet voor het verkeer. Alles valt of staat met dingen op de juiste manier toepassen. Wat dat betreft niet anders dan on-premises net met de huidige manier van werken. Die is ook alleen maar effectief als je het goed toepast, iets waarvan wij weten dat maar weinig bedrijven dat doen…
Zijn we het zo waar weer een keer met elkaar eens. Dank voor je toevoeging.
Alleen bij de 1 cent moet je nog wel de kosten voor bandbreedte/verbinding naar de Cloud rekenen.
@Henri
Betreffende de genoemde use cases aangaande granular restore ben ik benieuwd of dit wel in alle cloud proposities zit, ik wees voorgaande reactie op ‘self-service’ om zodoende de beheerlast te verlagen. De eufemistische ‘business restore’ aanbiedingen houden meestal geen rekening met gebruikersfouten. Analogie van het bonnetje van Teeven in voorgaande opinie is namelijk nogal systemisch door het simpele feit dat schrijven, zoeken en lezen heel verschillende dingen zijn.
Misschien mag ik term ‘medium defragmentatie’ introduceren als we kijken naar het digitaal dossiergericht werken, aangaande het lager is trager principe van automatic storage tiering had ik voorgaande opinie ook al wat geschreven. De lessen met Nirvanix leerden dat lezen vaak heel wat trager is waardoor RTO overeenkwam met de tijd die nodig was om bonnetje van Teeven te vinden, de waarheid is nog steeds zoek. Dat geldt zeker voor wat betreft de data architectuur als we kijken naar information sprawl als gevolg van de defragmentatie.
Om CIO/CTO een beeld ervan te geven gebruik ik meestal de analogie van een supermarkt vol met conservenblikken, zonder de etiketten welteverstaan. De fact finding in de cloud is hierdoor als elk blik open maken om te kijken wat erin zit. En aangaande de privacy moet vaak geproefd worden of het nu hondenvoer of goulash is, de vaak optredende scope creep
zorgt voor cloudwatervrees als we overwegen waarop eerdere EPD initiatief afgeschoten is.
@Ruud
Hoor regelmatig de abstracte verhalen over ‘data-rentmeesterschap’ met het idee van een Ecosystem Oriented Architecture in de cloud, navraag leert dat het veelal ‘data-regenten’ oplossingen zijn. Civielrechtelijke recht om vergeten te worden betreft als ik me niet vergis ook de back-up;-)