IBM Tivoli Storage Manager vs. Veritas Netbackup

[Rtificial]

Mogelijk een van de meest besproken discussie-onderwerpen als het aankomt op backup-strategieën.

Door groei van de organisatie, aanscherping van procedures en een nieuw uitgewerkt DRP met daaruit voortvloeiende verplichtingen ben ik bezig voor onze omgeving een backup-oplossing te selecteren.

Waar het in feite op neer komt is dat ik nog een aantal leveranciers hiervoor in de running heb, waarvan een aantal het aanbod baseren op Veritas Netbackup, en een aantal op TSM.

Schets omgeving:
Platform: Windows
Capaciteit: 200GB met groeipad naar 400GB
Betrokken servers: 6 stuks, waaronder 1x SQL en 1 Domino
Gekozen medium: Ultrium

Er komt een aparte backup-server voor deze 6 machines, die over een 1000Mbit backup-lan de backup gaat verzorgen op een Ultrium library.

Ik vraag hier niet om een pasklaar antwoord.

Ik vraag ook eigenlijk niet naar ervaring met 1 van de 2.

Ik ben op zoek naar mensen die ervaring hebben met beiden, en een onderbouwde mening kunnen geven over de gemaakte keuze.

Alle rapporten die ik zelf tot nog toe heb kunnen vinden nemen 1 van beide als uitgangspunt, en zijn in mijn optiek dus niet objectief.
De antwoorden van de leveranciers zijn niet eenduidig.

Wellicht dat iemand hier wat meer inhoudelijke ervaring heeft...

[DeBolle]

Beide backuppakketten doen hun werk goed - ze kunnen een backup maken. Bekijk daarom vooral de achterkant: de restore. Je zegt zelf al dat je het uit het oogpunt van DR wil bekijken en op dat vlak ben ik werkzaam.
Je zult eerst moeten bepalen wat het uitgangspunt van jouw DRP is, gedeeltelijk verlies van systemen, totaal verlies van de systemen of zelfs lokatie.
Daarna zul je moeten bepalen welke (vervangende) hardware beschikbaar is om de backupserver opnieuw op te bouwen.
Inhoudelijk is tussen beide pakketten inderdaad een behoorlijk verschil bij een Total Disaster, TSM moet absoluut beschikken over de database en alle tapes in de te restoren pool. Een Recovery met TSM houdt dus in dat de backupserver ten allen tijde volledig gerestored moet worden. Als je geen database meer hebt dan valt er niets meer te restoren van de pool.
De tape met de database is dus dermate belangrijk dat je die echt off site wilt hebben zodra dat mogelijk is.
Netbackup (ik neem aan dat je Enterprise aangeboden hebt gekregen) is bij een Total Disaster iets eenvoudiger: mocht de tape met de index niet aanwezig zijn dan kun je besluiten de tapes zelf te importeren in een kale database, te vergelijken met bijvoorbeeld Arcserve of BrightStor.
Ook bij Netbackup echter is de backupserver het belangrijkste systeem, zodat ook hier erg belangrijk is de Recovery van dit systeem erg goed te regelen.
Voor wat betreft de hardware zul je alles al hebben overwogen, waarbij ik echter nog aandacht wil vragen voor de doorvoersnelheden. Backuppakketten met multiple streams naar een LTO drive kunnen erg veel data verzetten waarbij een Gbit netwerk ook volgeblazen wordt.
De leessnelheid van je disksystemen is ook een punt van aandacht, neem als vuistregel aan dat alle systemen in staat moeten zijn continue 50 MB/sec ( 3GB per minuut) per stream en per tapedrive moeten kunnen leveren.
Dat houdt dus ook in dat de backupserver die hoeveelheid naar de tapedrives kwijt moet kunnen, in de praktijk heb ik gezien dat het neerkomt op een Ultra2 controller per tapedrive.

Voor meer informatie en uitgebreidere ervaringen met TSM en Netbackup mag je mij mailen, zo mogelijk kan ik in overleg dan later wel een samenvatting in dit forum zetten zodat anderen er ook wat aan hebben.

[zomertje]

Ik heb een beetje ervaring met beiden. En qua leerproces vond ik Veritas makkelijker. Tivoli begrijp ik nu nog niet helemaal (of t is niet goed uitlgelegd ) Met beide pakketten kun je wel een flinke hoeveelheid data/servers aan. We hebben TSM draaien met een server of 25 en ik heb Veritas gezien met een stuk of 300 servers.

