Back-up van data veel mensen en bedrijven worstelen er nog steeds mee. Goed om de basics nog eens te bekijken. De precieze invulling is dan nog te bepalen en ook zaken als hoelang moet je de back-ups bewaren. Waarop maken we die back-up? Ik geloof in de juiste tools voor het werk dat gedaan moet worden. Meestal is dat een combinatie en niet maar één product. Zo ook voor back-up producten.
Waarom maken we een back-up? Om een restore te kunnen doen natuurlijk, want we doen al dat werk niet voor de lol. Hoewel er mensen zijn die back-ups maken omdat het moet en niet verder kijken. Waaraan moet een solide back-up voldoen? Daarover kunnen we discussiëren maar in basis is het 3-2-1. 3: Drie kopieën van de data; 2: Op tenminste twee verschillende media, dus niet die drie kopieën op dezelfde disk of hetzelfde systeem ; 1: Waarvan één op een andere locatie, dan ben je beschermd tegen problemen met de locatie.
Uit een recente studie blijkt dat 70 procent van de bedrijven een combinatie van disk en tape gebruikt voor hun back-up. De overige 30 procent gebruikt alleen disk, tape of cloud als back-up doel. Dus het merendeel maakt hun back-up eerst naar disk en daarna naar tape. De rol van tape is dus nog zeker niet uitgespeeld. Sterker nog door eerst naar disk en dan pas naar tape de back-up te maken houdt disk tape in leven omdat ze elkaar versterken. Disk is goed in het herstellen van een enkele file en heeft weinig moeite met wisselende snelheden. Tape is zeer goedkoop en uitermate snel voor een volledige restore
Verder is het ook zo dat er nog steeds geen afname van verkochte tape capaciteit is waar te nemen. De laatste cijfers laten zien dat er per kwartaal 5 ExaByte aan enterprise tape media verkocht wordt en 6 ExaByte aan server disk capaciteit (alles wat voor servers gebruikt wordt in- en extern). Dus de markt gelooft nog steeds volop in tape.
Cloud is een nieuwe back-up doel. Vandaag de dag zeer geschikt voor kleine bedrijven maar ook als extra kopie. Dan is het belangrijk dat je voldoende bandbreedte hebt en met name voor de restore. Want een restore van een paar Terabytes vanuit de cloud kan wel even duren. Hoe maak jij je back-up?
Ik zal een simpel voorbeeld geven hoe ik mijn eigen privé bestanden back-up (qua omvang zijn het vooral digitale foto’s). Ik maak op twee externe usb-diskjes een kopie van mijn foto’s met SyncToy. Dat zijn dus in totaal drie kopieën. Het zijn verschillende merken diskjes, dus het is zeer onwaarschijnlijk dat ze op hetzelfde moment beide de geest geven. Eén van die diskjes sla ik op buiten mijn huis, de andere ligt gewoon in de lade van mijn bureau. Dus breekt er brand uit thuis of neemt een dief mijn laptop en externe disk mee dan heb ik nog mijn andere disk over met mijn foto’s.
Uiteindelijk zijn de onderliggende vragen: RPO, RTO en kosten. Recovery Point Objective: als er iets gebeurt, hoe veel tijd mag er verloren gegaan zijn of naar welk moment moet ik terug kunnen. Is dat een dag, een uur, een kwartier, een minuut of nog minder. Recovery Time Objective: hoe lang na een calamiteit moet ik mijn data terug hebben. Ook hier is dat een dag, een uur, een kwartier, een minuut of nog minder. En wat mag dat kosten. Want iedereen wil natuurlijk een RPO en een RTO van vrijwel nul, maar meestal willen we dat überhaupt niet betalen.
Voor de meeste bedrijven is het ook nog eens zo dat de ene data belangrijker is dan de andere en dus data of applicaties verschillende klassen van RPO en RTO hebben. Het probleem is vaak dat de it-afdeling niet de juiste prioriteiten kan stellen en vaak alles op één hoop gooit. Dus de discussie moet gevoerd worden met de business. Tenslotte wanneer heb jij voor het laatst gecontroleerd of je een restore kunt doen?
@ Pavake,
Goed voorbeeld en zeer herkenbaar. Zoals Reza al zei zal iedere verandering in je architectuur gevolgen hebben voor je back-up data.
Het veranderen van back-up pakket, DB, mail, CRM etc. etc. heeft meestal grote gevolgen voor je historische data.
Hier heb ik in het verleden al geregeld wat over geroepen en geschreven.
@PaVaKe,
Blijkbaar werk je bij een professionele omgeving, daar moeten veel organisaties een voorbeeld aan nemen.
Ik heb een jaar geleden een recovery test namens een gemeente in het datacenter van een externe leverancier begeleid. Je moest zien hoeveel lijken uit de kast kwamen! Hoge bedragen die de betreffende leverancier bij de klant in rekening heeft gebracht was voor niks! Toen begon de touwtrek tussen de opdrachtgever en de leverancier. Resultaat: afscheid nemen van de leverancier en een andere oplossing hiervoor bedenken: samenwerken met andere gemeente op dit gebied! Heel voordelig, slim en ook het fundament voor de benodigde draagvlak en verder samenwerking tussen die twee gemeenten.
Virtualisatie is een deeloplossing van wat je in een totale DR/BC oplossing/programma nodig hebt. Er zijn nog meer lagen waar de klant in dit kader rekening mee moet houden.
Jammer dat in dit artikel geen “verwijzing” is naar dit soort zaken. Gelukkig hebben we nog de experts 🙂
Test mislukt.
…
Beste Remko, (…jouw schuld natuurlijk),
Wat nu, maandag moeten de mannen weer globaal 150 trailer lossen en in check’n.
Probeer reeds de hele zaterdagavond en zondag de boel te herstellen.
Nog niet klaar.
Je bent me er eentje…
@Jurgen,
Het is altijd makkelijk om de schuld op je leverancier af te schuiven! Wat er gebeurd is heb je deels te danken aan je houding in dit verhaal.
Veel van dit soort problemen kun je vooraf voorkomen als je als klant, proactief, samen met je leverancier aan de realisatie van dit soort zaken meedoet. Wanneer je dit doet dan zie je veel aspecten die voor je leverancier onzichtbaar zijn en er geen rekening mee is gehouden. Zo kunnen jullie elkaar aanvullen.
Voor de duidelijkheid, met “je” bedoel ik de klant en niet jij > Jurgen!
@Jurgen,
Zo te lezen heb je een RTO die verre van nul is, wat ik helaas niet kan zeggen van je toevoegingen aan dit artikel. Maar misschien dat je deze opmerkingen maakte om Remko te prikkelen voor een reactie hoewel ik het idee heb dat je dat dan wel op een contraproductieve manier doet, maar dat is uiteindelijk mijn opinie. Opinie van Ruud over het onderwerp is al gegeven en als je wat meer achtergrond informatie nodig hebt bekijk dan even slide 3 t/m 8:
http://www.slideshare.net/edekkinga/data-veiligstellen-is-nog-een-hele-klus
Want hoewel het, zoals Reza al aangeeft makkelijker is om de leverancier achteraf de schuld van problemen te geven denk ik dat we kunnen concluderen dat een back-up niet iets is wat je achteraf even implementeert maar waar je vooraf goed over na moet denken, net als het testen ervan. Nu is eerste echter ‘common practices’ omdat de back-up vaak aan het operationele niveau overgelaten wordt, de storage en systeem beheerders die alleen maar een hele grote berg data zien en weinig tijd (back-up window) hebben. En dus bestaat deze uit 30 puntoplossingen en even zo veel visies waarbij (thuis)oplossing van Remko met een Redudant Array of Inexpensive Disks er vast ook tussen zal zitten;-)
@Remko
Volgens mij heb je klanten!
wat een hoop reacties op gewoon een n00b artikel. backup321, dat je je data niet kwijtraakt en owja restore is ook niet niet onbelangrijk …
Ing Presales consultant storage HP, computable Storage Expert. Nu wel duidelijk waarom HP altijd veel duurder is dan de concurrent.
@ Remco,
Misschien aardig om even terug te komen op de reacties. Aangezien de discussie nu aardig op gang is gekomen.
@ Ewout,
Thanks voor de verwijzing naar de presentatie. Ik heb in het verleden al veel over dit onderwerp geschreven. Echter bleef een soortgelijke discussie toen uit. Leuk om te zien dat deze nu wel los komt.
@mauwered
Dit onderwerp kan niet vaak genoeg genoemd worden. Want het aantal keren dat ik mensen paniekerig heb zien kijken na de opmerking ‘dan zet je de backup toch gewoon terug’ kan ik niet meer op een hand tellen.
Backups, je doet het goed of je doet het niet.
@ Sjoerd,
Helemaal eens. Je back-up omgeving moet je ook periodiek blijven testen, en aanpassen op mogelijk extra benodigde functionaliteit.
Doe je dat niet dan kan je er nog wel eens slapeloze nachten van gaan krijgen.
Heren,
Voor mij een goed voorbeeld, bevestiging en het bewijs dat Architectuur vaak wordt onderschat of er te gemakkelijk over wordt nagedacht. Laatst een project gedaan bij een gemeente waarvan de ICT Infrastructuur moest worden vervangen. Hier is een backup ook een onderdeel van! Men vergeet dit vaak of denkt hier te lichtzinnig over. De consequenties en risico’s zijn niet helemaal duidelijk. Richt niet alleen je vizier op het applicatie landschap, maar juist de borging hiervan, alvorens je gaat ontwerpen. Wat #Reza als voorbeeld goed aangeeft is eigenlijk een lifecycle van je backup oplossing. Deze moet je meenemen in je ontwerp en innovatie, waarbij het belangrijk is dat de nieuwe oplossing compatibel blijft met techniek van mogelijk een decennia oud!
Dit is complex en bijna onmogelijk. Je moet dan eigenlijk innovatie compatibiliteit toepassen om een ‘verzekering’ van data in stand te houden. Het is echter wel mogelijk als je werkt onder Architectuur, immers wordt je, als het goed is, hierdoor geholpen of ‘gedwongen’ (denk PSA). Wat ertoe zou kunnen leiden is als mogelijke oplossing ook een platform ontwerpen, welke beschikbaar moet zijn om een ‘decennia’ oude backup infrastructuur te ‘hosten’.
De discussie tapes wil ik mij even niet in mengen, want dat vind ik een discussie op zich.
Verder ben ik het eens met #Ewout, denk ook aan Archivering van je backup en data kwalificatie. Veel klanten denken over een goede backup strategie te beschikken maar vaak komt men bedrogen uit.
Als laatste maar zeker niet onbelangrijk is inderdaad de vraag: “Weet u zeker dat uw backups feilloos kunt restoren?” “Heeft u garanties?”. Wat je ziet is dat de nieuwste backup oplossingen deze wel gaan bieden. Zie ook Veeam met Surebackup. Voorlopig nog de enige die garanties kan afgeven, zonder dat je hiervoor fysiek het restore proces geheel moet uitvoeren. Wie volgt….