Einrichten von Unix Workstations für ADSM/TSM Backups am RZG

Angenommen, Sie haben ein Unix workstation mit dem Netz-Namen musterws.mpabc.mpg.de, die nicht an das zentrale AFS Filesystem des RZGs angeschlossen ist. Und Sie wollen Daten dieses Rechners regelmäßig via Backup über den TSM Server des RZGs sichern.

Bevor wir darangehen, Einrichtung und Konfigurierung der TSM Software auf Ihrem Rechner zu beschreiben, empfehlen wir Ihnen, sich Kapitel 3 "Installing UNIX Clients"" aus dem IBM Handbuch "Installing the Clients" anzuschauen.
Bei allen Fragen zum grundsätzlichen Verständnis, zur Konfiguration und zum Betrieb schauen Sie bitte ins Handbuch "Using the Unix Backup-Archive Clients". Wir empfehlen Ihnen sehr, sein Inhaltsverzeichnis aufzuschlagen und zum jeweiligen Thema nachzulesen.
Leider liegen diese Handbücher nur in (US) Englisch vor.

Nebenbei:
Sie werden in Dokumentationen und auf Webseiten die Attribute ADSM und TSM zum Teil austauschbar verwendet finden. Was steckt dahinter ?

 

• Sie haben sich von ADSM System Administratoren am RZG Ihr Domain Administrator Id und Password geben lassen und sind vertraut mit dem Aufbau einer ADSM Domain, zum Beispiel Ihre Domain MPABC. Zudem ist Ihre Domain bereits in Absprache mit den System Administratoren nach Ihren Bedürfnissen vorbereitet.

   

• Als nächstes laden und installieren Sie die ADSM/TSM Client Software.

  Bezugsquellen:

   

  • IBM ftp server
  • ftp mirror bei der Uni Karlsruhe

  Lesen Sie dann bitte die Installationsbeschreibung im README.FTP und README file. Wählen Sie möglichst nur die Programmteile aus, die Sie im Zusammenhang mit dem TSM Server "adsm-1" am RZG wirklich brauchen: den Backup-Archive Client und die Dokumentation.

  Beachten Sie bitte, daß das RZG Anwendungen mit dem API - Application Program Interface - des ADSM nicht unterstützt. Ebenso unterstuetzen wir kein HSM - Hierachical Storage Management -. Das heißt, Sie können auf die Installation aller Programmteile verzichten, in deren Filenamen ".api" oder ".hsm" auftauchen.

  Es ist zu empfehlen, die Software mit den vorgegebenen oder empfohlenen Default-Pfaden zu installieren. Sie werden sich bei Installation und späterer Wartung leichter tun.

   

