TSM mit Linux

Diese Anleitung wurde nach bestem Wissen und Gewissen erstellt. Für enhaltene Fehler kann aber keine Haftung übernommen werden. Es wird vorausgesetzt, dass der Nutzer dieser Anleitung mit grundlegenden Kenntnissen der Systemadministration unter Linux vertraut ist. Da sowohl die Installation als auch die Konfiguration, i.d.R. dann auch die Anwendung mit „root“-Super-User-Rechten durchgeführt wird, sollte entsprechend umsichtig verfahren werden.

TSM steht für Tivoli Storage Manger und ist ein Backup-System ( = Sicherungs-System) von IBM. Mit einem TSM-Klienten kann man seine Daten auf einem TSM-Server sichern und bei Bedarf – z.B. wenn man eine Datei gelöscht hat – wieder zurückholen. TSM steht für die gängisten Betriebssysteme zur Verfügung. Es gibt (Stand 2009) eine Landeslizenz für die Nutzung in allen staatlichen Hochschulen des Landes Baden-Württemberg.

Ein Knoten (Node) ist ein Computer im Netz (LAN, Internet), der mit seiner TSM-Client-Software über das Netz auf den TSM-Server sichern will. Dabei ist es egal, ob es sich um einen „PC“ oder um ein Server-System handelt.

Beim Backup (Sicherung) werden Daten – im Wesentlichen Dateien und Verzeichnisse – vom Klienten auf den Server übertragen und dort gesichert, solange die Daten auf dem Knoten (noch) existieren … dazu später mehr.

Beim Restore (Wiederherstellung) können Daten zurückgeholt werden. Es existieren bis zu zwei Versionen jeder Datei: eine aktuelle und eine inaktive … dazu später mehr.

Es gibt auch noch die Funktionen Archive und Retrieve; der wesentliche Unterschied zu Backup und Restore besteht darin, dass ein Backup nach einem Sicherungslauf dem Benutzer die Möglichkeit geben soll, sein System wieder so herzustellen wie es zum Zeitpunk des Sicherungslaufs war. D.h. die Dateien werdem (mehr oder weniger) 1:1 abgebildet; gelöschte Dateien auf dem Knoten auch auf dem Server wieder gelöscht. Im Gegensatz dazu können nach dem Archivieren die lokalen Dateien auf dem Klienten gelöscht werden, die Archive verbleiben auf dem TSM-Server.

Bei einem Sicherungslauf werden deshalb auf dem Knoten nicht mehr vorhanden Dateien auf dem TSM-Server ebenfalls gelöscht oder genauer als „inaktiv“ markiert; erst nach einer gewissen Zeit (derzeit nach 30 Tagen) werden sie ganz entfernt. Innerhalb dieser Frist kann man sie also auch wieder restaurieren.

Zunächst mal ist eine Registrierung der zu sichernden Maschine in MyAccount erforderlich, was in der TSM-Anleitung ausführlich beschrieben wird. Dort wird auch das weitere Vorgehen für Windows-Betriebssystem beschrieben.

Eine weitere Lizenzierung ist derzeit nicht nötig. Allerdings heißt das nicht, dass es „kostenfrei“ wäre. Im Rahmen der Landeslizenz werden die Kosten dieser nach einem komplizierten Schlüssel abhängig von der Nutzung auf die Hochschulen verteilt. Diese Kosten werden derzeit aber nicht auf die einzelnen Nutzer umgelegt.

Hier geht's (nur) weiter für Linuxer ….

Die TSM-Client-Software kann man bei der Uni Karlsruhe herunterladen. Dort findet man verschiedene TSM-Versions-Verzeichnisse und darin die Betriebssystem-Versionen; i.d.R. sollte man die neueste Version nehmen. Alternativ findet man die TSM-Client-Software auch direkt bei IBM.

Verschiedene Dokus von Tivoli/IBM gibt's auch in deutsch oder englisch, ebenso die Fehlernachrichten in deutsch oder englisch

