Verschillende soorten backup software

[localhost]

Het volgende lijstje heb ik al:

• CA BrightStor ARCServe 2000 CA BrightStor Enterprise Backup CommFault Galaxy Tivoli TSM Veritas Backup Exec Veritas Netbackup Legato NetWorker BakBone NetVault SyncSort Backup Express ATempo TimeNavigator

Een aantal bekende, ook een aantal (voor mij) totaal onbekende. Een aantal leveranciers heb ik al benaderd en ze zeggen allemaal dat ze "het beste pakket" hebben en "iedereen gebruikt onze software".

Ik vindt Tivoli TSM er erg mooi uitzien, maar die prijs... Die past dus niet in het plaatje.

Met welke software hebben jullie nu uitermate goede ervaringen (graag zonder de anderen af te kraken, dat kan ik ook). Hij hoeft niet in de lijst te staan, want misschien ben ik het meest ideale pakket wel vergeten.

PS. Het pakket moet het liefst gaan draaien op een centrale Windows 2000/.NET Server, maar met netwerk connecties naar Unix (Linux, SunOS, AIX, HP-UX) en databases Oracle, SQL Server en Lotus Domino (op Sun en NT). Als hardware komt er een robot of autoloader.

[Arno]

Ik heb goede ervaring met Brightstor ArcServe 2000. Al wat jij opnoemt is te backuppen via ArcServe

[localhost]

Traag schreef op 12 augustus 2002 @ 20:07:
Ik heb goede ervaring met Brightstor ArcServe 2000. Al wat jij opnoemt is te backuppen via ArcServe

Hoe zit dat dan met SunOS 8 en 9 ? En met AIX 5.1 en 5.2, die kom ik niet tegen.
Op http://support.ca.com/techbases/as2000/ntcompmat.html dus.

[Arno]

afaik kun je gewoon unix systemen backuppen

[Mark]

ArcServe blijf ik (al is dat dan voornamelijk onder Novell) maar een brak pakket vinden. Ik heb om de een of andere reden altijd gezeik met de (brakke) btrieve database (ga ervan uit dat dit onder W2K beter is geregeld). Persoonlijk heb ik zeer goede ervaringen met Veritas Backup Exec, maar ik weet zo niet of daar Solaris, SunOS, HP-UX, e.d. agents voor zijn.

[Verwijderd]

let wel dat je met je databases vaak agents erbij moet kopen. ( en die wil je graag hebben , anders moet je gaan scripten etc ) en een goede stategie is ook wel een uitgangspunt.

Persoonlijk vind ik commVault wel wat hebben.

[MrCyber]

Ík heb zelf zeer goede ervaringen met UltraBac. Heb hier zeer uitgebreide performance testen etc mee gedaan en is vaak tot 30% sneller dan bv ArcServe en BackupExec. Verder is het niet al te prijzig.

http://www.ultrabac.com

[Zwelgje]

MrCyber schreef op 12 augustus 2002 @ 22:33:
Ík heb zelf zeer goede ervaringen met UltraBac. Heb hier zeer uitgebreide performance testen etc mee gedaan en is vaak tot 30% sneller dan bv ArcServe en BackupExec. Verder is het niet al te prijzig.

http://www.ultrabac.com

is het ook sneller met dezelfde hardware? vaak is namelijk de hardware de beperking van de snelheid,

aha: live trial.. weer wat te doen morgen...testen!

[DeBolle]

Mijn voorkeurslijstje voor de OS'sen en databases die jij noemt en de produkten waar ik goede ervaringen mee heb bij recoveries:

http://www.veritas.com/pr...mily.jhtml?categoryId=110
en
http://www.openview.hp.co.../specifications/index.asp

Hierbij heb ik dan een lichte voorkeur voor Omniback II Cell Manager op Win2K met Agents voor de andere platformen.
Qua performance zijn deze twee on the top en alleen te vergelijken met Legato, andere pakketten zoals Arcserve en Backup Exec snappen helemaal niets van streaming multi-server backups.

[ Voor 0% gewijzigd door DeBolle op 12-08-2002 22:42 . Reden: nog wat toegevoegd over performance ]

[MrCyber]

zwelgje schreef op 12 augustus 2002 @ 22:34:
[...]

is het ook sneller met dezelfde hardware? vaak is namelijk de hardware de beperking van de snelheid,

aha: live trial.. weer wat te doen morgen...testen!

