Zentrale Datensicherung an der RWTH Aachen - Einführung in TSM

Transkript

1 Zentrale Datensicherung an der RWTH Aachen - Einführung in TSM 23. Juni 2004 Daniel Stanek stanek@rz.rwth-aachen.de Rechen- und Kommunikationszentrum RWTH Aachen

2 Inhaltsverzeichnis 1 Überblick über die zentrale Datensicherung an der RWTH Aachen Ansprechpartner und nützliche Links Anmeldung Backup-/ Archivdienst Spielregeln Hard- und Softwareausstattung Backupserver Archivserver Aktuelle Belegung Einführung in TSM Arbeitsweise von TSM Versionierung und Aufbewahrungsdauer von Dateien Beispiel Sicherungsmöglichkeiten Stärken / Schwächen von TSM Voraussetzung zur Nutzung des Backupdienstes Randbedingungen Backup Client Netzwerk Offene Dateien Firewall / Paketfilter ICMP/UDP Ports Sicherung von Netzlaufwerken / gemounteten Filesystemen Ansprechpartner Installation und Konfiguration des TSM-Clients Installation der Software Installation unter Windows Hinweise zur Installation auf Linux-Systemen Konfiguration des Clients (dsm.sys/dsm.opt) Wie heisst mein TSM-Server Einstellen des TSM-Servers und Ports Generelle Einstellungen

3 2 INHALTSVERZEICHNIS Variable Einstellungen Auswahl zu sichernder Partitionen / Filesysteme Auswahl zu sichernder Dateien - Include-/Exclude Listen Sichern über verschiedene Managmentklassen Passwort Installation des Schedulers Windows Unix Aufgaben des Administrators Weitere Parameter für dsm.sys/dsm.opt Datums-, Zeit- und Zahlenformat Unicode Windows Unix Samba Open File Support (OFS) Installation des LVSA mit Open File Support Konfiguration Automatisches Ausschalten eines Rechners nach einem automatisierten Backup (Windows) Scheduler-Dienst mit Administrator-Rechten laufen lassen Ausschalten des Rechners konfigurieren Backup von Dateien Sicherung über grafische Oberfläche (dsm) Manuelle Auswahl zu sichernder Dateien Inkrementelle Sicherung der in dsm.sys/dsm.opt angegebenen Domains Statusbericht Sicherung über die Kommandozeile (dsmc) Automatisierte Sicherung über den Scheduler Start des Backups Begin der Sicherung Meldungen während der Sicherung Backupbericht am Ende der Sicherung Restore von Dateien Fall des Datenverlustes Restore großer Filesysteme (Disaster-Restore) Alternativen / Ergänzungen für den Disasterfall Vorbereitungen Restore über die grafische Oberfläche (dsm) Aktive / inaktive Sicht der Dateien Auswahl der Zielverzeichnisses Restorebericht Restore über die Kommandozeile (dsmc) Rechen- und Kommunikationszentrum 2 Einführung in TSM

4 3 INHALTSVERZEICHNIS 6.8 Point-in-time Restore grafische Oberfläche Kommandozeile Optimierungsmöglichkeiten Parallele Backup Sessions Parallele Restore Sessions Journal Based Backup Aufgaben bei der Betreuung des Backupclients Administrative Aufgaben Sonstige Aufgaben Filespaces aus dem Backup herausnehmen Sicherung von Datenbanken Tivoli Data Protection Agenten Sicherung von dumps Beispiel: mysql-datenbank und mysqlhotcopy A Beispiel dsm.sys für Unix-Systeme 72 B Beispiel dsm.opt für Windows-Systeme 74 Rechen- und Kommunikationszentrum 3 Einführung in TSM

5 Kapitel 1 Überblick über die zentrale Datensicherung an der RWTH Aachen 1.1 Ansprechpartner und nützliche Links Der Backup- und Archivdienst im Rechen- und Kommunikationszentrum der RWTH wird von folgenden Personen betreut, die Ihnen gerne bei Problemen oder sonstigen Fragen weiterhelfen: Arnold Malcherek malcherek@rz.rwth-aachen.de Daniel Stanek stanek@rz.rwth-aachen.de Bitte benutzen Sie bei Fragen oder Problemen zum Backup- oder Archivdienst den Support-Server des Rechen- und Kommunikationszentrums: bzw. backup@rz.rwth-aachen.de archive@rz.rwth-aachen.de Generelle Informationen zum Backup- und Archivdienst erhalten Sie auf den Webseiten des Rechen- und Kommunikationzentrums unter: Die Backup-Client-Software halten wir für alle gängigen Betriebssysteme für Sie bereit. Sie können die Software für die verschiedenen Betriebssysteme von folgender Seite beziehen: 4

6 ANMELDUNG BACKUP-/ ARCHIVDIENST Der z.z. aktuelle Client liegt in der Version 5.2 für die Betriebssysteme Windows ME/NT/2000/2003, Linux, AIX, Appel Macintosh, Novell Netware, Solaris, Irix, HP- UX und True64Unix vor. Offizielle Dokumentation zu den verschiedenen aktuellen Clients können Sie von unserem Support-Server unter der folgenden Adresse sowohl im pdf- als auch im HTML- Format beziehen: Anmeldung Backup-/ Archivdienst Wenn Sie den Backupdienst nutzen möchten, beantragen Sie bitte per an einen Knotennamen für das zu sichernde System. Für die Nutzung des Archivdienstes beantragen Sie bitte einen Account mit dem Antragsformular, das Sie unter folgender Adresse finden: Bitte beachten Sie, dass der Archivaccount ein Jahr gültig ist und rechtzeitig verlängert werden muss. 1.3 Spielregeln Zur sinnvollen Nutzung des Backupdienstes sind seitens der jeweiligen Einrichtung einige wenige Spielreglen zu beachten, ohne die dem Anspruch, eine wirksame Sicherung der Daten eines Rechners durchzuführen, nicht entsprochen werden kann: Der Backup-Dienst muss seitens der Einrichtung von zwei verlässlichen Ansprechpartnern betreut werden, die sich auch mit den Grundlagen von TSM vertraut machen, z. B. anhand der Unterlagen der Weiterbildungsveranstaltung. Der zu sichernde Rechner muss in der Regel permanent am Hochschuldatennetz erreichbar sein. Nur so ist sicherzustellen, dass das tägliche (genauer: nächtliche) Backup auch durchgeführt werden kann. Die Netzanbindung muss dem Sicherungsvolumen angemessen sein, so dass einerseits die täglichen Sicherungen im Laufe einer Nacht erfolgen können, aber auch z. B. ein Restore des gesamten Servers in realistischen Zeiträumen möglich ist. Die Tabelle auf Seite 15 kann hierbei als erste Orientierungshilfe gesehen werden. Rechen- und Kommunikationszentrum 5 Einführung in TSM