TSM met DRM werkte bij een uitwijktest bij ons maar moeizaam. Het restoren van een server gaat vele malen sneller met een ghost en daarna de data met TSM dan volledig met TSM. De conclusie van deze uitwijktest is ook dat wij recente ghosts zullen gaan maken van de belangrijkste servers.

[Rtificial]

Bedankt, nuttige reactie.

Over de eenvoud/complexiteit van beide applicaties in het gebruik, op welk gebruik doel je dan precies?

[seq_uence]

Heb vorige week nog een collega (van een ander bedrijf) uitgehoord over hun keuze, het ging in 1e instantie om de keuze voor een SAN op FC basis, maar de bijkomende backup-oplossing was ook van belang. Zij hebben gekozen voor Tivoli van IBM omdat ze met de hardware ook helemaal op de IBM lijn zitten, maar ook omdat volgens de leverancier het Tivoli pakket net iets meer doorvoersnelheid naar de LTO drive kan bereiken.....

edit:

typo

[ Voor 4% gewijzigd door seq_uence op 01-11-2004 21:04 ]

[Rtificial]

seq_uence schreef op 01 november 2004 @ 21:02:
Heb vorige week nog een collega (van een ander bedrijf) uitgehoord over hun keuze, het ging in 1e instantie om de keuze voor een SAN op FC basis, maar de bijkomende backup-oplossing was ook van belang. Zij hebben gekozen voor Tivoli van IBM omdat ze met de hardware ook helemaal op de IBM lijn zitten, maar ook omdat volgens de leverancier het Tivoli pakket net iets meer doorvoersnelheid naar de LTO drive kan bereiken.....

edit:

typo

En hoe zit dat met de snelheid VANAF de LTO tijdens een restore, is die ook hoger?

[seq_uence]

Rtificial schreef op 02 november 2004 @ 06:48:
[...]


En hoe zit dat met de snelheid VANAF de LTO tijdens een restore, is die ook hoger?

Ik neem aan van wel, maar het lijkt me dat het verschil niet gigantisch is. Ik zou er de keuze niet van af laten hangen denk ik. Binnenkort gaan we hier ook met LTO drives werken, maar Tivoli zal het niet worden omdat ik een beetje anti-IBM ben.
"Vroeger" stond IBM nl. voor Ik Betaal Meer, tegenwoordig zijn ze natuurlijk best concurrerend.

Wanneer je een business copy maakt kun je evt. restoren vanaf de HDD en hoef je alleen bij calamiteiten (brand e.d.)vanaf tape te restoren. Dan is de snelheid ook van minder belang.....

[zomertje]

Rtificial schreef op 01 november 2004 @ 14:44:
Bedankt, nuttige reactie.

Over de eenvoud/complexiteit van beide applicaties in het gebruik, op welk gebruik doel je dan precies?

Als beheerder wil je het liefst toch een beetje snappen hoe het in elkaar zit. Want je moet toch problemen oplossen

[Rtificial]

Okay, dat is inderdaad een belangrijk punt.

Wat ik bedoelde is eigenlijk meer of je het iets tastbaarder kan maken. Waarin merk je bijvoorbeeld heel sterk het verschil in eenvoud?

[zomertje]

Ik heb me in veritas minder kunnen verdiepen dan in tsm. Een echte diepe vergelijking kan ik dus niet maken, het is meer een gevoel. Veritas kwam veel makkelijker over toen ik er wat kleine dingen in moest doen.

Mn collega's hebben meer ervaring met tsm dan ik en geven echter aan dat ze zelfs na een aantal dagen uitleg over tsm en een gezamelijike installatie ze dit pakket niet zelf durven installeren en inrichten. Helaas weet ik niet hoe ingewikkeld dit is want ik heb dit bij beide pakketten niet gedaan. tsm zelf heeft wel een handige webinterface waarin je dingen kan aanpassen.

[Rtificial]

Vanochtend/middag heb ik een uitgebreide demonstratie TSM gehad, en moet zeggen dat ik je gevoel over de complexiteit deel.

In de nieuwe beheersinterface (5.3?) schijnt wel aardig wat hierin veranderd te zijn, deze volgt nog voor het eind van dit jaar. Evengoed heb ik het idee dat zelf al laat ik een beheerder een cursus volgens, dat deze voor de iets minder vaak voorkomende problemen/werkzaamheden hulp van buitenaf in zal moeten roepen. Dat bevalt me niet echt.

Ik heb wat diepere vragen gesteld over het verloren gaan van de database, hier komen ze binnen een week bij me op terug.