Uiteraard heb ik dit destijds getest op dezelfde hardware. Ik weet de nummers niet meer exact, maar we deden een backup van 60 Gb normale data, 18 Gb Exchange data en een 30 Gb SQL Database en hebben gewoon de stopwatch ingedrukt. Niet alleen was Ultrabac sneller met backuppen, maar wat veel belangrijker was was dat het zeer snel was met restoren.

Destijd getest op een Compaq Server (weet niet meer welk type) met een DLT Tapechanger met 5 tapes.

Testplan was 3 Servers, 1 Fileserver, 1 Exchange server en 1 SQL Server. Tapestreamer hing aan de Fileserver en de backupsw draaide daar ook. Wel met agents geinstalleerd op de andere 2. We hadden gewoon een afgescheiden lannetje via een 100 Mb Switch.

Ik zal vanavond (woon in de US, dus op het moment van schrijven is het hier pas 14:30) ff thuis zoeken of ik nog het testplan heb ergens in mijn backup data. Is van 2 werkgevers geleden, dus moet ff spitten.

[ Voor 0% gewijzigd door MrCyber op 12-08-2002 22:51 . Reden: uitleg vanavond ]

[Quinie]

Behalve het testen van de backup lijkt het mij dat je gaat testen hoe de restore is. Uiteindelijk is backuppen slechts onderdeel van je restore. ( waarom backup je )

Met arcserv heb ik nog al slechte ervaringen, echter mijn chef wil niet over op iets anders en heb ik dus ook nog geen mogelijkheid gehad te testen met andere pakketen

[MrCyber]

IK heb nog ff gezocht thuis, maar kan het rapport niet zo 1-2-3 vinden. Zit vast nog ergens op een CD in een van de 30 verhuizdozen die we nog niet uitgepakt hebben. Van het weekend gaan we weer uitpakken, dus als ik het tegenkom laat ik het wel ff weten.

[localhost]

MrCyber even over UltraBac:

Unix Server Agent - Primary AVAILABLE Q3 2002

dat is dus even geen optie.

Verder lees ik dat iedereen dus problemen heeft met ARCServe (vml. de database). Dit komt tevens overeen met mijn eigen ervaringen, vandaar dat ik dus iets anders wil.

scsi-freak: Kan je iets meer vertellen over je ervaringen met CommVault Galaxy ?
DeBolle: Kan je iets meer vertellen over je ervaringen met Netbackup en OmniBack ?

een goede stategie is ook wel een uitgangspunt

De strategie is alles backuppen, goed uitgangspunt toch ?

[MrCyber]

localhost schreef op 13 augustus 2002 @ 18:55:
MrCyber even over UltraBac:
[...]
dat is dus even geen optie.

Oops had ff die vereiste over het hoofd gezien.

De strategie is alles backuppen, goed uitgangspunt toch ?

Lijkt me niet echt een goed uitgangspunt. BV als je mbv een SQL agent een database backupped is het niet echt nuttig om dan ook nog eens de db file te backuppen. Zelfde geld voor Exchange. Daarnaast hangt het e.e.a. ook af van je diaster recovery strategie. Als je disaster recovery strategie bestaat uit OS installeren + SP en daarna data terugrollen heeft het dus niet veel zin je system files te backuppen. Zo zijn er nog wel een aantal zaken te noemen die nogal wat impact hebben op je strategie, bv hoeveel data moet je backuppen, backup je over je LAN, wat betekend dat voor je netwerk performance, worden daardoor geen andere processen verstoord, etc.... Verder bestaat je strategie niet alleen uit wat je backupped, maar ook wanneer (en hoe groot is je backup window), wordt er 24x7 gewerkt of heb je een paar uur elke nacht om te backuppen, hoe vaak backup je, doe je een dagelijks full backup of 1x per week/maand een full en de rest incremental.....etc.....etc.....etc....

Nogal wat zaken om goed over na te denken en om van te voren op papier te zetten.

[ Voor 0% gewijzigd door MrCyber op 13-08-2002 20:09 . Reden: nog ff wat dingetjes toegevoegd ]

[localhost]

MrCyber schreef op 13 augustus 2002 @ 20:07:
....
Nogal wat zaken om goed over na te denken en om van te voren op papier te zetten.

Het meeste staat al vast.