7 HARD- UND SOFTWAREAUSSTATTUNG 1.4 Hard- und Softwareausstattung Backupserver Als Backupserver kommt eine IBM pseries 650 6M2 mit 8 POWER4+ 1,45 GHz Mikroprozessoren und 64 GB Hauptspeicher zum Einsatz. Die Maschine ist mit 6 Gbit Ethernet Adaptern ausgestattet und stellt somit genügend Netzwerkbandbreite zur Verfügung, um auch grosse Datenmengen problemlos über das Netzwerk entgegennehmen zu können. Als Plattencache dienen 3 FAStT 900 Plattensysteme von IBM mit einer Gesamtkapazität von 30 TB. Als Robotorsystem kommt eine IBM 3494 Library mit ca Bandplätzen in 10 Schränken zum Einsatz. Diese bietet bei der aktuellen Bestückung mit ca Bändern eine Kapazität von 0,5 PB. In der Libraray sind 16 IBM Jaguar 3592 Laufwerke (FC attached) installiert. Der Backupserver läuft unter dem Betriebsystem AIX 5.2. Momentan werden 12 logische TSM-Server (Version ) eingesetzt. 10 dieser logischen Server dienen den einzelnen Fachbereichen der RWTH als Backupserver, einer wird als Backupserver für das Rechen- und Kommunikationszentrum eingesetzt und ein weiter Server wird zur Verwaltung der Bandlaufwerke und Tapes verwendet Archivserver Zurzeit wird als Archivserver eine IBM pseries 660 6H1 verwendet. Diese Maschine besitzt vier RS64 IV 750 MHz Mikroprozessoren und 16 GB Hauptspeicher. Als Plattencache dienen zwei Easy Raid - Raidsysteme mit jeweils einer Kapazität von 1 TB, sodass ein Gesamtcache von 2 TB zu Verfügung steht. TSM-Datenbank und TSM-Recovery Log sind jeweils auf eigene RAID-Systeme ausgelagert. Als Robotorsystem kommt eine IBM 3494 Libraray mit 2832 Bandplätzen in 8 Schränken zum Einsatz. Diese bietet eine Gesamtkapazität von 78 TB. In der Library sind 10 IBM Magstar 3590 Laufwerke (SCSI attached) installiert, die zum Schreiben und Lesen der Bänder verwendet werden. Der Archivserver läuft unter dem Betriebsystem AIX 5. Zur Zeit wird ein logischer TSM Server (Version ) als Archivserver betrieben. Rechen- und Kommunikationszentrum 6 Einführung in TSM

8 AKTUELLE BELEGUNG 1.5 Aktuelle Belegung Zur Zeit nutzen ca. 180 Einrichtungen der RWTH den zentralen Backupdienst des Rechen- und Kommunikationzentrums mit ca. 710 Rechnern und einer Nettobelegung von knapp 100 TB. Der Archivdienst hat mit ca. 125 verzeichneten Benutzern eine Belegung von knapp 7 TB. Dabei nimmt der Backupserver in der Spitze täglich bis zu 1,8 TB Daten entgegen. Im Durchschnitt werden pro Tag 10 GB restauriert. Rechen- und Kommunikationszentrum 7 Einführung in TSM

9 Kapitel 2 Einführung in TSM 2.1 Arbeitsweise von TSM Der TSM-Server arbeitet mit Hilfe einer Datenbank in der sämtliche Informationen über gesicherte Objekte gespeichert werden. Im Gegensatz zu den meisten anderen verfügbaren Backupprodukten, arbeitet TSM auf Dateiebene. Dies bedeutet, dass jede Datei als ein Objekt betrachtet wird und einzeln angesprochen werden kann. Generell verfolgt TSM die Strategie von inkrementellen Sicherungen. Nach einem Fullbackup werden dem TSM-Server nur noch die Änderungen im Filesystem übermittelt. Im Gegensatz zu herkömmlichen inkrementellen Sicherungen werden auch Informationen über gelöschte Dateien zum TSM-Server gesendet. Dies ist aufgrund der Arbeitsweise auf Dateiebene möglich. Vorteile sind hierbei in der geringeren zu übertragenden Datenmenge aufgrund der inkrementellen Sicherung zu sehen, die bei zyklisch durchgeführten Fullbackups, um ein erhebliches größer ist und zudem in der Tatsache, dass der Speicherplatz für gelöschte Dateien freigegeben werden kann. Aufgrund der Tatsache, dass alle Informationen über die Dateien im Filesystem in der TSM-Datenbank gespeichert sind, ist es möglich, beliebige Zustände des Filesystems zu restaurieren. TSM arbeitet mit Softwaremodulen die die Kommunikation zwischen Client und Server ermöglicht. Die Kommunikation läuft dabei über das TCP/IP Protokoll ab. 2.2 Versionierung und Aufbewahrungsdauer von Dateien TSM bietet die Möglichkeit mehrere Versionen von Dateien zu sichern. Unterschieden wird dabei zwischen aktiven und inaktiven Versionen. Die jeweils aktuelle Version einer gesicherten Datei wird dabei als aktive Version bezeichnet, alle weiteren Versionen der Datei werden als inaktive Versionen bezeichnet. Verschiedene Regeln legen 8

10 VERSIONIERUNG UND AUFBEWAHRUNGSDAUER VON DATEIEN fest, wie viele Versionen einer Datei für welche Dauer auf dem TSM-Server gehalten werden. Wird die Datei vom Dateisystem gelöscht, gibt es keine aktive Version dieser Datei mehr, alle Versionen sind inaktiv. Hierbei kann wiederum mit verschiedenen Regeln festgelegt werden, wie viele (inaktive) Versionen dieser gelöschten Datei für welche Dauer gehalten werden und wie lange die aktuellste inaktive Version dieser Datei gehalten wird, bevor endgültig auch die letzte Version verworfen wird. Folgende Parameter legen die Anzahl der Versionen und die Aufbewahrungsdauer fest: Versions Data exists Versions Data deleted Retain extra Versions Retain only Version Anzahl der Versionen einer vorhandenen Datei Anzahl der Versionen einer gelöschten Datei Dauer (Tage), für die inaktive Versionen einer Datei gehalten werden Dauer (Tage), für die die letze Version einer gelöschten Datei gehalten wird Die aktuellen Regeln, nach denen die Daten gesichert werden, können auf dem Client mit dem Punkt View Policy im Menü Utilities abgefragt werden. Es ist auch möglich, Dateien nach verschiedenen Regeln zu sichern (wenn mehrere Sets vom Server aus zur Verfügung gestellt werden). Mehr dazu siehe Sicherung über verschiedene Managmentklassen auf Seite Beispiel Folgendes Beispiel hilft, die Funktionsweise der Parameter zu verstehen: Versions Data exists 3 Versions Data deletet 2 Retain extra Versions 7 Retain only Version 10 Rechen- und Kommunikationszentrum 9 Einführung in TSM

11 VERSIONIERUNG UND AUFBEWAHRUNGSDAUER VON DATEIEN Tag Version o 2 o 3 - o 4 - o 5 - o o o o o 10 A - o o o 13 A - - o 14 B - - o o 16 C - x 17 - x 18 - x 19 - x 20 - x 21 A x 22 x 23 x 24 x 25 x 26 D o aktive Version - inaktive Version x letzte inaktive Version einer gelöschten Datei Am 3., 6., 11., 13. und 14. Tag wurde die Datei geändert. Am 16. Tag wurde die Datei gelöscht. A B C D Version wird gelöscht, weil sie älter als 7 Tage ist (Retain Extra Versions) Version wird gelöscht, weil nur 3 Versionen einer Datei gehalten werden (Versions Data Exists) eine Version wird gelöscht, weil nur 2 Versionen einer gelöschten Datei aufgehoben werden (Versions Data Deleted) endgültige Löschung der letzen Version nach 10 Tagen (Retain Only Version) Rechen- und Kommunikationszentrum 10 Einführung in TSM