TSM oogt echter wel als een uitermate krachtige, stabiele backup en restore oplossing.

Maar de eenvoud... die is wel erg ver te zoeken...

Ik ben er dus nog niet uit... Wordt weer een weekend nadenken en vergelijken.

[zomertje]

Volgens mn collega is TSM verloren als de database stuque is...

[MaXX99]

Dat is ook de reden dat er dagelijks backups van de database en de logs dioenen te worden gemaakt ... dat wordt gedaan op database backups en/of snaphots. Beiden zijn eigenlijk net hetzelfde, maar je kan op de expiration spelen van de tapes. Zo kan je dan een daily set maken en een weekly set bv.

[MaXX99]

Even een situatieschets :
Hier op het werk gebruiken we TSM op SUN Solaris met een IBM fibre optical Ultrium Tape Library ... In totaal hebben we 8 Tb aan data waar we een daily incremental backup van maken + copypool. Wekelijks doen we ook nog een backupset welke in externe kluizen wordt bewaard en een 'incremental monthly' (een idee dat we hier op het werk hebben uitgewerkt). En eens per maand doen we een export van de incremental monthly voor tapes die ad-vitam worden bewaard.

Zoals je kan merken hebben we wel een vrij behoorlijke infrastructuur, maar bemerk wel dat TSM geen pakket is dat 'af' is ... er zijn 3 maand scripting, testen, tuning, design aan voorafgegaan en nu nog kunnen we onze backup solution nog niet volledig af noemen ... Dit is ongetwijfeld ook te wijten aan de zeer hoge eisen die we aan onze backups stellen, maar TSM doet het zowieso niet 'out-of-the-box' ... voordeel dan weer is dat je het net zo kan krijgen zoals JIJ het wil ....
Grote voordeel van TSM tov. andere backup solutions is de mogelijkheid of parallel op meerdere drives backups te kunnen lanceren.

Tivoli dan weer heeft heel wat reeds built-in en vereist niet zo een grondige kennis van je OS en Backupsolution .... maar weer ten koste van de flexibiliteit ....

Succes met je keuze !

[zomertje]

MaXX99 schreef op 09 november 2004 @ 10:03:
Even een situatieschets :
Hier op het werk gebruiken we TSM op SUN Solaris met een IBM fibre optical Ultrium Tape Library ... In totaal hebben we 8 Tb aan data waar we een daily incremental backup van maken + copypool. Wekelijks doen we ook nog een backupset welke in externe kluizen wordt bewaard en een 'incremental monthly' (een idee dat we hier op het werk hebben uitgewerkt). En eens per maand doen we een export van de incremental monthly voor tapes die ad-vitam worden bewaard.

Zoals je kan merken hebben we wel een vrij behoorlijke infrastructuur, maar bemerk wel dat TSM geen pakket is dat 'af' is ... er zijn 3 maand scripting, testen, tuning, design aan voorafgegaan en nu nog kunnen we onze backup solution nog niet volledig af noemen ... Dit is ongetwijfeld ook te wijten aan de zeer hoge eisen die we aan onze backups stellen, maar TSM doet het zowieso niet 'out-of-the-box' ... voordeel dan weer is dat je het net zo kan krijgen zoals JIJ het wil ....
Grote voordeel van TSM tov. andere backup solutions is de mogelijkheid of parallel op meerdere drives backups te kunnen lanceren.

Tivoli dan weer heeft heel wat reeds built-in en vereist niet zo een grondige kennis van je OS en Backupsolution .... maar weer ten koste van de flexibiliteit ....

Succes met je keuze !

Klinkt herkenbaar, wij hebben ook een incremental backup, database backup en snapshot. In het weekend wordt alles naar een kopie (copypool) gekopieerd en dat gaat maandag buiten de deur. Van alle data worden de 3 laatste versies bewaard. Verwijderde items blijven nog maximaal 90 dagen bestaan.

[Rtificial]

Okay, bedankt weer voor deze duidelijk beschrijving van een praktijksituatie.

Donderdag neem ik een besluit.

Het besluit zal ik proberen hier gemotiveerd te posten, indien de motivatie een technische grondslag heeft...

Nogmaals mijn dank aan een ieder die bijgedragen heeft aan mijn beeldvorming.

[Verwijderd]

TSM voor en nadelen in de praktijk bekeken.

Ten aanzien van TSM deel ik wel de stelling : T duurt even maar dan heb je wat.