Nee, natuurlijk backuppen we geen dingen dubbel. Alles gaat via netwerk, ja dat is veel, en de Full-backup duurt bijna 24 uur. Incrementals duren maximaal 3 uur, maar dit zit geen overige processen in de weg. Backup kan nu maximaal uit 350 GB bestaan, maar kan binnen een dag groeien naar 550 GB (alles staat daarvoor al klaar). Restore, per roulatie een server, testen we maandelijks. Tapes worden on-site en off-site bewaard. Alles met goedkeuring van de directie (hun handtekening staat onder ons uitvoerings plan).

Wat mis ik nog

[Verwijderd]

commvault maakt gebruik van een sql 2000 database voor het catalogen van de tapes, en werkt met 1 hoofdserver en wat member servers , een soort tree effect. ( ook nadeel , want je kan een member server niet (zomaar) promoten tot hoofd server zoals bij veritas )
verder kan je naar disk backuppen en later op tape. prioriteiten aan backups geven , en single mailtje restoren.

maar ik vind de applicatie eigenlijk meer een bijzaak. een goede stratigie is veel belangrijker , servers indelen in belangrijkheid, eventueel backup-windows bouwen, bottlenecks calculeren , geen compressie rekenen , verify erbij , en dan het meest belangrijke : de restore ( je uitgangspunt ) restore duurt meestal 2x een backup ( in tijd )
Database , gebruik agents , maar iedere week een offline backup ( open files ) , maak backups van tablespaces etc .. ( snellere restore ) . neem de juiste drive voor je backup ( AIT/DLT/LTO ) reken je rotation sheme goed door ( genoeg tapes ) ( meestal het GFS schema ). Maak de afweging : full backups , full + incremental backups ( snelle backup , langere restore ) of full en differential backups ( langere backup , snellere restore ) .

verder is SAN ( fibrechannel ) een goede infra structuur hiervoor.

[MrCyber]

localhost schreef op 13 augustus 2002 @ 20:45:
Wat mis ik nog

Denk dat je zo alles wel zo'n beetje hebt

[localhost]

MrCyber schreef op 13 augustus 2002 @ 22:17:
[...]
Denk dat je zo alles wel zo'n beetje hebt

Maar ik heb ARCServe

[Verwijderd]

Ik heb thuis gewoon de standaard back-up van W2k server draaien.. (zonder problemen..)

Oeps, dit had ik niet moeten zeggen denk ik.

[DeBolle]

localhost schreef op 13 augustus 2002 @ 18:55:
DeBolle: Kan je iets meer vertellen over je ervaringen met Netbackup en OmniBack ?

Voor alle duidelijkheid, ik werk bij een disaster recovery bedrijf en daarom hebben de meeste van mijn ervaringen betrekking op full restores van scratch. Meestal op andere hardware dan de originele systemen.
TSM/Tivoli zat boven jouw budget merkte je al eerder op - hoewel het inderdaad een mooi, goed en duur pakket is, komen Legato, Netbackup en Omniback volgens mij ook aardig in de die buurt qua prijs. Onderhandelingen met een leverancier (of een integrator als je daarvoor kiest) over de totaalprijs zijn natuurlijk altijd mogelijk
Ten eerste de performance.
Zowel Omniback als Netbackup kunnen afgrijselijk snel backup en restore doen. Beide producten tonen onherroepelijk aan waar de bottleneck zit in het pad van disk naar tape en terug. Bij jou zal dat het netwerk zijn - 100Mb? Als je niet binnenkort overstapt op Gb Ethernet wil ik je in overweging geven heel serieus te kijken naar *of* een lokaal aangesloten tapedrive aan elke server, *of* het pad van disk naar tape up te graden naar SAN-achtige verbindingen. 100Mb is voor backups en restore helemaal niks, een willekeurige tapedrive (DLT7000, DLT8000, SDLT, LTO) slikt met Omniback en Netbackup tussen 15 en 30MB/sec.
Als je daarom met een netwerk aan de slag gaat zullen de tapedrives voortdurend staan te wachten tot er weer een blokje data binnenkomt.
Je zult begrijpen dat de disken aan elk systeem ook in staat moeten zijn dit te leveren.
Wat willekeurige ervaringen. Restore 2TB aan raw devices (Oracle/SAP) vanaf een STK Timberwolf met 4 DLT7000 drives over glas naar een Compaq ESA12000 via een Sun E10K deed ca. 2,2 GB/minuut met Netbackup. De Sun heeft overigens JNI kaarten, de standaard SOCal zijn ehm ...
Restore 600GB aan data naar NT4, Win2K, AIX en HP-UX systemen met Omniback vanaf een Win2K systeem met vier lokaal (SCSI) aangesloten DLT7000 tapedrives, over een 100Mb (FD) netwerk met Cisco switches, ca. 700MB/minuut.
Restore 800GB aan Oracle/SAP databases vanaf een STK L180 met 4 LTO tapedrives over glas naar drie HP-UX systemen, Amdahl LVS4800 en Compaq ESA12000 met Omniback 4.1 deed ca. 2,5Gb/minuut.
Dit ligt allemaal dicht bij het praktische maximum wat je hebt bij een stevige RAID5 array trouwens, bij wat natte vinger testen met een RS/6000 F50 met een Emulex LP8000 point-to-point naar een Compaq RA8000 array konden we met ca. 46MB/sec een disk to disk copy doen.
Een losse LTO (IBM 3580 en 3581) via een FWD/LVD converter op systemen als een Proliant 530 en een HP9000 N4000 doet constant tussen 1 en 1,5Gb per minuut.