12 SICHERUNGSMÖGLICHKEITEN Anmerkung: Die in diesem Beispiel verwendeten Werte sind nicht repräsentativ für die Einstellungen auf dem TSM-Server. Die Einstellungen wurden speziell für dieses Beispiel ausgewählt. Auch nur kleine Änderungen an diesen Werten können die Auslastung der Library in erheblichem Maße beeinflußen. In Zukunft wird beabsichtigt, mehrere Sets dieser Einstellungen für verschiedenen Arten von Dateien zur Verfügung zu stellen. Sie sollten dann möglichst Daten, die beispielsweise reproduzierbar sind, über ein anderes Set sichern (welches weniger Versionen und kürzere Haltezeiten vorgibt) als beispielweise nicht reprodizierbare Benutzerdaten. Mehr dazu siehe Sicherung über verschiedene Managmentklassen auf Seite Sicherungsmöglichkeiten TSM bietet die Möglichkeit sowohl von Hand initiierte Sicherungen als auch automatisierte Sicherungen durchzuführen. Um eine regelmäßige Durchführung der Sicherung zu gewährleisten, empfiehlt es sich, die automatisierte Sicherung durchzuführen. Nähres dazu finden Sie auch unter dem Punkt Installation des Schedulers auf Seite 32. An dieser Stelle sei darauf hingewiesen, dass eine einmal konfigurierte und lauffähige automatisierte Sicherung nicht dauerhaft korrekt laufen muss. Durch eine Fülle von verschiedensten Ursachen, kann es zu Problemen in der automatisierten Sicherung kommen. Deswegen ist es unerlässlich, regelmässige Kontrollen und Auswertungen der Logfiles durchzuführen, um eine korrekte Datensicherung zu garantieren. 2.4 Stärken / Schwächen von TSM Wie jedes Softwareprodukt besitzt auch der Tivoli Storage Manager Stärken und Schwächen. Diese (möglicherweise auch subjektiven) Eigenschaften sollen kurz aufgezeigt werden. Stärken: Backup auf Dateiebene; es entfallen Zyklen von Voll- und inkrementellen Sicherungen, Versionierung von Dateien Unterstützung von verschiedensten Betriebssystemen und Filesystemen viele Konfigurationsmöglichkeiten (auch als Schwäche zu sehen) schnell und zuverlässig (bei vorausgesetzer guter und schneller Netzinfrastruktur) Rechen- und Kommunikationszentrum 11 Einführung in TSM

13 STÄRKEN / SCHWÄCHEN VON TSM Schwächen: Problem beim Restore großer Filesysteme (teilweise behebbar über Backupsets) Journal Based Backup nur für Windows-Systeme Open File Support nur für Windows-Systeme Disaster Recovery Rechen- und Kommunikationszentrum 12 Einführung in TSM

14 Kapitel 3 Voraussetzung zur Nutzung des Backupdienstes 3.1 Randbedingungen Generell sollte wenn möglich eine automatisierte Sicherung mit Hilfe des Schedulers betrieben werden. Aufgrund konzeptioneller und adminstrativer Gegebenheiten werden Backups nur zwischen 18:00 Uhr und 05:00 Uhr mit einem Zeitfenster von max. 10 Stunden durchgeführt. Voraussetzung dafür ist, dass der Client in dieser Zeit eingeschaltet und über das Netzwerk erreichbar ist. 3.2 Backup Client Um problemlose Sicherungen durchführen zu können, sollte der Backup-Client sowohl einige Anforderungen an die Hardware als auch an das Betriebsystem erfüllen. Generell sind diese durch die Anforderungen der Backup-Client-Software gegeben. Das System sollte jedoch nicht älter als zwei Jahre sein und genügend CPU Leistung und Arbeitsspeicher zur Verfügung stellen. Das Betriebsystem sollte aktuell sein und durch Updates auf einem aktuellen Stand gehalten werden. Unterstüzt werden in der Version 5.2 die folgenden Betriebsysteme: AIX 5.1, 5.2 (32-bit und 64-bit) HP/UX 11.0, 11i (32-bit und 64-bit) Linux/x kernel: Red Hat 7.2, 7.3, 8, 9, Advanced Server 2.1; SuSe 7.3, 8.0, 8.1 und SLES 7 und 8; Turbo Linux 7.5, 8.0 Linux für pseries 2.4 Kernel (SuSE 8.0) 13

15 NETZWERK Linux für iseries 2.4 Kernel (SuSE 8.0) Linux IA Kernel (SLES 8, RHEL 3.0) Linux/390 und zseries 2.4 kernel (SuSE Linux Enterprise Server 7 und 8) Macintosh X(10).x Novell NetWare 5.1, 6, 6.5 OS/390, zseries USS (S/390 V2R10 mit SMP/E, z/os V1R1, V1R2, V1R3, V1R4) OS/ oder 5.2 API Client SGI IRIX UNIX, Release 6.5 mit EFS oder XFS Filesystem Sun Solaris 7, 8, 9 (32-bit und 64-bit) Tru64 UNIX, Version 5.1A Windows XP (32-bit und 64-bit), Windows 2003 Server (32-bit und 64-bit), Windows 2000 Professional, Server, Advanced Server, Datacenter Server Windows NT4.0 SP5 und SP6a 3.3 Netzwerk Einer der wichtigsten Punkte für ein problemloses Backup, ist ein korrekt konfiguriertes Netzwerk. Häufig fallen Netzprobleme im normalen Betrieb nicht auf. Deshalb sollte vor der Inbetriebnahme des Backupdienstes das Netzwerk überprüft werden. Eine ausführliche Anleitung an dieser Stelle würde allerdings den Rahmen sprengen. Deshalb werden einige häufige Fehlerquellen kurz angesprochen: Leitungen defekt Netzwerkkarte arbeitet nicht im korrekten Modus (10 MBit / 100 MBit / 1000 MBit / Half- / Fullduplex). Die Netzwerkkarte sollte im Fullduplex-Modus arbeiten Netzwerkkomponenten falsch konfiguriert ( Half- / Fullduplex / Autonegotiation ). Switche/Router sollten nicht auf Autonegotiation gestellt werden, sondern auf Fullduplex konfiguriert werden. Routen falsch gesetzt Weiterhin ist eine Fülle weiterer Fehlerquellen für ein langsames Netzwerk denkbar. Dies müsste im Einzelfall genauer untersucht werden. Bei Fragen oder Problemen im Bereich Netzwerk können Sie sich gerne an die Netzwerkabteilung des Rechen- und Kommunikationzentrums wenden: Rechen- und Kommunikationszentrum 14 Einführung in TSM

