4. Uitkomsten van de workshop

Memo 19923135
IT/Advies/GDr
Aalsmeer, 15 juni 1999
Bladzijde 1 van 7
Aan
Van
Kopie aan
:
:
:
Expl. chefs, Backup uitvoerenden
Gerard van Draanen
Interex Forum Network/OpenView
Onderwerp
:
Omniback op NT; Resultaat workshop
1.
Inleiding
Reeds lange tijd is er een behoefte aan een Centrale Backup omgeving.
Op dit moment wordt HP Omniback op HP/UX gebruikt voor de bedrijfssystemen, en ArcServe
binnen VW4. Voor de projecten RAS/VAS/EC (op NT platforms) is in principe gekozen voor
Omniback, maar een 'productie' installatie heeft nog niet plaats gevonden.
Ondersteund vanuit diverse discussies en afwegingen, is er gekozen voor HP Omniback, maar
op een NT platform. Eenduidigheid onder architectuur, servicegraad, kosten, en de centrale
bewaking op dienst niveau zijn bij de afwegingen de belangrijkste elementen geweest.
Om kennis en ervaring rondom het product uit te wisselen is er op 4 Juni bij de VBA een
workshop gehouden. Daarbij zijn een aantal externe 'gebruikers', interne betrokkenen, en vanuit
HP een consultant op het gebied van Omniback, ingegaan op de mogelijke problematiek bij een
dergelijke overgang.
2.
Samenvatting
Vanuit de besprekingen, en ervaringen, is gebleken, dat het product op alle terreinen aan de
gewenste functionaliteit voldoet. Een feitelijke overgang vraagt beperkte resources, maar kan
vanuit tijdsbeperkingen (deadlines lopende projecten, vakanties, …) toch problemen geven.
Toch is het verstandig om de implementatie snel te starten:
- Binnen de HP omgeving loopt men binnenkort tegen huidige beperkingen aan.
- EC moet 'in productie'; het zou dubbel werk zijn, om nu een ander product te kiezen.
- RAS/ VAS hebben ook reeds in de ontwikkelstadia behoefte aan backup faciliteiten.
Tevens dient er consensus bereikt te worden, of in ieder geval naar alle projecten en
omgevingen een duidelijke keuze gemaakt te worden.
De 'beperkingen' zitten dus vooral op het organisatorische vlak.
3.
Agenda workshop 4 Juni
13:00
Kennismaking
13:15
Presentatie .. Principes ( .ppt op aanvraag beschikbaar)
13:30
Discussie uitgangspunten, rekenwerk
13:45 Koffie/ Thee
14:00
“Hoe om te gaan met” discussies
15:30
“Hoe om te gaan met” presentaties
16:00 Naar ECA
16:15
Opstelling, detailering/ Toelichting
16:45
Bespreking vervolg; Evaluatie
Memo 19923135
IT/Advies/GDr
Aalsmeer, 15 juni 1999
Bladzijde 2 van 7
De Agendapunten zijn uitgewerkt als volgt:
- Problematiek / Historie van backup bij de VBA
- Uitleg principes/ terminologie binnen de OpenView Omniback oplossing
(Backup cell agent, Appllication agent, Backup device server, Backup Manager, Manager of
Managers, ...)
- Rekenwerk: Opslag, Groei %, Looptijden, Netwerk bandbreedte, Machine eisen, Tapes
- Toets op capaciteit (etc.) van de Compaq DLT IV model 3570-2 tape robot
(1 Terabyte aan opslag)
- Uitdetailering van de backup schema's
(wanneer, wat, van waar, waar naartoe, hoeveel, verantwoordelijke, ....)
- Hoe om te gaan met:
- Fallback / Fail-over, Calamiteiten
- Restore aanvragen (looptijden, verantwoordelijkheden)
- Backup van systemen in de Firewall - DMZ
- Backup agents (opzet, distributie, timing)
- Gedeelde of Gedelegeerde verantwoordelijkheid (zetten van restricties/ rechten)
- Bewaking van het Backup mechaniek
- Netwerk bandbreedte beperkingen/ controle
- Specifieke applicatie agents ( IIS, SQL server, SMS, Oracle, Sybase, Exchange)
- De NT registry backup
- Test en Acceptatie criteria
- Vormgeving/ verantwoording van testresultaten; hoe te testen.
- Mogelijke vervolg acties/ sessies
De 'minimum' uitkomst uit de sessie, was gesteld als:
- het uitwisselen van een stuk kennis en ervaring.
- materiaal voor een presentatie over Omniback, en het 'workshop' proces op 23 juni (tijdens het
Interex seminar 'Storage Area Networks, back-up and restore')
4.
Uitkomsten van de workshop