Het is in ieder geval zo dat een correct opgezette TSM implementatie tijd kost, Ik heb er verschillende gedaan en ook velen "rechtgezet" nadat bepaalde features toch niet helemaal deden wat men initieel dacht/ hoopte / wilde.

Binnen IBM ben ik er meermalen getuige van geweest dat klanten die een uitwijktest kwamen doen en bijvoorbeeld hun licentie-files niet hadden of de install media van de server vergeten waren in hun uitwijk-koffertje te stoppen , let daar dus op ! Die heb je immers als eerste nodig om de rest van de systemen te kunnen restoren.

Voor wat betreft de TSM database, deze is heilig en dient ook als zodanig behandeld te worden, hierin staat exact wat op welke tape en vooral waar die zich bevindt (library, offsite, etc etc). bij een grotere implementatie dient zowel het online dbase gebeuren zich op goede, gemirrorde raid te bevinden. En het beackuppen daarvan moet de hoogste prioriteit hebben, ik heb ook al vaak
gebruik gemaakt van de hedendaagse bandbreedte mogelijkheden gebruik gemaakt doro de snapshots online > higspeed-koppeling offsite of naar de
spare/standby locatie te sturen, gebruik je die dure lijnen ook tenminste..
Cross-system is uberhaupt voor dergelijke systemen erg handig, de data nodig voor rebuild-actie staan dan al grotendeels klaar ..

Ook is een correcte reclaimprocedure en copy-stgpool wel noodzaak, dan worden er minder tapes "vastgehouden" omdat er nog een paar files opstaan die uniek zijn, en het verkort de restore tijd aanzienlijk de data staat immers op minder tapes. Mounten en spoelen duren immers een eeuwigheid tov de paar mb/gb aan files die net weer op tape 432 staan..

Wat de "gebruikerskant" van TSM aangaat, in bijna elke implementatie kan
er gemakkelijk teruggegrepen worden op vorige versies, in een aantal oplossingen waar veel aan software ontwikkeling werd gedaan werd tsm feitelijk gebruikt als een soort van CVS, zo van Oeps .. dit werkt niet meer, ik wil nu de versie van eergisteren terug, uithuilen en opnieuw beginnen, dit is door de "point in time" mogelijkheid zelfs door een semi-IT-leek uitvoerbaar te documenteren.

Tsm heeft in mijn ervaring ondanks de complexheid wel een aantal voordelen tov van vergelijkbare oplossingen van derden waar ik ook wel mee werkte in het verleden.


Heel verhaal, hoop dat men er wat aan heeft ..

[Rtificial]

Dank voor deze nuttige bijdrage.

Mijn keuze voor software-oplossing is inmiddels gemaakt.

Ik heb besloten verder te gaan met TSM.

Hoewel beide oplossingen (TSM & NetBackup) een stabiele indruk maken, en beide een krachtige backup/restore oplossing zijn, zijn er een aantal punten waarin TSM beter lijkt te passen bij onze organisatie, en eisen die nu of in de nabije toekomst gesteld gaan worden.

Een belangrijk issue bij ons begint "archiving" zo langzamerhand te worden. Midden in de implementatie van Sarbanes-Oxley kom je er achter dat je erg veel te documenteren en vooral bewaren hebt. Meer dan je in eerste instantie voor mogelijk hebt gehouden. TSM springt met archiving-functionaliteit goed in op die wensen.

Schaalbaarheid van de applicatie, zowel in de diepte als breedte zijn eveneens een belangrijk punt. Dit betekent voor ons dat er in de toekomst op het gebied van storage nog voldoende mogelijkheden open staan, in dezelfde omgeving als de gekozen backup/restore oplossing.

Feit blijft dat TSM geen overtuigende winnaar is in dezen.

Beide oplossingen zijn erg krachtig, voldoen aan de huidige eisen, en zijn aan elkaar gewaagd in prijs.

Wellicht dat een van de belangrijkste pijlers voor dit besluit het gevoel bij de aangeboden oplossing is geweest.

Nogmaals mijn dank voor alle input in dit topic.

[ Voor 1% gewijzigd door Rtificial op 12-11-2004 10:55 . Reden: typo ]

[DeBolle]

Dit topic zou ik willen voordragen voor de (nog niet bestaande) GoT verkiezingen 2004 categorie "Topic met de beste argumenten voor een weloverwogen beslissing"
Top!

[Rtificial]

Ik moet heel eerlijk bekennen dat ik dit soort topics inderdaad wel een beetje mis af en toe hier...

Iemand een voorstander van een centraal Sarbanes-Oxley / Project 404 / blabla - topic?