16 OFFENE DATEIEN Zum Messen von Durchsatzraten in einem Netzwerk gibt es für fast alle Betriebssysteme frei verfügbare Benchmark-Programme. Diese können hilfreich sein um Netzwerkprobleme zu erkennen. Frei verfügbare Tools sind z.b.: netio iperf ftp... Weiterhin ist durch das Netzwerk auch die Menge der zu sichernden Daten beschränkt. Um in dem vorgegebenen Zeitfenster von max. 10 Stunden eine Sicherung durchführen zu können, können Sie sich an folgenden Datenmengen grob orientieren: 10 Mbit 10 GB 100 Mbit 100 GB 1000 MBit 1 TB Diese Angaben sind nur Richtwerte und sind stark abhänig von der Leistung des Clients und von der Leistung des Netzwerkes. Sollte bei einem entsprechenden Netzwerk die Datenmenge deutlich überschritten werden, ist entweder mehr Netzwerkperformance zur Verfügung zu stellen oder auf eine geeignete Auswahl der zu sichernden Daten zu achten. 3.4 Offene Dateien Ein Problem bei der Duchführung eines Backups besteht darin, dass sich eine zu sichernde Datei zum Zeitpunkt der Sicherung nicht in Zugriff durch einen anderen Prozess befinden darf, da diese sonst nicht gesichert werden kann und im Extremfall das aktuelle Backup fehlerhaft beendet. Deshalb ist darauf zu achten, dass andere Prozesse derart koordiniert werden, dass Kollisionen mit zu sichernden Dateien vermieden werden. Eine andere Möglichkeit besteht darin, kritische Dateien vom Backup auszuschliessen. Beispielsweise wäre dann neben der automatisierten Sicherung, eine händische Sicherung dieser kritischen Dateien in gewissen Zeitabständen denkbar. Für Windows 2000 und Windows XP besteht, mit dem ab Client 5.2 verfügbaren Feature Open File Support (OFS), die Möglichkeit, offene Dateien zu sichern. Open File Support wird auf Seite 38 ausführlich dargestellt. Rechen- und Kommunikationszentrum 15 Einführung in TSM

17 FIREWALL / PAKETFILTER 3.5 Firewall / Paketfilter Sollte eine Firewall oder ein Paketfilter betrieben werden, so ist darauf zu achten, dass der entsprechende Port auf dem Backupserver backup01 - backup11 vom Backupclient aus erreichbar ist. Bei der Nutzung des Archivdienstes muss der Port 1502 auf dem Backupserver archive.rwth-aachen.de vom Backupclient aus erreichbar sein. 3.6 ICMP/UDP Ports Zur Fehlerdiagnose sollte bei einem verwendeten Firewall/Paketfilter der Dienst ping und der Dienst traceroute freigegeben werden. 3.7 Sicherung von Netzlaufwerken / gemounteten Filesystemen Auf die Sicherung von Netzlaufwerken oder gemounteten Filesystemen von einem Backup-Client aus, sollte möglichst verzichtet werden. Dies hat zwei Gründe: 1. Sollte das Netzlaufwerk oder das gemountete Filesystem nicht erreichbar sein (Rechner ausgeschaltet, rpc-dienste nicht verfügbar), so kann dies im Extremfall dazu führen, dass das gesamte Backup fehlerhaft abbricht. 2. Das für Windows-Systeme verfügbare Journal Based Backup kann nur für lokale Partionen betrieben werden 3. Diese Sicherungsmethode ist von IBM nicht supported. Deshalb sollte für jedes zu sichernde System ein eigener Knoten beantragt und eingerichtet werden. 3.8 Ansprechpartner Bei der Einrichtung eines Knotens für ein Institut müssen zwei feste Personen angegeben werden, die für die Betreuung des Backup-Clients verantwortlich sind und feste Ansprechpartner für das Rechen- und Kommunikationszentrum darstellen. Bei Einrichtung weiterer Knoten für das selbe Institut sind ebenfalls diese Personen die jeweiligen Ansprechpartner. Dadurch ist es möglich, gezielten Support zu leisten und auch eine bestmögliche Betreuung des Backups für das Institut zu liefern. Diese Ansprechpartner sollten möglichst am Institut festangestellt sein. Somit entfällt der Aufwand bei oft wechselnden Ansprechpartnern Support für gleiche oder wiederauftretende Problemfälle zu leisten. Zudem ist es so möglich auftretende Probleme Rechen- und Kommunikationszentrum 16 Einführung in TSM

18 ANSPRECHPARTNER schneller zu lösen. Bei einem Wechsel der Ansprechpartner oder einem Wechsel der Daten wie Telefonnummer oder -adresse sollte eine entsprechende Benachrichtigung erfolgen. Rechen- und Kommunikationszentrum 17 Einführung in TSM

19 Kapitel 4 Installation und Konfiguration des TSM-Clients 4.1 Installation der Software Zunächst muss die aktuelle Version der Clientsoftware (Version 5.2) heruntergeladen werden. Die Backup-Client-Software halten wir für Sie für alle gängigen Betriebssysteme bereit. Sie kann von folgender Seite bezogen werden: Die Installation des Clients unterscheidet sich grundlegend durch das vorgegebene Betriebssystem. Folgende Tabelle gibt eine Einstiegshilfe in die Installation des Clients. Betriebssystem Mac OS HP-UX AIX Linux Windows IRIX Solaris Novell Installation Doppelklick TSM Installer Icon zum Starten des Setup Wizards Mit sam oder mittels /usr/sbin/swinstall -x mount all filesystems=false -v -s pwd /TIVsmC TIVsm smit install rpm -i TIVsm-BA.i386.rpm Doppelklick Icon zum Starten des Setup Wizards /usr/sbin/inst -a -f pwd -I TSM.sw.base pkgadd -d./tivsmcapi.pkg TIVsmCapi pkgadd -d./tivsmcba.pkg TIVsmCba NWConfig.NLM benutzen Es ist nur notwendig den Tivoli Storage Manager Backup-/Archiv-Client zu installieren. WEB, HSM, DFS, FTP oder ähnliche Programmteile werden nicht benötigt und 18

20 INSTALLATION DER SOFTWARE brauchen deshalb auch nicht installiert zu werden. Ausführliche Informationen zur Installation des jeweiligen Clients können Sie der README- Datei im entsprechenden Download-Verzeichnis des Clients entnehmen. Achtung: Einige Clients werden als tar-paket zur Verfügung gestellt. Dieses muss vor der Installation erst entpackt werden. Dazu muss folgendes Kommando abgesetzt werden: tar -xvf <filename.tar> Installation unter Windows 2000 Im folgenden wird gezeigt, wie eine Installation unter Windows 2000 abläuft. Die menügeführte Installation ist mit wenigen Mausklicken abgeschlossen. Anzuwählendes ist jeweils markiert. Nach Angabe in welches Verzeichnis temporär die Installationsdateien kopiert werden, mit Next > bestätigen. Rechen- und Kommunikationszentrum 19 Einführung in TSM

21 INSTALLATION DER SOFTWARE Nach Auswahl der Sprache mit OK bestätigen. Weiter > drücken um mit der Installation fortzufahren. Nach der Auswahl des Installationsverzeichnisses Weiter > klicken. Die zentrale Konfigurtationsdatei dsm.opt wird unterhalb dieses Verzeichnisses im Ordner baclient abgelegt. Rechen- und Kommunikationszentrum 20 Einführung in TSM

22 INSTALLATION DER SOFTWARE Nach Auswahl der Installationsmethode mit Weiter > fortfahren. Installieren > werden alle benötigen Dateien auf das Sys- Durch klicken auf tem übertragen. Rechen- und Kommunikationszentrum 21 Einführung in TSM