Kennismaking, Presentatie principes
De workshop bestond uit 11 man: 7 externen, 1 HP consultant, en 3 "VBA'ers" waaronder ikzelf.
Door omstandigheden, kon geen van de direct betrokkenen in het backup proces van de VBA bij
de sessie aanwezig zijn. Dat is wel een gemiste kans geweest.
Al snel was er in de groep gerichtte aandacht. De presentatie van het Interex Forum, en de
principes/ terminologie binnen de Omniback oplossing kwamen goed over. De stoelen zijn
daarna in een kring gezet, en er is veel kennis uitgewisseld over Omniback.
De concrete situatie van de VBA, en de binnen het project "RAS" opgebouwde test/acceptatie
omgeving van Omniback op NT is als uitgangspunt in de verdere behandeling genomen.

Discussie uitgangspunten, rekenwerk
Voor de dimensionering van de omgeving die nodig is voor een backup is achtereenvolgens
gekeken naar hoeveelheid data (huidig en verwacht), doorlooptijd (backup tijdvenster), netwerk
bandbreedte, server-tape aansluiting (SCSI).
Vanuit een productkeuze is nagegaan of de dimensionering 'past', op welke manier de
organisatie kan werken, en wat moet worden gedaan aan bijzondere omstandigheden.
Memo 19923135
IT/Advies/GDr
Aalsmeer, 15 juni 1999
Bladzijde 3 van 7
Uit eerder onderzoek (Juni '98) kwamen de volgende backup 'dimensionering' cijfers:
60 - 100 GB voor HP/UX
60 - 80 GB voor (toen nog) Novell.
Binnen de VBA zijn we inmiddels overgegaan van Novell/ Windows 3.11, naar een Windows NT
server en Windows NT desktop omgeving. Schattingen geven aan dat dit gepaard gaat met
'ongeveer' een verdubbeling van de benodigde disk capaciteit.
Met een zekere 'veiligheidsmarge' komen we dan uit op 300 GB voor een 'full' backup.
Als vuistregel wordt aangegeven dat ca 10% van de data betrokken is bij een 'incremental'.
Uitgaande van deze informatie is besloten om te dimensioneren op 400 GB.
Bij de VBA wordt normaalgesproken de full backup gedraait van vrijdag op zaterdag. Volgens
eerder onderzoek is er daarbij een backup tijdvenster van 11 uur beschikbaar.
- Uit de workshop kwam naar voren, dat vanuit beheer oogpunt (eenvoud) het te prefereren is
als er altijd een 'full' backup wordt gedraaid. Het tijdvenster moet dat dan wel toelaten.
Overigens zijn er andere elementen, waardoor ook een voorkeur voor incrementals kan zijn:
De tape spoeltijd, om een enkel bestand te vinden, is korter bij incrementals.
400 GB backup, binnen 11 uur, komt uit op 36 GB/hr of 10 MB/s. Om dit te kunnen doen over
een netwerk is dan een 'minimale' server aansluiting van 100 Mbit/s (Fast Ethernet) nodig.
In dat geval wordt de volle bandbreedte van een netwerk aansluiting benut.
Om niet 'alle' bandbreedte van het netwerk af te nemen, zal de 'backbone' meer ruimte moeten
hebben. Bij de VBA is sprake van een 155 Mbit ATM backbone. (Met upgrade mogelijkheid).
Om de data van de 'bacup device server' voldoende snel naar de tape te krijgen, is ook daar een
10 MB/s verbinding nodig. SCSI-1 transporteert 'maar' 5 MB/s, dus er is minstens een SCSI-2
verbinding nodig naar de tape unit.
De verschillende tape-media en opslagtechnieken hebben ook verschillen in de mogelijke
capaciteiten en doorvoersnelheden. [Tabel Johan]
Voor de hier gevraagde doorvoersnelheid, en voor een beperking in het aantal benodigde tapes,
is hierbij een DLT IV tape unit nodig.
Binnen de VBA is gekozen voor een Compaq DLT IV unit, model 3570-2.
De unit biedt plaats aan 15 cartridges, met ieder ca 70 GB (bij een compressiefactor van 2).
De totale (theoretische) capaciteit komt daarmee uit op ca 1 Terabyte aan gegevens.
De leverancier geeft een doorvoersnelheid aan van 72GB/hr maximum, 50 - 60 GB/hr 'typical'.
Voor een full backup zijn in dat geval ca 6 tapes nodig ( 6 x 70 = 420 GB ).
- Uit de workshop kwam naar voren, dat het duidelijk te prefereren is om incrementals niet te
combineren op een tape. Dit is zowel vanwege de looptijd, administratie, als vooral vanuit de
gevolgen bij beschadiging van de tape.
Uitgaande van een backup schema van 'incremental' op ma-do, en 'full' op vrijdag, zijn er dan
per week ca. 10 tapes in gebruik. Daarnaast kunnen er nog incidentele backups worden
gemaakt bij belangrijke wijzigingen in de infrastructuur.
Bij de gekozen tape unit zou er dus slechts eenmaal per week tapes gewisseld worden. Door
de week heen, zijn de backup tapes constant beschikbaar.
Memo 19923135
IT/Advies/GDr
Aalsmeer, 15 juni 1999
Bladzijde 4 van 7
Met de huidige wijze van backup, zijn de tapes verspreid over het hele veilingcomplex, en moet
er dagelijks 'gewisseld' worden. De hiervoor aangegeven keuze geeft dus directe tijdsbesparing
rondom de backup.
In de workshop wordt de conclusie getrokken, dat het rekenwerk correct is, en dat de gekozen
tape-robot zal voldoen. De verwachtte 'bottleneck' is de verbinding met het netwerk, en mogelijk
de doorvoersnelheid van de backup device server zelf (intern, backplane).
Tevens wordt aangegeven dat we hier nog spreken van theoretische waarden, waarbij de claims
van de leverancier nog in de praktijk getoetst moeten worden.
In de test/acceptatie omgeving is er (nog) geen verbinding met de tape-robot, en kan alleen de
doorvoersnelheid van server, en DAT tape worden bepaald.
Ook is in de workshop aangegeven, dat er diverse mogelijkheden bestaan, om mogelijke
bottlenecks te vermijden:
- onderling afstemmen van full backups (b.v. deel op vr-za, deel op za-zo )
- gebruik van meerdere backup device servers (meerdere tape-robots, of decentrale tapes)
- andere aansluiting van de servers (b.v. direct ATM)
- uitdetailering van de backups, hun oorsprong, bestemming, en tijdschema
Het Omniback product wordt gezien als voldoende schaalbaar.
Wanneer er in de organisatie sprake is van meerdere backup verantwoordelijken, of service
niveaus, dan worden er vanuit Omniback geen beperkingen opgelegd.
Er kan gebruik gemaakt worden van meerdere backup schema's.
Er kan gebruik gemaakt worden van centrale + decentrale verantwoordelijken. Op diverse
niveaus zijn rechten toe te kennen.

Hoe om te gaan met ….. discussies en conclusies

Fallback/ Fail-over/ Calamiteiten.
Er zijn diverse mogelijke invullingen voor het verkrijgen van hoge beschikbaarheid van het
proces. Hierbij een opsomming van de mogelijkheden op de diverse gebieden:
Backup Manager:
Netwerk:
Backup Agent:
Backup device srv:
Backup device:
MC/Serviceguard oplossing (maar dat geldt alleen voor HP/UX)
NT Cluster omgeving
Een van tevoren geconfigureerde 'Cold Standby' server
'Omhangen' van de disks naar een 'Cold Standby' server
RAID (2, 5, auto) disks (voor bewaking data integriteit)
2e NIC (met andere route/ tussen-componenten)
N.B. : Alternatieve bestemming is ook mogelijk voor bewaking
N.B. : De 2e NIC geeft geen hogere doorvoersnelheid
Alleen mogelijk voor zover de omgeving waar de agent op staat, zelf
reeds een verhoogde beschikbaarheid (fail-over) heeft.
Als de agent niet bereikbaar is, dan is ook de source-data niet bereikbaar.
Er kan gebruik gemaakt worden van meerdere device-servers.
Er kan bij 'afwezigheid' ook automatisch door-verwezen worden.
Bij device- of tape- fouten, wordt er een boodschap afgegeven. Vanuit de
centrale bewaking kan dan een (evt. Automatische) actie worden gedaan,
om de backup te herstarten op een andere tape (of andere locatie).
Memo 19923135
IT/Advies/GDr
Calamiteiten:
Aalsmeer, 15 juni 1999
Bladzijde 5 van 7
Wanneer we ervan uitgaan, dat de tapes meerdere dagen in de tape-robot
blijven, dan moet er een fysieke scheiding zijn tussen de robot, en de
oorsprong van de data.
Als er immers een calamiteit in de ruimte plaatsvindt (brand, water, etc)
dan zouden zowel de machine, als de backup verloren gaan.
In concreto mogen de backup device server (+ tape) niet in dezelfde
ruimte staan als de machine die ge-backup'd wordt.
Dit kan ondervangen worden door de tape-robot buiten de computer
ruimte te plaatsen (b.v. in een SER ruimte), of door gebruik te maken van
een tweede robot. De backups van de ene computer ruimte, gaan dan
naar de robot in een andere ruimte, en omgekeerd.

Restore aanvragen
Uit de workshop discussie kwam naar voren, dat de afhandeling van restore aanvragen, per
bedrijf verschillend kunnen zijn. Elementen die daarbij een rol spelen zijn:
- Hoe vaak wordt er om een restore gevraagd
- Hoe veel data moet er ge-restore'd worden (file, directory, applicatie, database, disk, of 'full' )
- Hoe snel moet de restore plaatsvinden (service niveau)
Dit kan verschillend zijn per 'dienst' (Kantoor applicaties of (kritische) bedrijfsapplicatie)
- Wanneer wordt er gevraagd om restore
- Van hoelang geleden, wordt er om een restore gevraagd
('vandaag' is er niet, binnen een week zit in de tape unit, na bewaartermijn is verloren)
- Wie mag er om een restore vragen (authorisatie)
- Wat kost een restore aan tijd, versus de tijd die de gebruiker nodig zou hebben om de
inhoud bijvoorbeeld opnieuw in te typen, of samen te stellen. (bv query resultaten)
Afhankelijk van de omstandigheden bij bedrijven, kan het noodzakelijk zijn om een 'policy' te
definieren rondom de restore aanvragen, en het bijbehorende service niveau.
In ieder geval dient bij het definieren van service-afspraken de restore tijd te worden bepaald.
Omniback kan de 'Tape ID' aangeven van de tape waarop de data staat opgeslagen.
Er zijn diverse mogelijkheden om in de Omniback tape-database te zoeken. Bestandsnaam,
type, auteur …. De huidige versie voorzien niet in de mogelijkheid om te zoeken naar 'alle'
bestanden van een bepaalde gebruiker van een bepaalde datum. (Date lookup)
Als er reeds een bestand met gelijke naam bestaat op het doel systeem (abusievelijk bestand
overschreven), dan kan een rename worden gegeven bij de restore.
Het is mogelijk om een aantal restore aanvragen te verzamelen, en vervolgens gelijktijdig (als
lijst) uit te voeren. Een complete 'system' restore wordt ondersteund.
Ook is een interactieve restore mogelijk.
Afhankelijk van het tape-rotatie mechaniek (hergebruik van tapes), zal de informatie na zekere
tijd overschreven worden. Als dat niet wenselijk is, of als er voor langere tijd vastlegging van
data opgelegd wordt, dan is er sprake van Archiving. Na verloop van tijd gaat backup/restore
dus over naar een Archiving mechaniek.
Ander aandachtspunt, is de beperkte levensduur van de tapes. 250 keer herschrijven, of 3 jaar
bewaren wordt daarbij aangehouden. Omniback zal waarschuwen, als de tape levensduur ten
einde is.
Memo 19923135
IT/Advies/GDr
Aalsmeer, 15 juni 1999
Bladzijde 6 van 7

Backup vanuit Firewall-DMZ
De DMZ (De-Militarized Zone) is een netwerk segment wat als buffer dient tussen een extern
netwerk en het interne netwerk. Alle verkeer van buiten kan alleen naar de DMZ; alleen de
machines op de DMZ kunnen naar het interne netwerk. De Firewall dient als filter/
verkeersagent.
Bij de VBA maken we gebruik van een Checkpoint FireWall-1 op een SUN systeem.
In principe is de Firewall de centrale plek om beveiligingsmaatregelen te nemen.
Om de parameterisering van de firewall goed in te stellen, dient er detailinformatie bekend te zijn
over de gebruikte protocollen, poortnummers [alleen 8088?], en mogelijk ook de tijden.
[Actie HP: Nog doorgeven wat exact deze informatie is ]
Indien de Backup Agent (de bron), en de Backup device server + tape (de bestemming) beiden
in de DMZ zitten, dan hoeft alleen de communicatie tussen Backup manager en Backup Agent
via de Firewall te lopen. Machines in een DMZ zullen niet routeren, dus transport van data en
management informatie dient aan de 'achterzijde' (via een aparte NIC) plaats te vinden.
De backup data niet zondermeer over het DMZ segment.
De Backup manager is normaal gesproken een onderdeel van het interne netwerk.
Bij gebrek aan detailinformatie, of mogelijkheden om de firewall instellingen te wijzigen, is het
'acceptabel' om via een aparte router verbinding te maken met het interne netwerk.
In dat geval moet de router slechts een verbinding kunnen maken tussen 'achterkant' van een
machine, en specifieke machines in het interne netwerk.
De backup van de informatie in de firewall zelf, kan evt. Afgehandeld worden met een specifieke
agent. Bij de VBA zullen we de 'management informatie' van de firewall op het interne netwerk
zetten, zodat de FireWall zelf qua applicaties zo 'kaal' mogelijk blijft.
[Actie HP: Status (uitleverbaar ?) van de Checkpoint FW1 'Agent' op het SUN platform nagaan]

Backup agents
Binnen de Omniback omgeving worden de agents centraal (op Backup manager) bewaakt en
onderhouden. Op deze wijze kunnen ze onderling worden afgestemd. De distributie van de
(bijgewerkte) agents naar de doel systemen vindt plaats vanuit de Backup manager.
Dit onderdeel werd binnen de werkgroep als vrij probleemloos afgeschilderd.

Instellen van restricties, rechten van beheerders.
Om agents te distribueren moeten natuurlijk wel de rechten van de systemen goed worden
geconfigureerd. Dit is meer een NT kwestie. Voor het afstemmen van de rechten van de diverse
backup/ restore beheerders legt het Omniback pakket niet echt beperkingen op.
Zowel de organisatie van een centraal beheer, als decentraal beheer met gedelegeerde
bevoegdheden wordt door het product ondersteund.
Memo 19923135
IT/Advies/GDr
Aalsmeer, 15 juni 1999
Bladzijde 7 van 7

Bewaking van het backup mechaniek
De agents, en device server kunnen zelfstandig, of via de backup manager 'problemen' kenbaar
maken aan de bewakings omgeving. Via SNMP trap destination, of via Opc messages kan in
voldoende mate van detail worden aangegeven wat er 'loos' is.
Tevens kunnen er in geval van specifieke problemen (automatische) reacties worden
geprogrammeerd. Dit kan bv betekenen dat wordt uitgeweken naar een andere unit, netwerk
verbinding, een andere tape, of dat er via mail, semafoon, desktop beeper, sms bericht, of
message browser een beroep wordt gedaan op ondersteuning van een operator of engineer.
Met name de koppeling met IT/Operations (en ITSM) is hier van belang.

Netwerk bandbreedte beperkingen

Specifieke applicatie agents

NT registry
Deze zijn gezien de vorderende tijd slechts beperkt aan bod geweest in de discussies.
Enkele punten:
Omniback voorziet zelf niet in concrete bandbreedte bewaking. Wel is er een 'low/ medium/ high'
setting voor het beslag op netwerk bandbreedte, maar concrete bandbreedten kunnen niet
worden aangegeven. Eventueel is hier in een ATM netwerk via een VLAN/ QoS setting wat
gedetaileerder een afstemming te bereiken.
Omniback heeft een redelijk aantal toegespitste agents voor diverse applicaties en databases.
Voor enkelen worden ze nog gemist. (Progress werd genoemd, evenals Informix … maar die
schijnt er inmiddels te zijn). Wanneer er geen specifieke agent voor beschikbaar is, dan zal een
omgeving tijdelijk 'offline' moeten gaan, om de bestanden te sluiten en consitentie in de
database te creeren op het moment van de backup.
[Actie HP: Hoe gaat Omniback om met backups van op dat moment geopende bestanden]
[Aanname: Geopende bestanden lopen niet mee in de backup ….. dat zou betekenen dat
gebruikers s'avonds hun bestanden moeten afsluiten, als ze willen dat die bestanden op tape
terechtkomen]
Een backup van de NT registry vormt onderdeel van een 'configuration' backup.

Opstelling detailering/ toelichting
De Hands-on demonstratie/ details is helaas een beete mager geweest.
- De direct betrokkenen bij de VBA konden niet bij de sessie aanwezig zijn
- Er waren eigenlijk niet zoveel vragen, welke verduidelijkt moesten worden
- De test/ acceptatie omgeving had (nog) geen verbinding naar de Unix Agents.
Wel heeft de HP Consultant nog een aantal details, menu's en mogelijkheden doorgenomen en
toegelicht.

Evaluatie
Een goed geslaagde, productieve, en aangename sessie. Enkele vervolg contacten zijn
overeengekomen. De nadere bezoeken onderling hebben inmiddels ook plaatsgevonden.
De positionering, mogelijkheden en beperkingen van Omniback zijn goed overgekomen. HP
Consultancy zou ook in de toekomst medewerking verlenen. Wel is het minder een 'vergelijkend
waren onderzoek' geweest. Omniback is niet direct afgezet tegen andere producten.