Beide pakketten hebben dezelfde structuur, een 'master' server die babbelt met disk-agents op de andere systemen en de media-agents op de server(s) waar de tapedrives aan hangen. Beide doen ook aan compressie (in de disk-agent) alvorens het de bus (netwerk, SCSI of glas) opgaat, waardoor de tapedrive optimaal kan worden aangestuurd.
De interfaces bij beiden zijn zowel onder X als onder Windows beschikbaar. Zoals gezegd, al met al heb ik een lichte voorkeur voor Omniback omdat dit pakket het dichtst bij mijn manier van denken aan ligt. Netbackup was (voor mij althans) wat 'onlogisch' in de bediening.
Beide hebben scheduling, vaulting en pre- en post processing aan boord, evenals de mogelijkheid van tape-to-tape copy en remote vaults.
Ik heb op dit moment niet echt zin om nog drie pagina's met ervaringen/problemen en valkuilen te vullen, maar als je meer of specifiekere informatie nodig hebt dan kun je gerust een gil geven.
['geen zin' in de zin van: - ik ben moe en lui, niet in de zin van: - ik wil jou niets vertellen]

[localhost]

DeBolle schreef op 13 augustus 2002 @ 23:35:
[...]

Dank voor je uitgebreide reply.

Alles is hier 100MB switched. Een tweede netwerkkaart (200 MB) voor de backupserver ligt klaar, maar die zit er nog niet in. We hebben 2 grote data-servers, 1 op NT en 1 op Unix. Voor deze 2 ligt een GB kaart klaar (maar dan moet de server down en dat kan eigenlijk niet, dus moet ik dat ergens ver vooruit in oktober/november plannen).

De performance van de backup zakt voornamelijk in elkaar als we bij de dataservers aankomen (en die zijn niet traag) ik denk dat dit komt door de enorme hoeveelheden kleine files (van 1 kbyte) en daar heb ik zo'n 10 tot 20 GB mee vol staan op beide servers. Het is niet anders, we hebben het nodig.

En ja, in geval van brand restoren op nieuwe hardware. Dat gaat lang duren vrees ik, men heeft tot nu toe geen uitwijkplan willen maken/uitvoeren. Dus we zullen maar eens beginnen met het zoeken van enkele stuks hardware en bedrijfsruimte als het zover komt.

Vraagje1: Heb je ook ervaringen (tijdens de restores dan) met de fabrikant van de paketten ? Bijvoorbeeld als de restore performance erg laag is, hebben ze dan een helpdesk die je kan helpen met fix/tips ? Bij CA is dit dus diep triest, verder dan "alles verwijderen en opnieuw installeren" komt men niet. En nee, dit lost de problemen niet op.

Vraagje2: Hoe makkelijk is het toevoegen van extra filesystemen (Unix) of disken (NT) aan een backup. Zien Omniback en Netbackup dit automatisch ? Of moet ik deze handmatig toevoegen. We hebben nml. nogal een dynamische omgeving waar zeker op Unix iedere dag van alles wijzigt. ARCServe kan hier niet goed mee overweg en z'n database schiet volledig in de stress.

Vraagje3: Omdat ons huidelige backup window al bijna 24 uur is, doen we dus incrementals op weekdagen. Hoe gaan Omniback en Netbackup om met incrementals op Unix ? ARCServe kan geen incrementals op Unix zonder kunst en vliegwerk (ik zal je de details besparen).