23 KONFIGURATION DES CLIENTS (DSM.SYS/DSM.OPT) Klicken auf Fertigstellen beendet die Installation erfolgreich. Achtung: Nach der erfolgreichen Installation sollten Sie den Client noch nicht starten. Zunächst sollte die zentrale Konfigurationsdatei dsm.opt eingerichtet werden, damit eine erfolgreiche Verbindung mit dem Backupserver hergestellt werden kann. Die Einrichtung der Konfigurationsdatei ist im nächsten Abschnitt beschrieben Hinweise zur Installation auf Linux-Systemen Zur Installation des TSM-Clients auf SuSE und Fedora Systemen wird die Bibliothek libstdc++ benötigt. Diese Bibliothek ist auf SuSE Systemen ( 7.3), Redhat Systemen (Version 9) und Fedora Systemen (Core 1 und Core 2) standardmässig nicht installiert. Um den Client installieren zu können, muss diese Bibliothek (zu finden auf den jeweiligen Installationsmedien) nachinstalliert werden. Die Bibliothek ist unter SuSE im rpm-paket compat-200x.x.x-x.x.rpm und unter Redhat und Fedore Systemen im rpm-paket compat-libstdc++-x.x-x.x.x.x.rpm zu finden. Beim Update auf Version 5.x kann es vorkommen, dass symbolische Links unter /usr/bin auf dsm-binaries gelöscht werden. Die Links können mit folgenden Kommandos neu angelegt werden: ln -s /opt/tivoli/tsm/client/ba/bin/dsm /usr/bin ln -s /opt/tivoli/tsm/client/ba/bin/dsmc /usr/bin ln -s /opt/tivoli/tsm/client/ba/bin/dsmadmc /usr/bin 4.2 Konfiguration des Clients (dsm.sys/dsm.opt) Die zentrale Konfigurationsdatei heißt unter Unix dsm.sys und unter Windows dsm.opt. Generell sollte diese Datei zunächst entsprechend angepasst werden, bevor der Backup- Rechen- und Kommunikationszentrum 22 Einführung in TSM

24 KONFIGURATION DES CLIENTS (DSM.SYS/DSM.OPT) client nach der Installation zum ersten Mal aufgerufen wird. Folgende Tabelle zeigt, wo die Konfigurationsdateien jeweils zu finden sind, falls der Standardinstallationspfad nicht verändert wurde: Unix Windows /opt/tivoli/tsm/client/ba/bin/dsm.sys /usr/tivoli/tsm/client/ba/bin/dsm.sys c:\programme\tivoli\tsm\baclient\dsm.opt Wie heisst mein TSM-Server Seit Inbetriebname des neuen TSM-Servers Anfang 2004 dienen dem Backup der Rechner aus der Hochschule insgesamt 10 logische TSM-Server (vorher einer: bas05). Dabei erfolgt die Zuordung eines Knotens zu einem Server über den Fachbereich. Folgende Tabelle zeigt, welcher Fachbereich welchem TSM-Server (und Port) zugeordnet ist: Fachbereich TSM-Server Port 1 backup03.rz.rwth-aachen.de backup04.rz.rwth-aachen.de backup05.rz.rwth-aachen.de backup06.rz.rwth-aachen.de backup07.rz.rwth-aachen.de backup08.rz.rwth-aachen.de backup09.rz.rwth-aachen.de backup10.rz.rwth-aachen.de backup11.rz.rwth-aachen.de 1511 Sonstige backup02.rz.rwth-aachen.de 1502 In der Konfigurationsdatei muss dann SERVERNAME, TCPSERVERADRESS und DEFAULTSERVER mit dem entsprechend ermittelten TSM-Server gesetzt werden, sowie der TCPPORT mit dem ermittelten Port gesetzt werden Einstellen des TSM-Servers und Ports Bei den Einträgen SERVERNAME, TCPSERVERADRESS und TCPPORT sind die X-Zeichen entsprechen der obigen Tabelle zu ersetzen. SERVERNAME TCPSERVERADRESS TCPPORT backupxx.rz.rwth-aachen.de backupxx.rz.rwth-aachen.de 15XX Rechen- und Kommunikationszentrum 23 Einführung in TSM

25 KONFIGURATION DES CLIENTS (DSM.SYS/DSM.OPT) Generelle Einstellungen Folgende Einstellungen müssen unverändert bleiben: COMMMETHOD tcpip PASSWORDACCESS generate SCHEDMODE polling TXNBYTELIMIT Variable Einstellungen Der nächste Eintrag ist der Knotenname des Rechners. Der Knotenname wird bei der Anmeldung mitgeteilt und ist hier entsprechend zu verwenden. NODENAME meinknoten.meinedomain.rwth-aachen.de Die nächsten beiden Zeilen legen fest, welche Dateien als Schedulerlogfile und Errorlogfile verwendet werden. Es sollten geeignete Verzeichnisse und Dateinamen gewählt werden. Die ersten beiden Einträge sind auf einem Windows-System, die nächsten beiden Einträge auf einem Unix-System gültig. SCHEDLOGNAME ERRORLOGNAME SCHEDLOGNAME ERRORLOGNAME c:\logfiles\dsmsched.log c:\logfiles\dsmerror.log /var/log/dsmsched.log /var/log/dsmerror.log Auswahl zu sichernder Partitionen / Filesysteme In diesem Teil muß angegeben werden, welche Partitionen bzw. Filesysteme mit in die Sicherung einbezogen werden sollen. Diese Partitionen bzw. Filesysteme müssen mittels DOMAIN-Statements eingetragen werden. Auch wenn nur ein Teil der Daten von einer Partition gesichert werden soll, muss hier die gesamte Partition angegeben werden. Eine Auswahl von zu sichernden Dateien kann durch weitere Statements getroffen werden, die im nächsten Abschnitt beschrieben sind. Eine Besonderheit ist bei Unix-Systemen zu beachten. Hier muß unterschieden werden, ob der zu sichernde Mountpoint ein eigenes Filesystem ist, oder nicht. Im zweiten Fall muß vor dem DOMAIN-Eintrag des Filesystems ein VIRTUALMOINTPOINT- Statement angegeben werden. Folgende Beispiele sollen die Anwendung von DOMAIN und VIRTUALMOUNTPOINT verdeutlichen. Rechen- und Kommunikationszentrum 24 Einführung in TSM