• (Vorläufige) Konfiguration via dsm.sys und dsm.opt

  Die Client Software ist nun in ein Verzeichnis installiert worden, in dem auch die beiden Konfigurationsdateien dsm.sys und dsm.opt beheimatet sind. Vergleichen Sie dazu bitte eingehend das zugehörige README und "Setting Processing Options" des Handbuchs. In der Regel überläßt es die Client Software Ihnen, aus den Beispieldateien dsm.sys.smp und dsm.opt.smp diese zu erstellen. Wir aber möchten Ihnen empfehlen, dies nicht zu tun, sondern statt dessen unsere vorkonfigurierten Konfigurationsdateien herunterzulanden und jeweils eine von ihnen zu verwenden.

  Der Client User Options File dsm.opt.RZG kann ohne Veränderung verwendet werden. Er enthält zur Zeit nur Optionen von nachgeordnetem Interesse und kommt - wie der Name schon sagt - erst ins Spiel, wenn einzelne "private" Benutzer die ADSM Client Software für ihre persönlichen Backups und Archive benutzen wollen.

  Der Client System Options File dsm.sys ist dagegen von zentraler Bedeutung. In ihm werden - sehr allgemein gesagt - drei Bereiche konfiguriert:

  • Wie erfolgt die Komunikation zwischen Client-Rechner und ADSM Server?
  • Wie sollen Scheduler- und das eigentliche Backup/Archiv-Programm auf dem Rechner laufen?
  • Welche Dateien sollen vom Automatischen Backup gesichtert werden?
  Wir haben System Options Files vorbereitet, die sich im letztgenannten Punkt unterscheiden. Die Datei dsm.sys.RZG.backup_all_local_fs sorgt dafür, daß - bis auf einige speziell ausgenomme Ordner und andere Dateien - grundsätzlich alle Directories und Files auf allen lokalen Filesystemen im Automatischen Backup gesichert werden. Was dem ADSM Client Default entspricht. Anders verhält sich das Automatische Backup bei Verwendung der folgenden Dateien, die - da sie jeweils kleine Unterschiede in den verschiedenen System berücksichtigen - nach Unixsystemen unterschieden werden: dsm.sys.RZG.solaris, dsm.sys.RZG.aix, dsm.sys.RZG.linux und dsm.sys.RZG.irix. Mit den Optionen DOMAIN und EXCLUDE /.../* sichern sie explizit nur die Directory-Struktur - also keine non-Directory-Dateien - bestimmter Plattenpartitionen der Unix-System-Filesysteme. Zusätzlich werden dann noch via INCLUDE alle Files in Directories bzw. Subdirectory-Bäumen gesichert, die für die individuelle Systemkonfiguration der Workstation von besonderer Bedeutung sind. Diese dsm.sys-Konfigurationen gehen also davon aus, daß beim Crash der Systemplatten das Unixsystem "aus der Dose" neu aufgespielt wird und nur diese speziellen Konfigurationsdateien vom Backup zurückgeholt werden. Sollten Sie sich für eine solche maßgeschneiderte und resourcen-sparende Version entscheiden, muß sie natürlich an das System Ihrer Workstation angepaßt werden. Auch müßen noch weiter zu sicherende lokale Filesysteme mit entsprechenden Optionen hinzugefügt werden. Die oben genannten von Automatischen Backup "speziell ausgenomme Ordner und andere Dateien" sind in allen dsm.sys-Dateien des RZGs ausgenommen. Dies sind System- oder Applikations-interne Cachefiles, Mountpoints von CD-ROM und Floppy und ständig geöffnete und "wachsende" Logdateien - zum Beispiel die Logfiles vom ADSM Scheduler und Backup selbst. Die Liste der Ausnahmen können Sie jederzeit selbst in Ihrem dsm.sys erweitern.

  Laden Sie bitte die ausgewählte Version herunter und wechseln Sie in die ADSM Clint Software Directory .../adsm/bin. Auf AIX Systemen zum Beispiel findet man dieses Verzeichnis per default unter /usr/lpp/adm/bin, auf Digital UNIX unter /usr/opt/adsm/bin, auf den meisten uebrigen unter /usr/adsm/bin. Kopieren Sie bitte die Dateien unter ihrem originalen Namen dsm.sys und dsm.opt hierher und editieren Sie dsm.sys mit Ihrem Lieblings-ascii-Editor. Natürlich können Sie - falls notwendig - die eben diskutierte Anpassung für das Backup Ihrer Workstation gleich jetzt vornehemen. In jedem Falle muß zuvor noch etwas anderes getan werden: tragen Sie in die Zeile mit der Option NODENAME hinter dieser Option den Namen ein, unter dem die Workstation beim ADSM Server registriert werden soll: zum Beispiel nodename musterws.mpabc.mpg.de Beachten Sie bitte, das am ADSM Server des RZGs die Konvention beachtet werden muß, stets den vollen, Netzwerk-fähigen Namen des Rechners als ADSM Node-Namen anzugeben. Näheres dazu auch im folgenden Abschnitt.

  Wenn über die einfache Installation und Registrierung eines ADSM Clients hinaus spezielle Kenntnisse für die Administrierung von ADSM Nodes gefragt sind, dann bei der Konfigurierung von dsm.sys (und dsm.opt). Bitte lesen Sie mehr dazu in Kapitel "Setting Common Options" des ADSM Unix Client Handbuchs.

  Mit der Installation der ADSM Unix Client Software wird auch das ADSM Administrator Commandline Interface dsmadmc installiert. An diesem Punkt der Installation sollten Sie es erfolgreich starten und mit seiner Hilfe den nun folgenden Installationpunkt erledigen können.

   

• Nun muß der Rechner als Client bzw. "Node" einer bestimmten ADSM Domain am Server registriert und für das Automatische Backup zugelassen werden.

  Dieser Punkt hätte auch schon zuvor ohne die oben besprochene Software Installation erledigt werden können, zum Beispiel von einem Unix-Rechner aus, der bereits an den ADSM Server des RZGs angeschlossen ist, oder mit Hilfe eines simplen Webbrowsers. Nun aber läßt es sich nicht mehr länger aufschieben.

  Diese Arbeiten setzen die Administrator Rechte für diese bestimmte ADSM Domain voraus und können also nur von einem für diese Domain verantwortlichen ADSM Domain Administrator ausgeführt werden, an den Administrator Id und Paßwort von den ADSM System Administratoren am RZG am RZG vergeben wurden. Einführende Seiten zum Thema ADSM Administration am RZG sind die "Einführung für ADSM Domain Administratoren" und "Aufbau einer ADSM Domain".

  Voraussetzung zur Registrierung eines Rechners in einer ADSM Domain ist natürlich, daß diese Domain bereits von den ADSM System Administratoren am RZG eingerichtet wurde und sie vom zuständigen ADSM Domain Administrator Ihres Instituts in Absprache mit dem System Administratoren konfiguriert wurde.

  Sie können die Registierung direkt von diesem Rechner aus mit Hilfe des Administrative Web Interface oder mit dem lokalen Administratorkommando dsmadmc vornehmen. Beide werden in der "Einführung für ADSM Domain Administratoren" vorgestellt. Die eigentliche Wahl aber liegt darin, ob Sie die Client Registrierung via grafischer Klick-Oberfläche vornehmen wollen oder ob Sie die Client Registrierung via Commandline Interface erledigen. Geschwindigkeit und umfangreiche Abfragemöglichkeiten mit diversen Query-Subkommandos sprechen klar für die letztgenannte Methode. Die Details finden Sie in den angegebenen Links.

   

• Den ADSM Backup Client des Rechner testen.

  Die ADSM Client Software ist installiert und konfiguriert , der Rechner am Server angemeldet. Das reicht für den nun folgenden ersten Backup-Test.

  Starten Sie als root-user in diesem Verzeichnis das GUI-Program dsm. Nun das Hauptfenster des ADSM Clients erscheint auf Ihrem Schirm. Drücken Sie auf den Button "Backup files und directories", so erscheint das eigentliche Backup-Fenster mit der Filesystem-Struktur Ihres Workstation. Blättern Sie ähnlich dem Explorer-Fenster eines Microsoft-Rechners die Baumstruktur eines lokalen Filesystems auf und wählen Sie links ein Directory fürs anschließende Backup. Ist der kleine Markierungs-Button hübsch gelb geworden und hat ein kleines rotes Hakerl bekommen, dann stoßen Sie Ihr erstes Backup über den Button "Backup" an. Nun taucht ein weiteres Fenster auf, in dem Sie verfolgen können, wie das Backup vorbereitet wird und dann die Datenübertragung beginnt. Sobald die ersten Daten erfolgreich zum Server fließen, brechen Sie das Backup mit einem Druck auf den Stop-Button bitte ab. Denn das eigentliche Backup soll nach Konfigurierung über das automatische Backup des ADSM Backup Client Scheduler Daemons erfolgen.

  Im Laufe dieser ersten Verbindung, sprich: Session, werden Sie nach dem Passwort gefragt, das Sie für diesen Rechner beim Registrieren angegeben haben. Enthält die Konfigurationsdatei dsm.sys - so wie in der beigelegten Beispiel des RZGs - die Option PASSWORDACCESS GENERATE, dann wird jetzt bei der ersten Verbindungsaufnahme dieses Passwort verschlüsselt und nur vom root-user lesbar ins lokale /etc-Filesystem geschrieben. Von nun an wird bei allen weiteren Kontaktaufnahmen zwischen Node und Server nicht mehr danach gefragt werden.

   

• Automatisieren Sie die Backups Ihrer Workstation musterws.mpabc.mpg.de.

  Das Backup sollte nur in Ausnahmefällen wie zuvor beschrieben von Hand angestoßen werden müßen. Backup macht im professionellen Bereich erst Sinn, wenn es - in aller Regel - täglich und automatisch ausgeführt wird. ADSM ermöglicht dies über seine Backup-Fahrpläne, die sogenannten "Backup Schedules", die auf dem Server individuell für jede Domain definiert werden können. Ein ADSM Client, besser: Node, muß mit mindestens einem solchen Schedule verbunden sein. Werfen Sie zu diesem Thema auch einen Blick in den Aufbau einer ADSM Domain.

  In oberen Beispiel ist unser Node bereits mit dem Schedule "nightly_backup" auf dem Server assoziiert werden. Dies allein reicht jedoch noch nicht aus. Um das "von Hand" zu ersetzen braucht es einen ständig laufenden Process, der die Kommnunikation des ADSM Client Software mit dem ADSM Server übernimmt. Und dies tun Sie als root-user prinzipiell mit dem Aufruf des allgemeinen Commondline User-Interface 'dsmc' samt der Option 'schedule':

  dsmc schedule

  Wie dieser Aufruf im Detail ausgeführt werden muß und welche Einträge vorzunehmen sind, um das automatische Starten des ADSM Scheduler Dämons bei jedem Hochfahren des Unix Rechners zu gewährleisten, beschreibt IBM/Tivolis Starting the Client Scheduler. Jedoch und leider nur für einige IBM-eigene Betriebssysteme. Und obendrein in einer weniger-empfehlenswerten Form. Dazu alternativ einige ergänzende Hinweise zu AIX und einigen anderen Unix Systemen:

   

  1. Grundsätzlich sollten Dämonen aus einem speziell auf ihre Bedürfnisse zugeschnittenen (BourneShell) Script ge'start'et und ge'stop't werden. Das Script muß daher mit dem Argumenten 'start' oder 'stop' gerufen werden können, wobei 'start' im Idealfall nicht den Dämon startet, wenn er schon oder noch läuft, und 'stop' eben laufende Dämonen sucht und adäquat zur Aufgabe zwingt. Bequem für den Einsatz von Hand ist das Argument 'status', das anzeigt, ob der Dämon läuft oder eben nicht läuft. Luxus ist ein Argument 'restart', das einen laufenden Daemon stopt, um ihn hernach erneut zu starten. Ein etwas aufwendig geratenes ADSM Client Scheduler Startscript-Beispiel können Sie sich hier herunter laden und nach Gutdünken abspecken. Vergleichen Sie hierzu bitte auch den letzten Punkt dieses Abschnitts.

     Beachten Sie bitte, daß der Dämon-Prozeß im Script grundsätzlich mit '&' im Hintergrund gestartet wird, um den Boot-Prozeß nicht an ihn zu binden und damit im Fehlerfall hängen zu lassen. Stdout und stderr sollten auf /dev/null zeigen - es sei denn, Sie leiten auf spezielle Logfiles im /var-Filesystem um und sorgen dafür, daß Ihnen das Filesystem nicht mit Backup-Information des laufenden Backup-Betriebs vollgeschrieben wird. Hilfreich sind dabei die Scheduling Options und Error Processing Options insbesondere die Optionen schedlogretention und errorlogretention. Wollen Sie Ihre Logfiles z.B. per script-Programm selbst verwalten, sehen Sie dazu die Option postschedulecmd.

      

  2. Jetzt heißt es, als root-user das Boot Script an den richtigen Platz des lokalen Filesystems zu stellen und dafür zu sorgen, daß das System beim Hochfahren von sich aus den Scheduler Daemon startet. Dabei sind einige Unix-Varianten wieder ein wenig gleicher als andere.

     Kopieren Sie unter SOLARIS das Script nach /etc/init.d/dsmsched.rc. Der Name entspricht den Solaris-Konventionen, ist jedoch frei wählbar. Linken Sie das Script mit dem Linknamen "S[NN]dsmsched" in dem oder den Directories /etc/rc[N].d. NN muß eine Zahl größer 77 sein und darf noch nicht von anderen Links dieser Art benutzt werden sein, zum Beispiel 81. N entspricht der Nummer des oder der Boot Levels, in welchen der Scheduler gestarted werden soll. Auf RZG eigenen Maschinen in der Regel unter Level 3. In unserem Beispiel setzen Sie den Link mit dem Kommando
     ln -s /etc/init.d/dsmsched.rc /etc/rc3.d/S81dsmsched
     Der Bootprozeß scannt diese Directories je nach Boot Level und startet alle S-Links in der Reihenfolge ihrer Nummerierung. Da der Scheduler Daemon auf die volle Funktionsfähigkeit von lokaler Maschine und Netzwerk angewiesen ist, sollte NN also ausreichend hoch sein.

     Alle Unix Betriebssysteme, die wie im Falle von Solaris die Boot Scripts per Link in den entscprechenden Level Directrories aufrufen, tun dies beim Hochfahren von sich aus mit dem Argument 'start'.

     Auf SGI's Workstations unter IRIX erfolgt die Installation grundsätzlich so wie unter Solaris. Das Script sollte nach SGI-Konvention allerdings nicht dsmsched.rc sondern nur 'dsmsched' heißen. Zusätzlich muß danach noch das checkconfig-Feature unter des IRIX-Betriebssystem unterstützen. Mit dem Kommando
     /sbin/chkconfig -f dsmsched yes
     wird in /etc/config eine Flagge für dsmsched gesetzt, die zusaetzlich von IRIX beim Bootup geprüft wird. Ist sie auf 'no' gesetzt worden, wird der Daemon trotz aller richtigen S-Links nicht gestartet. Der Vorteil ist, daß in die Bootup Installation für den Daemon nicht eingegriffen werden muß, um einen Daemon zu deaktivieren.

     Generell verfährt man auch unter LINUX ähnlich wie unter Solaris. Die einschlägige Script-Directory liegt jedoch einwenig anders:
     ln -s /etc/rc.d/init.d/dsmsched.rc /etc/rc3.d/S81dsmsched

     Hier sollte erwähnt werden, daß Sie ähnlich der Installation für den Bootup Prozeß auch den Shutdown Prozeß mit K-Links unterstützen können:
     ln -s /etc/rc.d/init.d/dsmsched.rc /etc/rc0.d/K21dsmsched
     wobei NN (in K[NN]dsmsched) unter Boot Level 0 (in rc[N].de) wiederum eine nicht anderweitig verwendete Nummer sein mu&szlig. Aufrufen von K-links gibt das System übrigens immer das 'stop' Argument auf den Weg. Für unseren Scheduler Daemon ist ein solcher Link in der Praxis nicht nötig, da der ADSM Scheduler Prozeß mit einem harten 'kill -9' einigermaßen problemlos beendet werden kann und folglich auch im System Shudown nicht sanft behandelt werden muß. Dennoch sprechen wir hier davon, da im Linux der Redhat Distribution davon Gebrauch gemacht wird.

     REDHAT hat das checkconfig-Feature von IRIX übernommen:
     - Sie machen sich auch hier auf die Suche nach einer gemeinsamen freien Startnummer S[NN].... aller Levels, in denen der Scheduler Daemon gestartet werden soll, sagen wir: in den Directories /etc/rc3.d, /etc/rc4.d und /etc/rc5.d und Sie finden wieder die 81. Dann suchen Sie eine gemeinsame Nummer in allen Levels, in denen der Scheduler Daemon heruntergefahren werden soll: 0,1,2 und 6. Hier finden Sie z.B. unter allen K[NN]-Links die freie Nummer 21.
     - Kopieren Sie Ihr Script wie gehabt nach /etc/rc.d/init.d/dsmsched, fügen nun aber zwei fest-formatierte Zeilen ein:
     # chkconfig: [Nummernfolge der Bootup Level] [S-Nummer] [K-Nummer]
     # description: [kurzer beschreibender Text]
     In unserem Beispiel:
     # chkconfig: 345 81 21
     # description: ADSM backup client scheduler
     - Dann aktivieren Sie das checkconfig-Feature entprechend Ihren Absichten je Boot Level:
     /sbin/chkconfig --level 345 dsmsched on
     /sbin/chkconfig --level 0126 dsmsched off
     So IRIX will, werden jetzt von checkconfig die entsprechenden S[NN}- und K[NN]-Links erzeugt.
     - Die Installation läßt sich überprüfen mit
     /sbin/chkconfig --list dsmsched

     Unter IBM's AIX sieht es - wie in "Starting the Client Scheduler" beschrieben - ein wenig anders aus. Grundsätzlich werden Dämonen über Einträge im /etc/inittab File gestartet. Wir tragen dort das zuvor nach /etc/rc.dsmsched kopierte Scheduler Boot Script mit dem Argument 'start' ein:
     adsm::once:/etc/rc.dsmsched start 1>/dev/null 2>&1 #ADSM backup scheduler

     Empfohlene Praxis ist jedoch, dort nur die wichtigsten Dämonen des Systems einzutragen und am Ende ein zusätzliches Bourne Shell Script, das seinerseits alle anderen Dämonen startet. In den AIX Installationen am RZG übernimmt dies das Script rc.local. Fügen Sie als eine der letzten Aktionen in ein solches Scripts zum Beispiel folgende Zeile ein:
     [ -x /etc/rc.dsmsched ] && /etc/rc.dsmsched start 1>/dev/null 2>&1

      

  3. Einfluß auf den Ablauf des automatischen Backups können Sie über die oben genannten Scheduling Options nehmen , die Sie in dsm.sys definieren. In der vorkonfigurierten dsm.sys Datei des RZGs finden Sie einige davon vor, die Sie im Rahmen der Vorgaben des ADSM Servers auf Ihre Bedürfnisse abstimmen können. Nähres zu diesem Thema finden Sie im Kapitel "Automating TSM Tasks" des Handbuchs.

      

  4. Beachten Sie bitte, daß der Scheduler Dämon nur bei seinem Start die Konfigurationsdateien dsm.sys (und dsm.opt) des Clients einliest. änderungen dieser Dateien werden erst nach einem Neustart des Schedulers berücksichtigt. Das können Sie als root-Benutzer mit dem Kommando
     nohup dsmc schedule 2> /dev/null &
     von Hand machen, nachdem Sie bitte den bereits laufenden Scheduler-Prozeß mit "ps" gesucht und per "kill -15" oder "kill -9" beendet haben. Einfacher gehts natürlich, wenn Sie - wie oben empfohlen - über ein funktionierendes Boot Script verfügen, das solche Arbeiten für Sie erledigt.

      

  5. Es sollte nicht vorkommen, doch es kommt vor, daß ein Scheduler Dämon Prozeß verschwindet, aufgibt, abbricht, stirbt .... Aus welchen Gründen auch immer. Und es ist nicht wahrscheinlich, daß Sie dies sofort bemerken. Sollte dieser Zustand laenger anhalten, könnte dies unangenehme Folgen haben. Es ist also ein Akt der Klugheit, Ihrer Aufmerksamkeit etwas nachzuhelfen. Am besten überlassen Sie das einem täglichen cronjob. Das oben unter 1. erwähnte Scheduler Startscript kann dabei hilfreich sein. Editieren Sie als root-user root's cron-job-Tabelle mit crontab -e und fügen Sie hier mit Ihrer email-Adresse z.B. folgende für Solaris geeignete Zeile ein:
     33 10 * * * /etc/init.d/dsmsched.rc status name@institut.mpg.de 1>/dev/null 2>&1
     dann werden Sie zur angegebenen Zeit darüber informiert, sollte der ADSM Scheduler Dämon auf dieser Maschine einmal nicht laufen.

   

• Kontrolle der Backups

  Der Hinweis auf die lokalen Log-Dateien eruebrigt sich eigentlich. Sind Sie allerdings fuer mehr als nur wenige Unix-Workstations verantwortlich, kann es sinnvoll sein, die Log-Dateien auf ein zentrales Filesystem - z.B. NFS - schreiben zu lassen, um sie leichter auszuwerten.

  Das RZG bietet zur Ueberwachung der Backups ein Tool an, dass es Ihnen erlaubt, via Webbrowser mit wenig Aufwand die Kontrolle der Backups in einer ADSM/TSM Domaene vorzunehmen.

   

PS:

Sollten Sie nach längerer Zeit Namen und Funktionen der beteiligten Programme etc. nicht mehr in Erinnerung haben, werfen Sie einen Blick auf die TSM Quick Reference for the UNIX Backup-Archive Clients.

Und denken Sie bitte daran:
Das hier gesagte gilt für ADSM Unix Client Software, die - wie hier beschrieben - "lokal und konservativ" auf dem jeweiligen Rechner komplett installiert wird. Rechner, die über das AFS-Filesystem des RZGs verfügen und vorbereitet sind, die dortige zentrale ADSM Client Installation im AFS zu nutzen, verwenden davon etwas abweichende Client-Kommandos. Auf solchen Rechnern können Sie sich mit dem Kommando adsm help darüber detailiert informieren.

 

---