Vraagje4: CA wil ons graag overzetten van ARCServe 2000 naar BrightStor Enterprise. Heeft iemand ooit met BrightStor Enterprise gewerkt ? Als je m'n opmerkingen over CA hierboven gelezen hebt, snap je waarom ik iemand zoek die ervaring heeft met BrightStor Enterprise, ik heb er namelijk absoluut geen vertrouwen in.

[Verwijderd]

debolle, veel ervaring etc. mooie uitleg, alleen de performance ligt iets anders denk ik.

je weet niet wat voor een data hij heeft (compressie ratio ) . en je gaat vertellen over een esa12000 ( compaq fibre array met hsg80`s ) dat is een niet standaard omgeving . De performance van je backup is natuurlijk wel afhankelijk van je aplicatie, maar dat scheelt niet zo heel veel. Lan is natuurlijk vaak een bottleneck , maar disken is meestal het probleem. zelfs een dikke raid-set hoeft geen garantie te zijn voor snelheid. een SDLT doet 11MB/S native , eventueel met compressie 22MB/S. Je moet een flinke raidset hebben wil ie dat kunnen leveren , zelfs die 11MB . een raidset van 10 disken in raid5 zal het misschien zelfs niet halen ( is ook niet zoeen grote raidset eigenlijk ) . Ga je naar de DLT7000 of 8000 ( resp 5mb/s en 6mb/s native 10/12 mb met compressie ) is dat 5mb x 3600 (sec/min ) = 18gb/h . Dit is natuurlijk als je de drive Streaming houd en genoeg data aanlevert ( meestal niet ) . Natuurlijk is een library eeen hele vooruitgang. meerdere drives tegelijk bezig ( pool maken ) of RAIT gebruiken (raid 0,1 en 5 beschikbaar ) ( raid 0 niet aan te raden ).

client met een IDE drive .... nouja bottleneck al leg je er een gigabit tussen

verder helpen pushagents ( veritas ) ook zeker wel. behalve dus als je veel compressed data op die server/client hebt, dan wordt het slechter.

[Tags NL]

Hoewel Tivoli TSM dus nogal duur is heeft het wel een voordeel waarvan ik niet weet of de overige backup progamma's die ook hebben: backuppool!

Kijk, je hebt een machine en die backupped naar de TSM Server. Het komt dan eerst in een backuppool, op disk dus, en wordt dan later naar een tapepool gemigreerd. Zo kun je dus eerst met een behoorlijke snelheid backuppen 's nachts, eventueel met 10 sessies tegelijkertijd naar een Gigabit aangesloten TSM Server, om vervolgens overdag te migreren naar tape.

We hebben het op werk dan ook nog zo dat de tapepool een kopie krijgt op een copypool en die tapes komen dan in de kluis. Dus de actuele data zit in de taperobot en de copydata is veilig in de,externe, kluis.

Wat wil je nog meer

[DeBolle]

localhost schreef op 14 augustus 2002 @ 06:42:

De performance van de backup zakt voornamelijk in elkaar als we bij de dataservers aankomen (en die zijn niet traag) ik denk dat dit komt door de enorme hoeveelheden kleine files (van 1 kbyte) en daar heb ik zo'n 10 tot 20 GB mee vol staan op beide servers. Het is niet anders, we hebben het nodig.

Bij een restore is het al niet anders - het aanmaken van de vele inodes kost buitensporig veel tijd. Het enige wat helpt is een goed getuned filesystem (kom ik *zelden* tegen) en veel write cache op de disk controllers. Als het om RAID gaat dan kun je wellicht experimenteren met de blocksize van de raidset. Voor tapedrives geldt dat de beste waarden zijn: DDS 16K, DLT 64K, LTO 256K.

En ja, in geval van brand restoren op nieuwe hardware. Dat gaat lang duren vrees ik, men heeft tot nu toe geen uitwijkplan willen maken/uitvoeren. Dus we zullen maar eens beginnen met het zoeken van enkele stuks hardware en bedrijfsruimte als het zover komt.

Da's nu precies mijn werk, uitwijkplannen opstellen Ik kan daar dus verder geen commentaar op geven zonder te vervallen in reclame uitingen, sorry. Wel wil ik kwijt dat het op voorhand niet nodig is om zelf ruimte en apparatuur aan te schaffen voor die doeleinden.

Vraagje1: Heb je ook ervaringen (tijdens de restores dan) met de fabrikant van de paketten?

Ja, en die ervaringen zijn even triest als die van jou. Buiten veel zoeken in hun knowledgebases ('Will be solved in the next release') en af en toe een blauwe blazer in een Alfa 147 ('Tsja, dit is natuurlijk unsupported') ben ik nog geen leverancier tegengekomen die simpelweg een aantal losse tips kon uitdelen. Wel hebben wij zelf een lijst met tips & trucs voor een aantal pakketten en hardware (voornamelijk gericht op recovery). Die is te groot om lukraak hier neer te zetten, maar als je specifieke vragen hebt, vraag maar raak. Een tip die meestal wat verstopt zit in de manuals van de backuppakketten: zorg dat de database van het backuppakket na elke backup op een *aparte* tape wordt gezet. Arcserve zet het standaard als aparte sessie achteraan de backup, waardoor je de gehele tape eerst moet scannen voordat je de database kunt restoren. Netbackup en Omniback kunnen een database weer opbouwen vanaf de backuptapes (net als 'merge' in Arcserve), bij TSM/Tivoli mag de database nimmer verloren gaan.

Vraagje2: Hoe makkelijk is het toevoegen van extra filesystemen (Unix) of disken (NT) aan een backup. Zien Omniback en Netbackup dit automatisch?

Beide pakketten maken bij Unix gebruik van naar keuze het gehele systeem (alles onder een nodenaam), fysieke disken (raw devices), volumegroups of logical volumes (HP-UX en AIX hebben beiden LVM tenslotte) of databases. Bij databases kun je onderscheid maken tussen online en offline backups, journal logs en wat al niet meer. Het is standaard dus mogelijk om periodiek (bijvoorbeeld zondag) automatisch een offline backup te maken van een database en de rest van de week een online backup met alle logfiles. Bij een restore kun je dan simpelweg de offline restoren, de online d'erover heen gooien en tot de laatste minuut een roll forward te doen.
Bij nieuwe filesystemen hangt het af welk niveau je hebt gekozen. Als je bijvoorbeeld van een systeem alle mountpoints backupt, dan moet je zelf een nieuw mountpoint toevoegen aan de backup. Ga je bijvoorbeeld per volumegroup, dan zullen alle nieuwe mountpoints, lvols en raw devices automatisch meegaan.
Tip tussendoor, kijk even naar Ignite UX bij de HP-UX systemen - snel en gemakkelijk op te zetten en een prima manier om snel vg00 te restoren in geval van nood.
En NT/Win2K/Novell ... tsja, daar zul je per volume/driveletter/directorie moeten werken of het hele systeem, een tussenweg (vg, lvol) is er niet.
Bij Win2K/Novell kennen alle pakketten tegenwoordig het verschil tussen NDS/AD, system state en data, die daarom in de praktijk vrij goed te restoren zijn.

Vraagje3: Omdat ons huidelige backup window al bijna 24 uur is, doen we dus incrementals op weekdagen. Hoe gaan Omniback en Netbackup om met incrementals op Unix?

Geen enkel probleem. Incrementals, differentials, vanaf een bepaald tijdstip, alles is eenvoudig in te stellen voor elke backup. Mag ik opmerken dat een backup window van bijna 24 uur naar mijn maatstaven te lang is voor een bedrijf dat 24/7 in de lucht wil/moet zijn?
De door iemand anders al genoemde TSM pool kan een oplossing zijn, evenals de 'snapshot' technologie, bij de leveranciers bekend onder namen als snapshot, TDMF Open, Data Protector, Data Mover enz. In principe doet de backupserver dan een 'freeze' van alle systemen, maakt van alle filesystemen een 'snapshot', laat alles systemen weer lopen en gaat vervolgens rustig de snapshot op tape zetten. Deze methode is vooral geschikt als je een (remote) mirror hebt natuurlijk, dan kun je ook de bekende methode gebruiken van: freeze systemen / breek mirror / unfreeze systemen / mount en backup mirror / resync mirror.

Nou ehm ... dat was weer genoeg getypt voor vanavond, ik hoop dat je er wat aan hebt

[Tribbles]

Vergeet niet systeem backups te maken van je backup server . En berg die backups ver weg op... Onze backupserver staat fysiek op een andere plek dan de servers die hij backupped. En de backups van de backupserver gaan uiteraard in de kluis...

[DeBolle]

Verwijderd schreef op 14 augustus 2002 @ 07:40:

je weet niet wat voor een data hij heeft (compressie ratio ) . en je gaat vertellen over een esa12000 ( compaq fibre array met hsg80`s ) dat is een niet standaard omgeving .