26 KONFIGURATION DES CLIENTS (DSM.SYS/DSM.OPT) Windows-Beispiel Mit den folgenden Einträgen werden die lokalen Partionen c:, e: sowie das verbundene Netzlaufwerk g$ des Rechners winclient2 gesichert. Generell sollte auf die Sicherung von Netzlaufwerken verzichtet werden. Siehe dazu auch Seite 16. DOMAIN c: DOMAIN e: DOMAIN \\winclient2\g$ Unix-Beispiel Mit den folgenden Einträgen werden /opt und /home/ae106st gesichert, wobei ein seperates Filesytem nach /opt gemountet ist, /home/ae106st aber ein Verzeichnis ist, das im / Filesystem (root-filesystem) liegt. DOMAIN VIRTUALMOUNTPOINT DOMAIN /opt /home/ae106st /home/ae106st Achtung: Es sollte überpüft werden, ob mit einem DOMAIN-Eintrag ein CD-Rom oder DVD-Rom Laufwerk gesichert wird und dieser Eintrag unbedingt entfernt werden. Wir behalten uns vor, gesicherte CD-Roms oder DVDs vom Server zu löschen. Anmerkung: Im wesentlichen spielen die DOMAIN Einträge bei der automatisierten Sicherung eine Rolle. Manuelle Sicherungen wären theoretisch auch ohne diese Einträge möglich. Trotzdem ist es empfehlenswert, diese Einträge direkt bei der Erstellung der dsm.sys/dsm.opt zu berücksichtigen Auswahl zu sichernder Dateien - Include-/Exclude Listen Da es in den meisten Fällen nicht sinnvoll ist, komplette Partitionen zu sichern, kann in diesem Abschnitt angegeben werden, welche Dateien gesichert und welche vom Backup ausgeschlossen werden. Syntaxbeschreibung und Arbeitsweise Um zu steuern, ob Dateien gesichert werden oder nicht, werden folgende Statements verwendet: INCLUDE, EXCLUDE und EXCLUDE.DIR. INCLUDE EXCLUDE EXCLUDE.DIR Dateien werden ins Backup mit einbezogen Dateien werden vom Backup ausgeschlossen Verzeichnis und alle Unterverzeichnisse inkl. aller Dateien werden vom Backup ausgeschlossen Rechen- und Kommunikationszentrum 25 Einführung in TSM