Download, Installation und Konfigration der Tivoli-TSM-Client-Software (hier Version 6.1) wird im Folgenden (beispielhaft) für openSuSE 11.1 beschrieben.

Downloads:

• http://ftp.rz.uni-karlsruhe.de/pub/tsm/mirror/maintenance/client/v6r1/Linux/LinuxX86/v610/6.1.0.0-TIV-TSMBAC-LinuxX86.tar
• http://ftp.rz.uni-karlsruhe.de/pub/tsm/mirror/maintenance/client/v6r1/Linux/LinuxX86/v610/TIVsm-msg.DE_DE.i386.rpm

oder ggf. andere als DE_DE-Sprachversionszusätze runterladen.

z.B in einer Shell per

 # tar xvpf 6.1.0.0-TIV-TSMBAC-LinuxX86.tar

Man erhält die Dateien

• TIVsm-API.i386.rpm
• TIVsm-API64.i386.rpm
• TIVsm-BA.i386.rpm

Vorbemerkung: auf 64-Bit-Systemen wird ggf. beim Ausführen von „rpm -U TIVsm-API.i386.rpm“ folgender Fehler ausgegeben:

  error: Failed dependencies:
       libstdc++.so.5 is needed by TIVsm-API-6.1.0-0.i586
       libstdc++.so.5(CXXABI_1.2) is needed by TIVsm-API-6.1.0-0.i586
       libstdc++.so.5(GLIBCPP_3.2) is needed by TIVsm-API-6.1.0-0.i586

Diese Abhängigkeiten kann man nicht einfach ignorieren, sondern es ist notwendig, entspr. Bibliothek(en) (libstdc++) zuvor nachzuladen; für openSuSE-11.1 (x86_64) habe ich libstdc++33-32bit-3.3.3-7.10 per YaST „gefunden“ und nachinstalliert.

Zum Installieren mit „rpm“ als root in einer Shell ausführen (Bitte unbedingt Reihenfolge beachten!):

 #   rpm -U TIVsm-API.i386.rpm         # das braucht man immer
 # #(rpm -U TIVsm-API64.i386.rpm)      # das braucht man **nur** bei **64-Bit-Betriebssystemen** !!!
 #   rpm -U TIVsm-BA.i386.rpm          # das ist die eigentliche Anwendungssoftware
 #   rpm -U TIVsm-msg.DE_DE.i386.rpm   # und das (nur) für sprachabhängige (hier deutsche) Ausgaben

Wenn alles geklappt hat, findet sich alles Notwendige unterhalb von

• /opt/tivoli/tsm/ ,

das Wichtigste aber in

• /opt/tivoli/tsm/client/ba/bin/

Hier gibt's dann auch die (Beispiel-)Konfigurations-Dateien

• dsm.sys(.smp) und
• dsm.opt(.smp)

welche a) für die Anwendung notwendig sind und b) standardmäßig hier in diesem Verzeichnis gesucht werden.

Es ist gute Praxis, beide o.g. Konfigurationsdateien z.B. im Verzeichnis /etc/tsm/ abzulegen,

  # mkdir /etc/tsm/
  

die beiden Konfigurationsdateien dsm.sys und dsm.opt hier mit dem Lieblings-Text-Editor anzulegen, und dann zu verlinken:

  # cd  /opt/tivoli/tsm/client/ba/bin/
  # mv dsm.sys dsm.sys.orig
  # mv dsm.opt dsm.opt.orig
  # ln -s /etc/tsm/dsm.sys
  # ln -s /etc/tsm/dsm.opt

So könnte Ihre (Minimal-)dsm.sys-Datei aussehen:

   servername  ARCH2
   	COMMmethod	   TCPip
   	TCPPort 	   1503
   	TCPServeraddress   arch2.uni-freiburg.de
   	Passwordaccess     generate
  
   inclexcl       /etc/tsm/inclexcl
   compression    off
   nodename       myhost.mydomain.uni-freiburg.de
   passworddir    /etc/tsm/security

Zu den o.a. Parametern:

• Der servername (hier) „ARCH2“ ist ein Alias für den daran anschliessenden TSM-Server-Definitionsblock für einen unserer (derzeit) vier TSM-Server, der Ihnen bzw. Ihrem Knoten bei der Registrierung zugewiesen wird. Dieser Definitionsblock beinhaltett zwingend die Kommunikations-Parameter zum TSM Server mit der
• alternativlosen COMMmethod „TCPip“ (also das Protokoll),
• der TCPServeraddress , die IP-Adresse des TSM-Servers, hier „arch2.uni-freiburg.de“ und
• des zugehörigen TCPPort, hier im Beispiel „1503“

Für „multi user clients“ empfiehlt sich die Einstellung

• Passwordaccess generate ,

was sicherstellt, dass jeder „User“ auf dem System auf seine gesicherten Dateien im TSM zugreifen kann, ohne das Passwort zu wissen.

Im Übrigen kann man über den Aliasnamen beim Aufruf der TSM-Client-SW auf verschiedene TSM-Server zugreifen, was aber im Otto-Normalfall für Sie als Anwender nicht relevant ist.

Die Server unterscheiden sich konfigurationseitig aus Sicht der Klienten lediglich in der IP-Adresse und dem Port: z.Z. sind dies:

• Server: adsm.uni-freiburg.de Port: 1500
• Server: arch.uni-freiburg.de Port: 1501
• Server: adsm2.uni-freiburg.de Port: 1502
• Server: arch2.uni-freiburg.de Port: 1503

Die weiteren global gültigen Parameter:

• inclexcl (eine Datei mit bei der Sicherung auszuschließenden Datei- und Verzeichnis-Namen)
• compression „off“ oder alternativ auch „on“ bei langsamen Verbindungen
• Der nodename ist optional, wenn der Linux-HOSTNAME diesem entspricht; der Knotenname wird bei der Registrierung angegeben und muss dem FQDN (Full Qualified Domain Name), also dem vollständigen IP-Namen Ihres Knoten entsprechen. Diese (unsere) „Policy“ macht es uns leichter, einen Knoten zuzuordnen und gleichzeitig nutzen wir damit einen eindeutigen Namensraum.
• passworddir legt ein Verzeichnis fest, in dem die bei „passwordaccess generate“ automatisch erzeugten Passwörter verschlüsselt abgelegt werden.

Nun zur dsm.opt - Datei:

   SErvername       ARCH2
   domain           ALL-LOCAL
   * oder alternativ z.B.
   domain	      /  /home  /data  /nfs/nfsserver/directory

• Der SErvername ist optional, insbesonders wenn nur ein Server-Alias in dsm.sys definiert ist; ggf. wird der erste in „dsm.sys“ gefundene herangezogen.
• domain definiert die zu sichernden Dateisysteme, bei ALL-LOCAL werden alle lokalen gesichert, ggf. kann man auch explizit auswählen, wie oben gezeigt.

Optional dazu z.B.

   dateformat      4
   timeformat      1
   numberformat    5
   verbose

Die Parameter sind alle in der Dokumentation für Version 6.1 bzw. der Dokumentation für die 5er-Versionen beschrieben. Ggf. helfen auch die hier erläuterten Fehlermeldungen weiter.

fehlt noch

fehlt noch: so lange siehe Dokus von Tivoli (weiter unten)

(die Anleitungen sind nur teilweise in deutsch verfügbar)

TSM-Version 6.1:

• Dokumentation zu IBM Tivoli Storage Manager Version 6.1 als Einstiegspunkt

TSM-Version 5.5

• IBM Tivoli Storage Manager Backup-Archive Clients als Einstiegspunkt und die
• TSM-(Fehler)-Meldungen

Im Wiki der GWDG wird die Einrichtung des TSM-Clients unter Debian beschrieben, insbesondere wird auch auf die Fallstricke bei 64-Bit eingegangen:

TSM-Client unter Debian/etch einrichten

• http://wiki.gwdg.de/index.php/TSM:debian