Precies, gezien de genoemde systemen (NT/Win2K, HP-UX, Linux, AIX en databases) heb ik een aanname gedaan met betrekking tot de data. Ik zie op m'n werk nogal wat verschillende systemen voorbijkomen en heb daarom een 'educated guess' gedaan
Overigens is die esa12K eigenlijk al verouderd, de SBB's worden moeilijker verkrijgbaar en de prijs van het ding op de tweedehands markt is idioot gezakt. Maar terechte opmerking, het is geen standaard stripesetje

De performance van je backup is natuurlijk wel afhankelijk van je aplicatie, maar dat scheelt niet zo heel veel. Lan is natuurlijk vaak een bottleneck , maar disken is meestal het probleem.[...snip...] Natuurlijk is een library eeen hele vooruitgang. meerdere drives tegelijk bezig ( pool maken ) of RAIT gebruiken (raid 0,1 en 5 beschikbaar ) ( raid 0 niet aan te raden ).

Inderdaad, de meest gemaakte fouten liggen in de hardware. In de eerste plaats moeten tapedrives en disken op hun eigen SCSI controller. Dat elke SCSI bus goede bekabeling en terminators moet hebben lijkt vanzelfsprekend, maar m'n bek valt toch elke keer weer tot op m'n schoenen als ik een configuratie audit ('De backup is traag ... zou dat komen doordat de terminator zoek is?').
Verloop en verlengsnoeren (wide aansluiting naar narrow DDS-3, dan met een centronics naar 68 pins kabel op een DLT) van het bekende 'El Cheapo' worden volop gebruikt.
Tweedens wordt er nauwelijks gekeken naar de blocksize van tapedrives. Als je cpio of tar gebruikt, zorg dan dat de blocksize groot genoeg is. Gooi er desnoods een 'dd' achteraan en 'cat' dat naar de tapedrive - in de meeste gevallen scheelt dat de helft of meer qua tijd. Optimaal is DDS 16K, DLT 64K, LTO 256K.
Dan hardware compressie op een tapedrive - stel dat je een vette database gaat backuppen die een compressiefactor van 1:5 haalt.
Om de tapedrive streaming te houden, moet dan bijv. bij een DLT ca. 50MB/sec over de bus gejakkerd worden. Dat lukt niet. In dit geval is het dan aan te raden te experimenteren met software compressie, zodat de data al gecomprimeerd over de bus gaat.