27 KONFIGURATION DES CLIENTS (DSM.SYS/DSM.OPT) Diesen Statements muss eine Datei- oder Verzeichnissangabe folgen, wobei auch Wildcards verwendet werden können. Einige zur Verfügung stehenden Wildcards sind in der folgenden Tabelle ausgeführt:? steht für ein beliebiges Zeichen (ausser Verzeichnisstrenner) steht für eine belibige Zeichenkette... steht für kein, ein oder beliebig viele Verzeichnisse Mittels dieser Statements kann eine Liste von Include-/Exclude-Anweisungen in der dsm.sys/dsm.opt angegeben werden. Bei der Sicherung einer Datei wird anhand dieser Liste überprüft, ob sie in die Sicherung einbezogen oder vom Backup ausgeschlossen wird. Diese Liste wird dabei von unten nach oben abgearbeitet (bottom up) und das erste Statement dessen Muster auf diese Datei paßt, entscheidet darüber ob die Datei gesichert wird oder nicht. Ausnahme bildet das EXCLUDE.DIR-Statement. Dieses wird generell zuerst auf Übereinstimmung mit der aktuellen Datei überprüft, egal an welcher Position es in der Include-/Exclude-Liste steht. Wird kein Statement für eine Datei gefunden, so wird diese implizit included. Beispiel für Unix-Systeme Das folgende Beispiel soll die Verwendung von Include-/Exclude-Statements verdeutlichen. Folgende Statements werden definiert (entsprechende DOMAIN-Einträge seien vorhanden): EXCLUDE.DIR /.../cache * Regel 1 EXCLUDE /usr/software/.../* * Regel 2 EXCLUDE /.../core * Regel 3 EXCLUDE /home/ae106st/nobackup/.../*.test * Regel 4 EXCLUDE /home/ae106st/a.out * Regel 5 INCLUDE /usr/software/netio/.../* * Regel 6 INCLUDE /home/ae106st/nobackup/ausnahme/3.test * Regel 7 Folgende Dateien werden betrachtet: Rechen- und Kommunikationszentrum 26 Einführung in TSM

28 KONFIGURATION DES CLIENTS (DSM.SYS/DSM.OPT) /var/lib/core /usr/software/netio/cache/c1.cah /usr/software/netio/bin/linux /home/ae106st/nobackup/ausnahme/3.test /home/ae106st/nobackup/kernel/2.4.18/system.map.test /home/ae106st/a.out /usr/software/syncro/sync.d/sync.conf /home/ae106st/tsm_config/dsm.sys wird ausgeschlossen - Regel 3 - wird ausgeschlossen - Regel 1 - wird einbezogen - Regel 6 - wird einbezogen - Regel 7 - wird ausgeschlossen - Regel 4 - wird ausgeschlossen - Regel 5 - wird ausgeschlossen - Regel 2 - wird implizit eingeschlossen - da keine Regel definiert - Überprüfen von Include-/Exclude-Statements Da sich beim Definieren der Include-/Exclude-Liste schnell Fehler einschleichen können und wichtige Dateien dadurch fälschlicherweise nicht gesichert werden, empfiehlt es sich, die definierten Regeln auf Korrektheit zu überprüfen. Dazu bietet sich der grafische Backupclient an. Rufen Sie diesen durch Doppelklick auf das entsprechende Icon oder durch das Kommando dsm auf (beim ersten Aufruf nach der Installtion wird die Eingabe des mitgeteilten Passwortes verlangt). Rechen- und Kommunikationszentrum 27 Einführung in TSM

29 KONFIGURATION DES CLIENTS (DSM.SYS/DSM.OPT) Hier muß der Punkt Sichern ausgewählt werden. Greift eine Exclude-Regel für eine Datei, so wird diese Datei durch ein rotes Symbol vor dem Dateinamen gekennzeichnet. Trifft für diese Datei ein Include-Statement zu, Rechen- und Kommunikationszentrum 28 Einführung in TSM

30 KONFIGURATION DES CLIENTS (DSM.SYS/DSM.OPT) so ist dieses Symbol dort nicht zu sehen. Auf Unix-Systemen erscheint der Dateiname von ausgeschlossenen Dateien in roter Schrift. Mittels des Kommandos dsmc q inclexcl werden sowohl alle serverseitig sowie in der dsm.sys/dsm.opt definierten Statements ausgegeben. Es besteht allerdings keine Möglichkeit diese Kriterien testweise auf eine Datei anzuwenden. Dazu müss die oben beschriebene Möglichkeit verwendet werden. Empfohlene Include-/Exclude-Statements Einige Dateien sollten grundsätzlich von der Sicherung ausgeschlossen werden. Im einzelnen sind dies verschiedene Systemdateien diverse Caches - vor allem Browser-Caches Dateien aus dem Papierkorb (Recycler) temporäre Dateien core-files... Dateien dieser Art sollten mit geeigneten Include-/Exclude-Statements von der Sicherung ausgeschlossen werden, da eine Sicherung weder notwendig noch sinnvoll ist, diese Dateien aber trotzdem Ressourcen des Backupservers nutzen. Serverseitig vorgegebene Statements Gerade auch unter dem im vorigen Abschnitt genannten Aspekten werden vom Backup- Server gewisse Exclude-Listen vorgegeben. Diese Exlude-Statements sind als Ergänzung zu eigenen definierten Include-Exclude-Listen zu verstehen. Deshalb sollten für das jeweilige System trotzdem speziell angepaßte Include-Exclude-Listen definiert werden. Zurzeit gibt es für Windows und Unix-Systeme solche Exclude-Listen, die die folgenden Exclude-Statements enthalten: Windows Exclude-Liste: Rechen- und Kommunikationszentrum 29 Einführung in TSM

31 KONFIGURATION DES CLIENTS (DSM.SYS/DSM.OPT) EXCLUDE *:\...\NETSCAPE\...\CACHE\* EXCLUDE *:\...\Microsoft Internet\cache\...\* EXCLUDE *:\...\Microsoft Internet\history\...\* EXCLUDE *:\...\Microsoft Internet\verlauf\...\* EXCLUDE *:\...\Temporary Internet Files\...\* EXCLUDE *:\...\Profiles\...\History\...\* EXCLUDE *:\...\Profiles\...\Verlauf\...\* EXCLUDE *:\macintosh volume\...\* EXCLUDE *:\macintosh volume\...\*.* EXCLUDE *:\microsoft uam volume\...\* EXCLUDE *:\microsoft uam volume\...\*.* EXCLUDE *:\...\EA DATA. SF EXCLUDE *:\...\pagefile.sys EXCLUDE *:\IBMBIO.COM EXCLUDE *:\IBMDOS.COM EXCLUDE *:\MSDOS.SYS EXCLUDE *:\...\SYSTEM32\CONFIG\...\* EXCLUDE *:\...\*.swp EXCLUDE *:\...\win386.swp EXCLUDE *:\...\*.par EXCLUDE *:\...\386spart.par EXCLUDE *:\ffastun.* EXCLUDE *:\ffastun0.* EXCLUDE *:\...\dblspace.* EXCLUDE *:\...\drvspace.* EXCLUDE *:\Recycler\...\* EXCLUDE *:\Recycled\...\* EXCLUDE *:\...\dsmerror.log EXCLUDE *:\...\dsmsched.log UNIX Exclude-Liste: EXCLUDE.DIR /.../.kde/share/cache/http/.../* EXCLUDE /.../.mozilla/.../.../cache/.../* EXCLUDE /.../.netscape/cache/.../* EXCLUDE core EXCLUDE /.../dsmerror.log EXCLUDE /.../dsmsched.log Achtung: Da diese Statements bereits definiert sind, dürfen sie nicht noch einmal in der dsm.sys/dsm.opt definiert werden. Doppelte Definitionen können zu Fehlern führen und sind deshalb zu vermeiden. Rechen- und Kommunikationszentrum 30 Einführung in TSM

32 PASSWORT Sichern über verschiedene Managmentklassen Wie bereits erwähnt, ist es sinnvoll verschiedene Arten von Dateien nach verschiedenen Regeln zu sichern. Siehe dazu auch Versionierung und Aufbewahrungsdauer von Dateien auf Seite 8. Realisiert wird die Zuweisung von Regelsätzen (Managmentklassen) an Dateien über INCLUDE-Anweisungen. Definiert seien auf dem Server die beiden Managmentklassen STANDARD und DYNAMIC. Die folgenden Statements verdeutlichen wie verschiedenen Haltezeiten für Dateien vereinbart werden: INCLUDE /work/.../kurzzeitig/.../* DYNAMIC INCLUDE /home/.../tests/.../* DYNAMIC Diese Statements bewirken, dass alle Dateien, auf die die INCLUDE-Muster zutreffen, über die Managmentklasse DYNAMIC gesichert werden und nach den Regeln gehalten werden, die in dieser Managmentklasse definiert sind. Die aktuellen Regeln, nach denen die Daten gesichert werden, können auf dem Client mit dem Punkt View Policy im Menü Utilities abgefragt werden. 4.3 Passwort Bei der Beantragung eines Knotens wir neben dem Knotennamen auch ein Passwort mitgeteilt. Nach erfolgreicher Installation und Konfiguration des Clients sollte der grafische Client mittels dsm oder durch Doppelklick auf das entsprechende Icon aufgerufen werden. Beim ersten Aufruf ist die Eingabe des Knotennamens und des Passworts notwendig. Durch die in der dsm.sys/dsm.opt gesetzte Option PASSWORDACCESS generate handelt der Client mit dem Server nach der ersten Anmeldung und dann jeweils nach 90 Tagen ein neues Passwort aus, das verschlüsselt auf dem Server und dem Client abgelegt wird. Unter Windows wird das Passwort in der Registry abgespeichert und kann mit dem folgenden Kommando im Klartext ausgegeben werden: dsmcutil SHOWPW /node:<nodename> Unter Unix ist eine Ausgabe des Passworts im Klartext nicht möglich. Mittels der Option PASSWORDDIR /rwth/stage/tsm_pwd Rechen- und Kommunikationszentrum 31 Einführung in TSM

33 INSTALLATION DES SCHEDULERS ist es möglich ein Verzeichnis anzugeben, in dem das Passwort in verschlüsselter Form in einer Datei (TSM.pwd) abgespeichert wird. Es ist empfehlenswert, sich das Passwort in periodischen Abständen per Mail zuschicken zu lassen. Unter Windows kann dies durch ein Skript erreicht werden, das zunächst mittels der oben angegebenen Methode das Passwort ermittelt und anschliessend verschickt. Bei Unix-Systemen kann in der dsm.sys die Option MAILPROG <filespec> <userid> angegeben werden. Diese Option bewirkt, dass das Passwort nach einer automatischen Änderung (nur bei gesetzter Option PASSWORACCESS generate) per Mail an den Empfänger geschickt wird. Ein Eintrag könnte folgendermassen aussehen: MAILPROG /usr/ucb/mail -s "Knoten GUESTC2" Unter Unix sollte der mittes PASSWORDDIR angegebene Pfad auf ein nicht lokales Filesystem verweisen, sodass im Falle einer Neuinstallation oder eines Plattencrashes, dass Passwort weiter verfügbar ist. Sollten trotzdem Probleme mit dem Passwort entstehen, ist es möglich, dies auf dem Server auf das Initialpasswort (bei der Anmeldung erhalten) zurückzusetzen. 4.4 Installation des Schedulers Um eine automatisierte Sicherung durchzuführen, muss der Scheduler installiert bzw. gestartet werden. Es werden die nötigen Schritte für Windows- und Unix-Systeme gezeigt Windows 2000 Der Scheduler kann als Dienst unter Windows 2000 mit folgendem Kommando installiert und gleichzeitig gestartet werden: dsmcutil install /name:"tsm Client Scheduler" /node:nodename /password:"password" /autostart:yes Wie das entsprechende Passwort zum Knotennamen ermittelt werden kann, ist in Abschnitt Passwort auf Seite 31 beschrieben. Dieses Kommando richtet den Scheduler als Dienst ein und startet ihn. Folgende Ausgabe sollte auf der Kommandozeile zu sehen sein: Rechen- und Kommunikationszentrum 32 Einführung in TSM

34 INSTALLATION DES SCHEDULERS Unter den Diensten sollte folgender Eintrag zu sehen sein: Standardmäßig wird der Scheduler unter Windows unter dem Systemkonto Local System gestartet. Falls die Sicherung eines Netzlaufwerkes notwendig ist, muss der Scheduler unter dem Systemkonto laufen, welches Zugriff auf das Netzlaufwerk hat. Rechen- und Kommunikationszentrum 33 Einführung in TSM

35 INSTALLATION DES SCHEDULERS Unix Der Scheduler kann unter Unix mit folgendem Kommando gestartet werden: dsmc sched Dabei wird der Scheduler im Vordergrund gestartet. Beim Ausloggen aus dem System wird dieser wieder beendet. Um dies zu verhindern, sollte der Scheduler im Hintergrund und unabhängig von der Shell gestartet werden: nohup dsmc sched 1>/dev/null 2>&1 & Es ist dringend erforderlich, den Scheduler über ein Startup-Skript zu starten, damit dieser auch nach einem Reboot der Maschine aktiv ist. Folgendes Init-Skript (für Red- Hat Linux) kann dazu verwendet werden. Diese sollte in /etc/rc.d/init.d/ liegen und entsprechende Links für die jeweiligen Runlevel gesetzt sein: #!/bin/bash # # description: starts TSM backup client scheduler. # # processname: dsmc # pidfile: none LANG=en_US export LANG start() { if [ -x /usr/bin/dsmc ]; then echo "Starting dsm" ulimit -d unlimited ulimit -f unlimited ulimit -t unlimited nohup /usr/bin/dsmc sched >/dev/null 2>&1 & else echo "dsm: couldn t find binary" fi } stop() { echo "Shutting down dsm services: " pid= /bin/ps -eo pid,cmd grep -i "dsmc sched" grep -v grep /usr/bin/sed -e s/ˆ *// -e s/.*// if [ "${pid}"!= "" ]; then echo "Stopping TSM scheduler" echo ${pid} /bin/kill -9 ${pid} 2> /dev/null fi } Rechen- und Kommunikationszentrum 34 Einführung in TSM

