Als eerste wil ik iets vertellen over mijn huidige ervaringen:
Ik heb de afgelopen jaren gewerkt met backup oplossingen van Veritas (nu Symantec), Legato, ArcServe, BackupAgent, Veeam, ManageEngine en waarschijnlijk nog een paar… Word je wel steeds kritischer als er een nieuwe vendor langskomt. Ik ben in ieder geval al zijn 20 jaar aan het back-uppen en heb dit gedaan met oplossingen lokaal (naar tape of NAS) op virtuele platformen en in de cloud.
Iets over backup in het algemeen:
Vaak wordt backup en disaster recovery besproken in 1 onderwerp. Dit is niet terecht want beide functionaliteiten verschillen aanzienlijk van elkaar. Waar een backup bedoeld is om historische data te bewaren (vaak 5 tot 7 jaar) is het bij disaster recovery voornamelijk gericht om de meeste recente data snel terug te halen. Hier zie je dan ook meteen het belangrijkste verschil en de meeste uitdagingen van backup vendoren. Een backup dient te worden ondersteund door een hele goede database waarin je snel versies van bestanden kan terugvinden welke zelfs jaren geleden verwijderd zijn. Bij een disaster wil je graag zo snel mogelijk de meeste recente data terug plaatsen zodat de impact zo laag mogelijk is. In de praktijk zie je vaak dat hier overeen wordt gekeken en dat er eigenlijk maar 1 van de 2 in gebruik is genomen.
Op dit moment zie ik dat veel bedrijven migreren van een op locatie server omgeving naar een cloud server omgeving. De cloud provider biedt vaak een hogere server beschikbaarheid dan welke het bedrijf zelf op locatie kan realiseren. Er zijn allerhande aan redundante componenten opgenomen in de infrastructuur om 99,999% beschikbaarheid te bieden. Steeds meer cloud providers begrijpen ook dat er een backup gemaakt moet worden van de data, toch is het bijna altijd bedoeld voor een disaster recovery scenario. Vaak is er bijvoorbeeld een 30 dagen retentie opgenomen. In veel gevallen kan dit ook voldoende zijn, voornamelijk waarbij het database gedreven applicatie servers zijn, moet dit ook voldoende zijn. Toch leert mijn ervaring dat ook database gedreven applicaties soms afhankelijk zijn van data welke langer geback-upte dienen te worden dan deze 30 dagen.
Een voorbeeld hiervan heb ik uit een praktijk situatie van een klant van mij: er was een onduidelijkheid opgevallen in November in de database welke veroorzaakt was in Januari. In Januari heeft de externe software leverancier een update uitgevoerd in de test omgeving en na goedkeuring deze ook uitgevoerd in de productie omgeving. In November wilde de administratie vast voorbereidingen treffen voor de afronding van het jaar. Tijdens deze voorbereiding kwam de fout in de database naar voren. Natuurlijk is er eerst contact opgezocht met de software leverancier om te zien of dit een bekend probleem was en of dit elders ook voorkwam. Ook is er gekeken of er updates of patches waren uitgevoerd welke dit probleem veroorzaakte. Niks wat te vinden. Wel was het probleem niet te reproduceren in de test omgeving welke sinds januari niet meer geupdate was. Na uitgebreid onderzoek bleek dat de productie database op enig punt keek naar een gebruikers OU in de local user database welke of verwijderd was of niet aangemaakt was in de productie omgeving. Dit probleem had zich al moeten laten zien in Februari maar aangezien deze actie allen werd aangeroepen tijdens een jaar afsluiting werd dit pas in November gezien. Probleem was echter dat deze klant enkel maandelijkse back-ups maakte van de database servers. Het was hierdoor niet mogelijk om de user te herstellen zodat de fout kon worden hersteld. De oplossing bleek uiteindelijk te zitten in het restoren van de database op de test server waar deze user nog wel op bestond, alle maand afsluitingen opnieuw te draaien en vervolgens de database en de user te herstellen naar de productie database. Dit was een in menstraject en hierdoor is de productie van de bedrijf meerdere dagen verstoort geweest.
Het is dan ook gewoon te kort door de bocht om te zeggen dat een 30 dagen retentie altijd volstaat en sinds dien adviseer ik dan ook om dit als disaster recovery aan te houden maar de echte backup nog wel te blijven gebruiken.
Er zijn veel verschillende methodes om te backuppen:
Met de komst van virtualisatie zijn we instaat om de verkregen hardware capaciteit van een server of serverpark veel efficiënter te gebruiken. Ook is het mogelijk geworden om de schijfcapaciteit te centraliseren (hetzij fysiek hetzij virtueel) waardoor de backup strategie ook aangepast kan worden. Waar vroeger de impact van de backup groot was op de bestaande productie omgeving zijn we nu instaat om dit supersnel uit te voeren. Toch is het niet altijd mogelijk of verstandig om een backup te maken van enkel de gevirtualiseerde infrastructuur. De meeste backup software is zich tegenwoordig wel bewust van de onderliggende bestandssysteem of de onderliggende database maar een snapshot methode levert vaak niet de juiste informatie om snel een bestand of database object te kunnen herstellen. Om deze functionaliteiten goed te kunnen backuppen is het nogsteeds (20 jaar geleden was dit namelijk ook al zo) om met agents te werken. Agents gedreven backup geeft je een goede indexering van de verschillende versies van bestanden op verschillende tijds momenten. Ook biedt de agent tegenwoordig een data compressie waardoor het dataverkeer tussen server en het de backup opslag vaak al geoptimaliseerd wordt.
Oké een lange introductie voor het beschrijven van een ‘nieuwe’ backup vendor….
Nieuwe is deze backup vendor zeker niet. Sinds 1992 zijn ze alleen maar bezig met het ontwikkelen van de meeste betrouwbare en veelzijdige backup oplossing in de markt. Het product wordt enkel verkocht doormiddel van een partner netwerk in meer dan 50 verschillende landen in de wereld. Wat voornamelijk opvalt is dat ze nooit iets hebben gedaan aan marketing/ naamsbekendheid. De mond op mond reclame en samenwerking met partners heeft ze voldoende geholpen om een succesvolle onderneming te zijn. Nu zie je dit ook wel iets terug in de look and feel van dit product.
Alles ziet er nog uit of dat het ontwikkeld is in 1992. Toch als je onder de motor kijkt zien je dat er veel technisch ontwikkeld wordt. Zo is er ondersteuning voor bijna alle bekende backup targets. Denk hierbij aan HPE StoreOnce – NetApp Snap Store maar ook aan cloud backup targets als Azure en AWS. Wat voornamelijk opvalt is dat er backup gemaakt kan worden van alle windows besturingssystemen welke er tot nu zijn uitgekomen. Er is dan ook support voor de backup van Windows XP en Windows NT tot Windows 10 en Windows Server 2019. Hiernaast worden er bijna alle Linux/ Unix versies ondersteund en zelfs nog alle versies van Netware en Alpha VMS. Deze Duitse software fabrikant heeft een groot deel van zijn ervaring dan ook in de backup van Unix en Novell Netware. Wederom allemaal producten waarbij de technische kennis voornamelijk de bovenhand voort en de verkoop en marketing afdeling een ondergeschikt kindje zijn.
Juist hierom wil deze software fabrikant de support op dit product zo veel mogelijk in eigen hand houden. De partners dienen dan ook te voldoen aan een zeer strikt certificeringsprogramma willen ze zelfstandig support mogen uitvoeren. Hierdoor worden problemen en ervaringen in het product altijd uit eerste hand ontdekt en worden deze direct opgevolgd. Het product voldoet dan niet alleen aan Duitse degelijkheid, maar ook de support op het product is heel direct en altijd direct met kennis van zaken.
Veel van de eerdere genoemde backup fabrikanten hebben een hele goede marketing en verkoop afdeling maar bieden op het gebiedt van support vaak niet de juiste toegevoegde waarde.
Voor nu heb ik voldoende geschreven of mijn eerste ervaring met deze backup vendor. Mijn volgende blog artikel gaat veel meer over de technische oplossing van deze fabrikant. Ben je nu nieuwsgierig geworden na het lezen van dit artikel, download dan de product brochure van de fabrikant en hou andere berichten op mijn blog over backup nauwlettend in de gaten.
[email-download-link namefield=”YES” id=”4″]