[LastBoyScout]

localhost schreef op 13 augustus 2002 @ 20:45:
Wat mis ik nog

127.0.0.1 ,

Weet niet of het al je features doet, maar check Tapeware eens. (zie www.tapeware.com) Is errug goed. heeft een stapeltje connectors en is multiplatform. Heb er ruim ervaring mee (gebruik het bij tig klanten), dus kan er wel wat over vertellen als er interesse is...

[ Voor 0% gewijzigd door LastBoyScout op 14-08-2002 23:57 . Reden: smiley's doen ut nie als er een komma'tje achter staat :'( ]

[jep]

tar .

[Verwijderd]

De bolle ,

Je hebt gelijk met de blocksize . die kun je afstemmen op de tapedrive, maar in praktijk zullen ze je voor gek verklaren .. ik heb er ervaring mee . backup vinden ze nou meestal net niet zo belangrijk .

Het outdated zijn van de ESA12000 ( of MA8000 , MA6000 , RA8000 , EMA12000 of EMA16000 ) heb je een beetje gelijk in , maar het is allemaal gebaseert op de HSG80 en 60 .Alleen de disken zijn anders en maen het verschil. ( 7200rpm tegen 10.000 in de MA serie ) dat is dus beter voor kleine files. Probleem is dat je de HSG80 zo ver kan tweaken (of de-tweaken ) dat het zowiezo moeilijk is om te gokken. ( je kan per LUN alle cache settings veranderen ( read-ahead gedrag , Cache gedrag etc . )

De nieuwe tapedrives ( DLT8000 (* ) SDLT en LTO en VXA ) kunnen zich aanpassen aan de feed rate , en gaan dus niet in start/stop mode ) .

[localhost]

scsi-freak, DeBolle, MrCyber en jep (tar, fatastische opmerking gewoon ) bedankt voor de input, ik zal laten weten (over 2 maand of zo) wat het geworden is.

Laatste oproep: Wie heeft er bedrijfmatige ervaring met CA Brighstor Enterprise ? Als er niemand reageert (mag ook per email) dan kies ik voor iets anders

[Verwijderd]

localhost schreef op 12 augustus 2002 @ 19:54:
Het volgende lijstje heb ik al:

• CA BrightStor ARCServe 2000 CA BrightStor Enterprise Backup CommFault Galaxy Tivoli TSM Veritas Backup Exec Veritas Netbackup Legato NetWorker BakBone NetVault SyncSort Backup Express ATempo TimeNavigator

je vergeet er 1 NT backup. persoonlijk vind ik die erg goed, alleen er zitten wel nadelen aan, zoals niet kunnen backuppen van openfiles (online sql, exchange, etc), maar meestal zijn daar wel workarounds voor...
overigens in jou geval is het geen optie!

[reddog33hummer]

wij gebruiken op het werk Veritas in combinatie met een backuprobot. Alles is SCSI en gigabit dus weinig bottlenecks. Novell 6 Cluster, NAS, WIN2K, Solaris en linux servers. Mijn ervaringen met betrekking tot een restore zijn deels positief deels negatief.

Positief:
Server was gehackt, backup opgehaald binnen notime weer up.

Negatief:
Gebruikers die een bestand kwijt zijn . Met veritas kan het nog wel eens ff duren.

[-W0kk3L-]

Ik ken alleen Tivoli Storage...hou er wel rekening mee dat de software een maximum van 10.000 files per directory aan kan. Dat is een foutje in de software van Tivoli/IBM. Kom je daarboven, dan loopt je backup vast. We hebben er ervaring mee...

Voor de rest werkt et prima, zolang je een goede netwerkstructuur hebt liggen tussen de servers ,de backup-unit en de tape-robot zelf.

[Bockelaar]

localhost schreef op 16 augustus 2002 @ 08:10:
....
Laatste oproep: Wie heeft er bedrijfmatige ervaring met CA Brighstor Enterprise ? Als er niemand reageert (mag ook per email) dan kies ik voor iets anders

Ik heb wel praktijkervaring met ArcServe. Op zich een heel mooi pakket, redelijk gevoelig met configuratie enzo, maar ook weer redelijk eenvoudig. De disaster recovery hebben we in praktijk nog niet nodig gehad, maar op een testbak deed hij het prima! De agents die we draaien (open files, exchange, SQL) doen het allemaal proma, alleen de Exchangeagent wil nog wel eens lastig doen met de bricklevel backup (heeft te maken met de mailbox scan van InoculateIT --> errors in Named Pipes en dat soort lekkere meldingen. Hiervoor (nog) geen permanente fix kunnen vinden). Ons bedrijf is een CA-partner, dus kennis is er bij ons wel binnen, misschien dat dat ook wel helpt met de implementatie
Daarnaast weet ik dat KPMG voor hun Global Omgeving heeft gekozen voor Arcserve 2000, en dat dat daar ook erg soepel draait (ruim 150 servers, veel data en databases), ook zij hadden erg veel ondersteuning vanuit CA met de implementatie.
Kortom: afhankelijk van de grootte van je netwerk denk ik dat het verstandig is om de implementatie en configuratie over te laten aan specialisten, in een kleinere omgeving kun je het grootendeels zelf wel redden (zou je moeten )

^{en nee, ik werk niet voor CA, en verdien geen geld aan deze post}

[localhost]

Bockelaar schreef op 19 augustus 2002 @ 09:45:
[...]


Ik heb wel praktijkervaring met ArcServe.

Dank voor je verhaal, maar zoals je gelezen had hierboven, is ARCServe dus geen optie. Het grappige is trouwens dat ik van al jou bovenstaande ervaringen bij alles juist het omgekeeerde ervaren heb.

[Noener]

Om even een oud topic op te halen

Ik ben zelf bezig om een backup plan op te zetten. Nu ben ik Geïnteresseerd in Veritas Netbackup. IBM Tivoli Storage Manager en CA Brightstor.

Nu heb ik GoT al lekker doorgespit en al redelijk wat kunnen vinden. Nu ben ik op zoek naar wat meer documentatie en dergelijke. Op de sites van de leveranciers is niet veel informatie af te halen, daarom ben ik op zoek naar meer informatie van de pakketten. Kan iemand mij hieraan helpen.

[richard_kraal]

ik weet zeker van arcserve zeker dat er "howto" en "specs/product info" documenten te vinden zijn

[Koffie]

kom op zeg, wat heeft het voor nut om daarvoor een oud topic omhoog te schoppen ?
En ik kan me niet voorstellen dat een manual niet online te vinden is.