36 INSTALLATION DES SCHEDULERS case "$1" in start) start ;; stop) stop ;; restart) stop start ;; *) echo $"Usage: $0 {start stop restart}" exit 1 esac Unter Unix-Systemen ist darauf zu achten, dass der Scheduler-Prozess mit root- Rechten gestartet wird, um Zugriff auf alle zu sichernden Dateien zu haben. Um zu überprüfen, ob der Scheduler-Prozess läuft, kann das folgende Kommando verwendet werden: ps -ef grep -v grep grep dsmc Das Kommando liefert als Ausgabe den Scheduler-Prozess. Die Ausgabe enthält neben einigen Prozessinformationen das zugrundeliegende Kommando dsmc sched Aufgaben des Administrators Der Client ist jetzt konfiguriert, um tägliche, automatisierte Backups durchzuführen. Nach Einrichtung des Schedulers sollte regelmäßig überprüft werden, ob der Scheduler noch korrekt läuft, weiterhin sollten die beiden Logfiles dsmsched.log und dsmerror.log regelmäßig auf ein korrekt durchgeführtes Backup hin überprüft werden. In dsmsched.log ist nach jedem Backup ein Backupbericht vorhanden. Weisen die Dateien keine aktuellen Einträge auf, so ist davon auszugehen das der Scheduler nicht mehr korrekt läuft. Ein Neustart behebt in der Regel das Problem. Sind andere Fehlermeldungen vorhanden, müssen die entsprechenden Probleme behoben werden, um ein korrektes Backup zu garantieren. Beim ersten Start des Schedulers muß eine Information über das nächste auszuführende Backup in der dsmsched.log vorhanden sein. Sollte dies nicht der Fall sein, gab es ein Problem beim Starten des Schedules. Sollten Änderungen an der dsm.sys/dsm.opt vorgenommen werden, muss der Scheduler neu gestartet werden, damit die Änderungen wirksam werden. Rechen- und Kommunikationszentrum 35 Einführung in TSM

37 WEITERE PARAMETER FÜR DSM.SYS/DSM.OPT Eine häufige Ursache für ein fehlerhaftes Backup sind Dateien, die sich zum Zeitpunkt der Sicherung im Zugriff durch einen anderen Prozess befinden. Der Scheduler meldet ein fehlerhaftes Backup mit return code 4. Hier sollten entsprechende Maßnahmen getroffen werden. Siehe dazu auch den Punkt Koordination mit anderen Prozessen auf Seite Weitere Parameter für dsm.sys/dsm.opt Es gibt eine Fülle weiterer Parameter die in der dsm.sys/dsm.opt angegeben werden können. Im folgenden wird eine Auswahl der wichtigsten Parameter vorgestellt: Option INCLEXCL MEMORYEFFICIENTBACKUP PRESCHEDULECMD POSTSCHEDULECMD SCHEDLOGRETENTION ERRORLOGRETENTION DATEFORMAT TIMEFORMAT NUMBERFORMAT RESOURCEUTILIZATION GUITREEVIEWAFTERBACKUP Bedeutung gibt eine Datei an, die zu verwendende Include-/Exclude Statements enthält Verwendung eines speicherschonenden Backupalgorithmus Systemkommando, das vor der Ausführung des Schedules abgesetzt wird Systemkommando, das nach der Ausführung des Scheudles abgesetzt wird Anzahl der Tage, die Einträge im Schedulerlogfile gehalten werden Anzahl der Tage, die Einträge im Errorlogfile gehalten werden Datumsformat definieren Zeitformat definieren Zahlenformat definieren Anzahl der Clientsession definieren Rückkehr zum Hauptfenster oder zum Backup/Restore-Fenster festlegen Alle weiteren Optionen können der offiziellen Dokumentation für den jeweiligen Client entnommen werden. Dort sind auch die genauen Syntaxbeschreibungen der Optionen und ihrer Parameter zu finden. Siehe dazu auch Kapitel Ansprechpartner und nützliche Links auf Seite Datums-, Zeit- und Zahlenformat Bei den Optionen DATEFORMAT, TIMEFORMAT, NUMBERFORMAT muss eine Zahl als Parameter angegeben werden, die das zu verwendende Format spezifiziert. Die für Deutschland üblichen Formate können mit folgenden Angaben gewählt werden: Rechen- und Kommunikationszentrum 36 Einführung in TSM

38 UNICODE DATEFORMAT 4 TIMEFORMAT 1 NUMBERFORMAT 4 Dadurch werden Fomate der folgenden Form verwendet: 4.6 Unicode Datum Zeit Zahl : Bei der Sicherung von Dateien, die Umlaute oder Sonderzeichen im Dateinamen enthalten, kann es zu Problemen kommen, so dass diese Dateien nicht gesichert werden Windows Unter Windows stellt die Sicherung mit dem aktuellen Client keine Probleme dar. Filespaces werden im Unicode-Format gesichert, so dass auch Dateien mit Umlauten oder Sonderzeichen im Dateinamen gesichert werden. Bei Clients, die bereits Sicherungen im Nicht-Unicode-Format durchgeführt haben, kann eine Umwandlung, nach Update auf den aktuellen Client, erzwungen werden. Für alle Windows Systeme ist diese Umwandlung bereits eingerichtet, so dass nach einem Clientupdate eine Umwandlung ins Unicode-Format durchgeführt wird. Dabei werden die alten Filespaces auf dem TSM-Server umbenannt und ein neues Fullbackup im Unicode-Format durchgeführt. Sollte eine Unicodeumwandlung noch nicht stattgefunden haben, ist es empfehlenswert Kontakt mit dem Rechen- und Kommunikationszentrum aufzunehmen und diese Umwandlung durchzuführen Unix Um unter Unix-Systemen Dateien sichern zu können, die Umlaute oder Sonderzeichen im Dateinamen enthalten, muss die Umgebungsvariable LANG auf en_us gesetzt sein. Ein Aufruf des Kommandos locale gibt Auskunft darüber, wie die Variable gesetzt ist. Sollte hier kein Eintrag der Form LANG=en_US vorhanden sein, muss die Variable entsprechend gesetzt werden. Dies kann durch folgenden Aufruf erreicht werden: export LANG=en_US Rechen- und Kommunikationszentrum 37 Einführung in TSM