Skript

Transcription

Skript

Zentrale Datensicherung an der
RWTH Aachen Einführung in TSM
23. Juni 2004
Daniel Stanek
stanek@rz.rwth-aachen.de
Rechen- und Kommunikationszentrum RWTH Aachen
Inhaltsverzeichnis
1 Überblick über die zentrale Datensicherung an der RWTH Aachen
1.1 Ansprechpartner und nützliche Links . . . . . . . . . . . . . . . .
1.2 Anmeldung Backup-/ Archivdienst . . . . . . . . . . . . . . . . .
1.3 Spielregeln . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4 Hard- und Softwareausstattung . . . . . . . . . . . . . . . . . . .
1.4.1 Backupserver . . . . . . . . . . . . . . . . . . . . . . . .
1.4.2 Archivserver . . . . . . . . . . . . . . . . . . . . . . . .
1.5 Aktuelle Belegung . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4
4
5
5
6
6
6
7
2 Einführung in TSM
2.1 Arbeitsweise von TSM . . . . . . . . . . . . . . . .
2.2 Versionierung und Aufbewahrungsdauer von Dateien
2.2.1 Beispiel . . . . . . . . . . . . . . . . . . . .
2.3 Sicherungsmöglichkeiten . . . . . . . . . . . . . . .
2.4 Stärken / Schwächen von TSM . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8
8
8
9
11
11
3 Voraussetzung zur Nutzung des Backupdienstes
3.1 Randbedingungen . . . . . . . . . . . . . . . . . . . . . . .
3.2 Backup Client . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 Netzwerk . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4 Offene Dateien . . . . . . . . . . . . . . . . . . . . . . . .
3.5 Firewall / Paketfilter . . . . . . . . . . . . . . . . . . . . . .
3.6 ICMP/UDP Ports . . . . . . . . . . . . . . . . . . . . . . .
3.7 Sicherung von Netzlaufwerken / gemounteten Filesystemen .
3.8 Ansprechpartner . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
13
13
13
14
15
16
16
16
16
4 Installation und Konfiguration des TSM-Clients
4.1 Installation der Software . . . . . . . . . . . . . . . .
4.1.1 Installation unter Windows 2000 . . . . . . . .
4.1.2 Hinweise zur Installation auf Linux-Systemen .
4.2 Konfiguration des Clients (dsm.sys/dsm.opt) . . . . . .
4.2.1 Wie heisst mein TSM-Server . . . . . . . . . .
4.2.2 Einstellen des TSM-Servers und Ports . . . . .
4.2.3 Generelle Einstellungen . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
18
18
19
22
22
23
23
24
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
INHALTSVERZEICHNIS
4.2.4 Variable Einstellungen . . . . . . . . . . . . . . . . . . . . .
4.2.5 Auswahl zu sichernder Partitionen / Filesysteme . . . . . . .
4.2.6 Auswahl zu sichernder Dateien - Include-/Exclude Listen . . .
4.2.7 Sichern über verschiedene Managmentklassen . . . . . . . .
Passwort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Installation des Schedulers . . . . . . . . . . . . . . . . . . . . . . .
4.4.1 Windows 2000 . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.2 Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4.3 Aufgaben des Administrators . . . . . . . . . . . . . . . . .
Weitere Parameter für dsm.sys/dsm.opt . . . . . . . . . . . . . . . .
4.5.1 Datums-, Zeit- und Zahlenformat . . . . . . . . . . . . . . .
Unicode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6.1 Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6.2 Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6.3 Samba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Open File Support (OFS) . . . . . . . . . . . . . . . . . . . . . . . .
4.7.1 Installation des LVSA mit ”Open File Support” . . . . . . . .
4.7.2 Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . .
Automatisches Ausschalten eines Rechners nach einem automatisierten Backup (Windows) . . . . . . . . . . . . . . . . . . . . . . . . .
4.8.1 Scheduler-Dienst mit Administrator-Rechten laufen lassen . .
4.8.2 Ausschalten des Rechners konfigurieren . . . . . . . . . . . .
24
24
25
31
31
32
32
34
35
36
36
37
37
37
38
38
38
39
5 Backup von Dateien
5.1 Sicherung über grafische Oberfläche (dsm) . . . . . . . . . . . . . . .
5.1.1 Manuelle Auswahl zu sichernder Dateien . . . . . . . . . . .
5.1.2 Inkrementelle Sicherung der in dsm.sys/dsm.opt angegebenen
Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.3 Statusbericht . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Sicherung über die Kommandozeile (dsmc) . . . . . . . . . . . . . .
5.3 Automatisierte Sicherung über den Scheduler . . . . . . . . . . . . .
5.3.1 Start des Backups . . . . . . . . . . . . . . . . . . . . . . . .
5.3.2 Begin der Sicherung . . . . . . . . . . . . . . . . . . . . . .
5.3.3 Meldungen während der Sicherung . . . . . . . . . . . . . .
5.3.4 Backupbericht am Ende der Sicherung . . . . . . . . . . . . .
41
41
42
6 Restore von Dateien
6.1 Fall des Datenverlustes . . . . . . . . . . . . . . . . .
6.2 Restore großer Filesysteme (Disaster-Restore) . . . . .
6.2.1 Alternativen / Ergänzungen für den Disasterfall
6.3 Vorbereitungen . . . . . . . . . . . . . . . . . . . . .
6.4 Restore über die grafische Oberfläche (dsm) . . . . . .
6.4.1 Aktive / inaktive Sicht der Dateien . . . . . . .
6.5 Auswahl der Zielverzeichnisses . . . . . . . . . . . . .
6.6 Restorebericht . . . . . . . . . . . . . . . . . . . . . .
6.7 Restore über die Kommandozeile (dsmc) . . . . . . . .
48
48
48
49
49
50
51
52
54
54
4.3
4.4
4.5
4.6
4.7
4.8
Rechen- und Kommunikationszentrum
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
39
40
40
42
43
43
44
44
45
45
45
Einführung in TSM
3
INHALTSVERZEICHNIS
6.8
Point-in-time Restore . . . . . . . . . . . . . . . . . . . . . . . . . .
6.8.1 grafische Oberfläche . . . . . . . . . . . . . . . . . . . . . .
6.8.2 Kommandozeile . . . . . . . . . . . . . . . . . . . . . . . .
55
56
57
7 Optimierungsmöglichkeiten
7.1 Parallele Backup Sessions . . . . . . . . . . . . . . . . . . . . . . .
7.2 Parallele Restore Sessions . . . . . . . . . . . . . . . . . . . . . . .
7.3 Journal Based Backup . . . . . . . . . . . . . . . . . . . . . . . . . .
58
58
59
60
8 Aufgaben bei der Betreuung des Backupclients
8.1 Administrative Aufgaben . . . . . . . . . . . . . . . . . . . . . . . .
8.2 Sonstige Aufgaben . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3 Filespaces aus dem Backup herausnehmen . . . . . . . . . . . . . . .
67
67
67
68
9 Sicherung von Datenbanken
9.1 Tivoli Data Protection Agenten . . . . . . . . . . . . . . . . . . . . .
9.2 Sicherung von dumps . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2.1 Beispiel: mysql-Datenbank und mysqlhotcopy . . . . . . . .
69
69
69
70
A Beispiel dsm.sys für Unix-Systeme
72
B Beispiel dsm.opt für Windows-Systeme
74
3
Einführung in TSM
Kapitel 1
Überblick über die zentrale
Datensicherung an der RWTH
Aachen
1.1 Ansprechpartner und nü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
Daniel Stanek
malcherek@rz.rwth-aachen.de
stanek@rz.rwth-aachen.de
8028715
8029425
Bitte benutzen Sie bei Fragen oder Problemen zum Backup- oder Archivdienst den
Support-Server des Rechen- und Kommunikationszentrums:
backup@rz.rwth-aachen.de
bzw.
archive@rz.rwth-aachen.de
Generelle Informationen zum Backup- und Archivdienst erhalten Sie auf den Webseiten des Rechen- und Kommunikationzentrums unter:
http://www.rz.rwth-aachen.de/computing/datendienste/backup/index.php
Die Backup-Client-Software halten wir für alle gängigen Betriebssysteme für Sie bereit. Sie können die Software für die verschiedenen Betriebssysteme von folgender
Seite beziehen:
4
5
1.2. ANMELDUNG BACKUP-/ ARCHIVDIENST
http://www.rz.rwth-aachen.de/computing/datendienste/backup/installation.php
Der z.Z. aktuelle Client liegt in der Version 5.2 für die Betriebssysteme Windows
ME/NT/2000/2003, Linux, AIX, Appel Macintosh, Novell Netware, Solaris, Irix, HPUX und True64Unix vor.
Offizielle Dokumentation zu den verschiedenen aktuellen Clients können Sie von unserem Support-Server unter der folgenden Adresse sowohl im pdf- als auch im HTMLFormat beziehen:
http://support.rz.rwth-aachen.de/Manuals/TSM52/infocenter.html
1.2 Anmeldung Backup-/ Archivdienst
Wenn Sie den Backupdienst nutzen möchten, beantragen Sie bitte per email an
backup@rwth-aachen.de
einen Knotennamen für das zu sichernde System.
Für die Nutzung des Archivdienstes beantragen Sie bitte einen Account mit dem Antragsformular, das Sie unter folgender Adresse finden:
http://www.rz.rwth-aachen.de/computing/antraege/index.php
Bitte beachten Sie, dass der Archivaccount ein Jahr gültig ist und rechtzeitig verlä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 durchzuführen, nicht entsprochen werden kann:
Der Backup-Dienst muss seitens der Einrichtung von zwei verlä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 tägliche (genauer: nächtliche)
Backup auch durchgeführt werden kann.
Die Netzanbindung muss dem Sicherungsvolumen angemessen sein, so dass einerseits die täglichen Sicherungen im Laufe einer Nacht erfolgen können, aber
auch z. B. ein Restore des gesamten Servers in realistischen Zeiträumen möglich
ist. Die Tabelle auf Seite 15 kann hierbei als erste Orientierungshilfe gesehen
werden.
5
Einführung in TSM
6
1.4. HARD- UND SOFTWAREAUSSTATTUNG
1.4 Hard- und Softwareausstattung
1.4.1 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 genügend
Netzwerkbandbreite zur Verfügung, um auch grosse Datenmengen problemlos über das
Netzwerk entgegennehmen zu können.
Als Plattencache dienen 3 FAStT 900 Plattensysteme von IBM mit einer Gesamtkapazität von 30 TB.
Als Robotorsystem kommt eine IBM 3494 Library mit ca. 3000 Bandplätzen in 10
Schränken zum Einsatz. Diese bietet bei der aktuellen Bestückung mit ca. 1800 Bändern
eine Kapazität von 0,5 PB.
In der Libraray sind 16 IBM Jaguar 3592 Laufwerke (FC attached) installiert.
Der Backupserver läuft unter dem Betriebsystem AIX 5.2. Momentan werden 12 logische TSM-Server (Version 5.2.1.3) eingesetzt. 10 dieser logischen Server dienen den
einzelnen Fachbereichen der RWTH als Backupserver, einer wird als Backupserver für
das Rechen- und Kommunikationszentrum eingesetzt und ein weiter Server wird zur
Verwaltung der Bandlaufwerke und Tapes verwendet.
1.4.2 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 Kapazität
von 1 TB, sodass ein Gesamtcache von 2 TB zu Verfügung steht. TSM-Datenbank und
TSM-Recovery Log sind jeweils auf eigene RAID-Systeme ausgelagert.
Als Robotorsystem kommt eine IBM 3494 Libraray mit 2832 Bandplätzen in 8 Schränken
zum Einsatz. Diese bietet eine Gesamtkapazität von 78 TB.
In der Library sind 10 IBM Magstar 3590 Laufwerke (SCSI attached) installiert, die
zum Schreiben und Lesen der Bänder verwendet werden.
Der Archivserver läuft unter dem Betriebsystem AIX 5. Zur Zeit wird ein logischer
TSM Server (Version 4.2.1.15) als Archivserver betrieben.
6
Einführung in TSM
7
1.5. 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 täglich bis zu 1,8 TB Daten entgegen.
Im Durchschnitt werden pro Tag 10 GB restauriert.
7
Einführung in TSM
Kapitel 2
Einführung in TSM
2.1 Arbeitsweise von TSM
Der TSM-Server arbeitet mit Hilfe einer Datenbank in der sämtliche Informationen
über gesicherte Objekte gespeichert werden. Im Gegensatz zu den meisten anderen
verfü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 Änderungen im Filesystem übermittelt. Im Gegensatz zu herkömmlichen inkrementellen Sicherungen werden auch
Informationen über gelöschte Dateien zum TSM-Server gesendet. Dies ist aufgrund
der Arbeitsweise auf Dateiebene möglich. Vorteile sind hierbei in der geringeren zu
übertragenden Datenmenge aufgrund der inkrementellen Sicherung zu sehen, die bei
zyklisch durchgeführten Fullbackups, um ein erhebliches größer ist und zudem in der
Tatsache, dass der Speicherplatz für gelöschte Dateien freigegeben werden kann. Aufgrund der Tatsache, dass alle Informationen über die Dateien im Filesystem in der
TSM-Datenbank gespeichert sind, ist es möglich, beliebige Zustände des Filesystems
zu restaurieren.
TSM arbeitet mit Softwaremodulen die die Kommunikation zwischen Client und Server ermöglicht. Die Kommunikation läuft dabei über das TCP/IP Protokoll ab.
2.2 Versionierung und Aufbewahrungsdauer von Dateien
TSM bietet die Mö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
9
2.2. VERSIONIERUNG UND AUFBEWAHRUNGSDAUER VON DATEIEN
fest, wie viele Versionen einer Datei für welche Dauer auf dem TSM-Server gehalten
werden. Wird die Datei vom Dateisystem gelö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 gelöschten Datei für
welche Dauer gehalten werden und wie lange die aktuellste inaktive Version dieser
Datei gehalten wird, bevor endgü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 gelöschten Datei
Dauer (Tage), für die inaktive Versionen
einer Datei gehalten werden
Dauer (Tage), für die die letze Version
einer gelöschten Datei gehalten wird
Die aktuellen Regeln, nach denen die Daten gesichert werden, können auf dem Client mit dem Punkt View Policy im Menü Utilities abgefragt werden.
Es ist auch möglich, Dateien nach verschiedenen Regeln zu sichern (wenn mehrere
Sets vom Server aus zur Verfügung gestellt werden). Mehr dazu siehe ”Sicherung über
verschiedene Managmentklassen” auf Seite 31.
2.2.1 Beispiel
Folgendes Beispiel hilft, die Funktionsweise der Parameter zu verstehen:
Versions Data exists
Versions Data deletet
Retain extra Versions
Retain only Version
3
2
7
10
9
Einführung in TSM
10
2.2. VERSIONIERUNG UND AUFBEWAHRUNGSDAUER VON DATEIEN
Tag
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
1
o
o
A
o
x
2
o
o
o
A
Version
3 4
o
o
o
o
o
B
o
o
C
5
o
A
6
o
o
x
x
x
x
x
x
x
x
x
x
D
aktive Version
inaktive Version
letzte inaktive Version
einer gelöschten Datei
Am 3., 6., 11., 13. und 14. Tag wurde die Datei geändert.
Am 16. Tag wurde die Datei gelöscht.
A
B
C
D
Version wird gelöscht, weil sie älter als 7 Tage ist (Retain Extra Versions)
Version wird gelöscht, weil nur 3 Versionen einer Datei gehalten werden
(Versions Data Exists)
eine Version wird gelöscht, weil nur 2 Versionen einer gelöschten Datei
aufgehoben werden (Versions Data Deleted)
endgültige Löschung der letzen Version nach 10 Tagen (Retain Only Version)
10
Einführung in TSM
11
2.3. SICHERUNGSMÖGLICHKEITEN
Anmerkung: Die in diesem Beispiel verwendeten Werte sind nicht repräsentativ für
die Einstellungen auf dem TSM-Server. Die Einstellungen wurden speziell für dieses
Beispiel ausgewählt.
Auch nur kleine Änderungen an diesen Werten können die Auslastung der Library in
erheblichem Maße beeinflußen. In Zukunft wird beabsichtigt, mehrere Sets dieser Einstellungen für verschiedenen ”Arten” von Dateien zur Verfügung zu stellen. Sie sollten
dann möglichst Daten, die beispielsweise reproduzierbar sind, über ein anderes Set sichern (welches weniger Versionen und kürzere Haltezeiten vorgibt) als beispielweise
nicht reprodizierbare Benutzerdaten. Mehr dazu siehe ”Sicherung über verschiedene
Managmentklassen” auf Seite 31.
2.3 Sicherungsmöglichkeiten
TSM bietet die Möglichkeit sowohl von Hand initiierte Sicherungen als auch automatisierte Sicherungen durchzuführen.
Um eine regelmäßige Durchführung der Sicherung zu gewährleisten, empfiehlt es sich,
die automatisierte Sicherung durchzuführen. Nä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 lauffähige
automatisierte Sicherung nicht dauerhaft korrekt laufen muss. Durch eine Fülle von
verschiedensten Ursachen, kann es zu Problemen in der automatisierten Sicherung
kommen. Deswegen ist es unerlässlich, regelmässige Kontrollen und Auswertungen
der Logfiles durchzuführen, um eine korrekte Datensicherung zu garantieren.
2.4 Stärken / Schwächen von TSM
Wie jedes Softwareprodukt besitzt auch der Tivoli Storage Manager Stärken und Schwächen.
Diese (möglicherweise auch subjektiven) Eigenschaften sollen kurz aufgezeigt werden.
Stärken:
Backup auf Dateiebene; es entfallen Zyklen von Voll- und inkrementellen Sicherungen, Versionierung von Dateien
Unterstützung von verschiedensten Betriebssystemen und Filesystemen
viele Konfigurationsmöglichkeiten (auch als Schwäche zu sehen)
schnell und zuverlässig (bei vorausgesetzer guter und schneller Netzinfrastruktur)
11
Einführung in TSM
12
2.4. STÄRKEN / SCHWÄCHEN VON TSM
Schwächen:
Problem beim Restore großer Filesysteme (teilweise behebbar über Backupsets)
Journal Based Backup nur für Windows-Systeme
”Open File Support” nur für Windows-Systeme
”Disaster Recovery”
12
Einführung in TSM
Kapitel 3
Voraussetzung zur Nutzung des
Backupdienstes
3.1 Randbedingungen
Generell sollte wenn mö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 durchgeführt.
Voraussetzung dafür ist, dass der Client in dieser Zeit eingeschaltet und über das Netzwerk erreichbar ist.
3.2 Backup Client
Um problemlose Sicherungen durchführen zu können, sollte der Backup-Client sowohl
einige Anforderungen an die Hardware als auch an das Betriebsystem erfüllen. Generell sind diese durch die Anforderungen der Backup-Client-Software gegeben. Das
System sollte jedoch nicht älter als zwei Jahre sein und genügend CPU Leistung und
Arbeitsspeicher zur Verfügung stellen. Das Betriebsystem sollte aktuell sein und durch
Updates auf einem aktuellen Stand gehalten werden. Unterstü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/x86 2.4 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 für pSeries 2.4 Kernel (SuSE 8.0)
13
14
3.3. NETZWERK
Linux für iSeries 2.4 Kernel (SuSE 8.0)
Linux IA64 2.4 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/400 5.1 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 für ein problemloses Backup, ist ein korrekt konfiguriertes Netzwerk. Häufig fallen Netzprobleme im ”normalen” Betrieb nicht auf. Deshalb
sollte vor der Inbetriebnahme des Backupdienstes das Netzwerk überprüft werden. Eine ausführliche Anleitung an dieser Stelle würde allerdings den Rahmen sprengen.
Deshalb werden einige hä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 Fülle weiterer Fehlerquellen für ein ”langsames” Netzwerk denkbar.
Dies müsste im Einzelfall genauer untersucht werden.
Bei Fragen oder Problemen im Bereich ”Netzwerk” können Sie sich gerne an die Netzwerkabteilung des Rechen- und Kommunikationzentrums wenden:
14
Einführung in TSM
15
3.4. OFFENE DATEIEN
noc@rz.rwth-aachen.de
Zum Messen von Durchsatzraten in einem Netzwerk gibt es für fast alle Betriebssysteme frei verfügbare Benchmark-Programme. Diese können hilfreich sein um Netzwerkprobleme zu erkennen. Frei verfügbare Tools sind z.B.:
netio
iperf
ftp
...
Weiterhin ist durch das Netzwerk auch die Menge der zu sichernden Daten beschränkt.
Um in dem vorgegebenen Zeitfenster von max. 10 Stunden eine Sicherung durchführen
zu können, können Sie sich an folgenden Datenmengen grob orientieren:
10 Mbit
100 Mbit
1000 MBit
10 GB
100 GB
1 TB
Diese Angaben sind nur Richtwerte und sind stark abhänig von der Leistung des Clients und von der Leistung des Netzwerkes.
Sollte bei einem entsprechenden Netzwerk die Datenmenge deutlich überschritten werden, ist entweder mehr Netzwerkperformance zur Verfügung zu stellen oder auf eine
geeignete Auswahl der zu sichernden Daten zu achten.
3.4 Offene Dateien
Ein Problem bei der Duchfü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 Möglichkeit besteht darin, kritische Dateien vom Backup auszuschliessen. Beispielsweise wäre dann neben der automatisierten Sicherung, eine händische
Sicherung dieser kritischen Dateien in gewissen Zeitabständen denkbar.
Für Windows 2000 und Windows XP besteht, mit dem ab Client 5.2 verfügbaren Feature ”Open File Support (OFS)”, die Möglichkeit, offene Dateien zu sichern. ”Open
File Support” wird auf Seite 38 ausführlich dargestellt.
15
Einführung in TSM
16
3.5. FIREWALL / PAKETFILTER
3.5 Firewall / Paketfilter
Sollte eine Firewall oder ein Paketfilter betrieben werden, so ist darauf zu achten, dass
der entsprechende Port 1500 - 1511 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 möglichst verzichtet werden. Dies hat zwei Gründe:
1. Sollte das Netzlaufwerk oder das gemountete Filesystem nicht erreichbar sein
(Rechner ausgeschaltet, rpc-Dienste nicht verfügbar), so kann dies im Extremfall
dazu führen, dass das gesamte Backup fehlerhaft abbricht.
2. Das für Windows-Systeme verfügbare ”Journal Based Backup” kann nur für lokale Partionen betrieben werden
3. Diese Sicherungsmethode ist von IBM nicht supported.
Deshalb sollte für jedes zu sichernde System ein eigener Knoten beantragt und eingerichtet werden.
3.8 Ansprechpartner
Bei der Einrichtung eines Knotens für ein Institut müssen zwei feste Personen angegeben werden, die für die Betreuung des Backup-Clients verantwortlich sind und
feste Ansprechpartner für das Rechen- und Kommunikationszentrum darstellen. Bei
Einrichtung weiterer Knoten für das selbe Institut sind ebenfalls diese Personen die
jeweiligen Ansprechpartner. Dadurch ist es möglich, gezielten Support zu leisten und
auch eine bestmögliche Betreuung des Backups für das Institut zu liefern.
Diese Ansprechpartner sollten möglichst am Institut festangestellt sein. Somit entfällt
der Aufwand bei oft wechselnden Ansprechpartnern Support für gleiche oder wiederauftretende Problemfälle zu leisten. Zudem ist es so möglich auftretende Probleme
16
Einführung in TSM
17
3.8. ANSPRECHPARTNER
schneller zu lösen.
Bei einem Wechsel der Ansprechpartner oder einem Wechsel der Daten wie Telefonnummer oder email-Adresse sollte eine entsprechende Benachrichtigung erfolgen.
17
Einführung in TSM
Kapitel 4
Installation und Konfiguration
des TSM-Clients
4.1 Installation der Software
Zunächst muss die aktuelle Version der Clientsoftware (Version 5.2) heruntergeladen
werden. Die Backup-Client-Software halten wir für Sie für alle gängigen Betriebssysteme bereit. Sie kann von folgender Seite bezogen werden:
http://www.rz.rwth-aachen.de/computing/datendienste/backup/installation.php
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 ähnliche Programmteile werden nicht benötigt und
18
19
4.1. INSTALLATION DER SOFTWARE
brauchen deshalb auch nicht installiert zu werden.
Ausführliche Informationen zur Installation des jeweiligen Clients können Sie der READMEDatei im entsprechenden Download-Verzeichnis des Clients entnehmen.
Achtung: Einige Clients werden als tar-Paket zur Verfügung gestellt. Dieses muss vor
der Installation erst entpackt werden. Dazu muss folgendes Kommando abgesetzt werden:
tar -xvf <filename.tar>
4.1.1 Installation unter Windows 2000
Im folgenden wird gezeigt, wie eine Installation unter Windows 2000 abläuft. Die
menügeführte Installation ist mit wenigen Mausklicken abgeschlossen. Anzuwählendes ist jeweils markiert.
Nach Angabe in welches Verzeichnis temporär die Installationsdateien kopiert werden,
mit Next > bestätigen.
19
Einführung in TSM
20
Nach Auswahl der Sprache mit OK
Weiter >
bestätigen.
drü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.
20
Einführung in TSM
21
Nach Auswahl der Installationsmethode mit Weiter >
fortfahren.
Durch klicken auf Installieren > werden alle benötigen Dateien auf das System übertragen.
21
Einführung in TSM
22
4.2. 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.
Zunä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 nächsten Abschnitt beschrieben.
4.1.2 Hinweise zur Installation auf Linux-Systemen
Zur Installation des TSM-Clients auf SuSE und Fedora Systemen wird die Bibliothek libstdc++ benötigt. Diese Bibliothek ist auf SuSE Systemen ( 7.3),
Redhat Systemen (Version 9) und Fedora Systemen (Core 1 und Core 2) standardmässig nicht installiert. Um den Client installieren zu kö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 gelöscht werden. Die Links kö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 zunächst entsprechend angepasst werden, bevor der BackupRechen- und Kommunikationszentrum
22
Einführung in TSM
23
client nach der Installation zum ersten Mal aufgerufen wird. Folgende Tabelle zeigt,
wo die Konfigurationsdateien jeweils zu finden sind, falls der Standardinstallationspfad nicht verä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
4.2.1 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 über den Fachbereich. Folgende Tabelle zeigt, welcher Fachbereich welchem TSM-Server (und Port) zugeordnet
ist:
Fachbereich
1
2
3
4
5
6
7
8
10
Sonstige
TSM-Server
backup03.rz.rwth-aachen.de
Port
1503
1504
1505
1506
1507
1508
1509
1510
1511
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.
4.2.2 Einstellen des TSM-Servers und Ports
Bei den Einträgen SERVERNAME, TCPSERVERADRESS und TCPPORT sind die
X-Zeichen entsprechen der obigen Tabelle zu ersetzen.
SERVERNAME
TCPSERVERADRESS
TCPPORT
backupXX.rz.rwth-aachen.de
15XX
23
Einführung in TSM
24
4.2.3 Generelle Einstellungen
Folgende Einstellungen müssen unverändert bleiben:
COMMMETHOD
PASSWORDACCESS
SCHEDMODE
TXNBYTELIMIT
tcpip
generate
polling
25600
4.2.4 Variable Einstellungen
Der nä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 nächsten beiden Zeilen legen fest, welche Dateien als Schedulerlogfile und Errorlogfile verwendet werden. Es sollten geeignete Verzeichnisse und Dateinamen gewählt
werden. Die ersten beiden Einträge sind auf einem Windows-System, die nächsten beiden Einträge auf einem Unix-System gültig.
SCHEDLOGNAME
ERRORLOGNAME
c:\logfiles\dsmsched.log
c:\logfiles\dsmerror.log
SCHEDLOGNAME
ERRORLOGNAME
/var/log/dsmsched.log
/var/log/dsmerror.log
4.2.5 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 mü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 nä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 VIRTUALMOINTPOINTStatement angegeben werden. Folgende Beispiele sollen die Anwendung von DOMAIN und
VIRTUALMOUNTPOINT verdeutlichen.
24
Einführung in TSM
25
Windows-Beispiel
Mit den folgenden Einträ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 Einträ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 überpü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 löschen.
Anmerkung: Im wesentlichen spielen die DOMAIN Einträge bei der automatisierten
Sicherung eine Rolle. Manuelle Sicherungen wären theoretisch auch ohne diese Einträge möglich. Trotzdem ist es empfehlenswert, diese Einträge direkt bei der Erstellung
der dsm.sys/dsm.opt zu berücksichtigen.
4.2.6 Auswahl zu sichernder Dateien - Include-/Exclude Listen
Da es in den meisten Fä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
25
Einführung in TSM
26
Diesen Statements muss eine Datei- oder Verzeichnissangabe folgen, wobei auch ”Wildcards” verwendet werden können. Einige zur Verfügung stehenden ”Wildcards” sind
in der folgenden Tabelle ausgeführt:
?
...
steht für ein beliebiges Zeichen (ausser Verzeichnisstrenner)
steht für eine belibige Zeichenkette
steht fü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 überprü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 darüber ob die Datei gesichert wird oder nicht. Ausnahme bildet das EXCLUDE.DIR-Statement. Dieses wird
generell zuerst auf Übereinstimmung mit der aktuellen Datei überprüft, egal an welcher
Position es in der Include-/Exclude-Liste steht. Wird kein Statement für eine Datei gefunden, so wird diese implizit ”included”.
Beispiel für Unix-Systeme
Das folgende Beispiel soll die Verwendung von Include-/Exclude-Statements verdeutlichen. Folgende Statements werden definiert (entsprechende DOMAIN-Einträge seien
vorhanden):
EXCLUDE.DIR
EXCLUDE
EXCLUDE
EXCLUDE
EXCLUDE
INCLUDE
INCLUDE
/.../cache
/usr/software/.../*
/.../core
/home/ae106st/nobackup/.../*.test
/home/ae106st/a.out
/usr/software/netio/.../*
/home/ae106st/nobackup/ausnahme/3.test
Folgende Dateien werden betrachtet:
26
Einführung in TSM
*
*
*
*
*
*
*
Regel
Regel
Regel
Regel
Regel
Regel
Regel
1
2
3
4
5
6
7
27
/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 2 wird implizit eingeschlossen
- da keine Regel definiert -
Überprüfen von Include-/Exclude-Statements
Da sich beim Definieren der Include-/Exclude-Liste schnell Fehler einschleichen können
und wichtige Dateien dadurch fälschlicherweise nicht gesichert werden, empfiehlt es
sich, die definierten Regeln auf Korrektheit zu überprü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).
27
Einführung in TSM
28
Hier muß der Punkt Sichern ausgewählt werden.
Greift eine Exclude-Regel für eine Datei, so wird diese Datei durch ein rotes Symbol
vor dem Dateinamen gekennzeichnet. Trifft für diese Datei ein Include-Statement zu,
28
Einführung in TSM
29
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 Möglichkeit diese Kriterien testweise
auf eine Datei anzuwenden. Dazu müss die oben beschriebene Möglichkeit verwendet
werden.
Empfohlene Include-/Exclude-Statements
Einige Dateien sollten grundsätzlich von der Sicherung ausgeschlossen werden. Im
einzelnen sind dies
verschiedene Systemdateien
diverse Caches - vor allem Browser-Caches
Dateien aus dem Papierkorb (Recycler)
temporä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 BackupServer gewisse Exclude-Listen vorgegeben. Diese Exlude-Statements sind als Ergänzung
zu eigenen definierten Include-Exclude-Listen zu verstehen. Deshalb sollten für das jeweilige System trotzdem speziell angepaßte Include-Exclude-Listen definiert werden.
Zurzeit gibt es für Windows und Unix-Systeme solche Exclude-Listen, die die folgenden Exclude-Statements enthalten:
Windows Exclude-Liste:
29
Einführung in TSM
30
EXCLUDE
EXCLUDE
EXCLUDE
EXCLUDE
EXCLUDE
EXCLUDE
EXCLUDE
EXCLUDE
EXCLUDE
EXCLUDE
EXCLUDE
EXCLUDE
EXCLUDE
EXCLUDE
EXCLUDE
EXCLUDE
EXCLUDE
EXCLUDE
EXCLUDE
EXCLUDE
EXCLUDE
EXCLUDE
EXCLUDE
EXCLUDE
EXCLUDE
EXCLUDE
EXCLUDE
EXCLUDE
EXCLUDE
’*:\...\NETSCAPE\...\CACHE\*’
’*:\...\Microsoft Internet\cache\...\*’
’*:\...\Microsoft Internet\history\...\*’
’*:\...\Microsoft Internet\verlauf\...\*’
’*:\...\Temporary Internet Files\...\*’
’*:\...\Profiles\...\History\...\*’
’*:\...\Profiles\...\Verlauf\...\*’
’*:\macintosh volume\...\*’
’*:\macintosh volume\...\*.*’
’*:\microsoft uam volume\...\*’
’*:\microsoft uam volume\...\*.*’
’*:\...\EA DATA. SF’
’*:\...\pagefile.sys’
’*:\IBMBIO.COM’
’*:\IBMDOS.COM’
’*:\MSDOS.SYS’
’*:\...\SYSTEM32\CONFIG\...\*’
’*:\...\*.swp’
’*:\...\win386.swp’
’*:\...\*.par’
’*:\...\386spart.par’
’*:\ffastun.*’
’*:\ffastun0.*’
’*:\...\dblspace.*’
’*:\...\drvspace.*’
’*:\Recycler\...\*’
’*:\Recycled\...\*’
’*:\...\dsmerror.log’
’*:\...\dsmsched.log’
UNIX Exclude-Liste:
EXCLUDE.DIR
EXCLUDE
EXCLUDE
EXCLUDE
EXCLUDE
EXCLUDE
’/.../.kde/share/cache/http/.../*’
’/.../.mozilla/.../.../Cache/.../*’
’/.../.netscape/cache/.../*’
’core’
’/.../dsmerror.log’
’/.../dsmsched.log’
Achtung: Da diese Statements bereits definiert sind, dürfen sie nicht noch einmal in
der dsm.sys/dsm.opt definiert werden. Doppelte Definitionen können zu Fehlern
führen und sind deshalb zu vermeiden.
30
Einführung in TSM
31
4.3. PASSWORT
4.2.7 Sichern über verschiedene Managmentklassen
Wie bereits erwä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 Regelsätzen (Managmentklassen) an Dateien über
INCLUDE-Anweisungen. Definiert seien auf dem Server die beiden Managmentklassen STANDARD und DYNAMIC. Die folgenden Statements verdeutlichen wie verschiedenen Haltezeiten für Dateien vereinbart werden:
INCLUDE /work/.../kurzzeitig/.../* DYNAMIC
INCLUDE /home/.../tests/.../*
DYNAMIC
Diese Statements bewirken, dass alle Dateien, auf die die INCLUDE-Muster zutreffen,
ü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, können auf dem Client mit dem Punkt View Policy im Menü 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 verschlü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 möglich. Mittels der Option
PASSWORDDIR /rwth/stage/tsm_pwd
31
Einführung in TSM
32
4.4. INSTALLATION DES SCHEDULERS
ist es möglich ein Verzeichnis anzugeben, in dem das Passwort in verschlüsselter Form
in einer Datei (TSM.pwd) abgespeichert wird.
Es ist empfehlenswert, sich das Passwort in periodischen Abständen per Mail zuschicken zu lassen. Unter Windows kann dies durch ein Skript erreicht werden, das
zunä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
Änderung (nur bei gesetzter Option PASSWORACCESS generate) per Mail an den
Empfänger geschickt wird. Ein Eintrag könnte folgendermassen aussehen:
MAILPROG /usr/ucb/Mail -s "Knoten GUESTC2" stanek@rz.rwth-aachen.de
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 verfügbar ist.
Sollten trotzdem Probleme mit dem Passwort entstehen, ist es möglich, dies auf dem
Server auf das Initialpasswort (bei der Anmeldung erhalten) zurückzusetzen.
4.4 Installation des Schedulers
Um eine automatisierte Sicherung durchzuführen, muss der ”Scheduler” installiert bzw.
gestartet werden. Es werden die nötigen Schritte für Windows- und Unix-Systeme gezeigt.
4.4.1 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:
32
Einführung in TSM
33
Unter den Diensten sollte folgender Eintrag zu sehen sein:
Standardmäß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.
33
Einführung in TSM
34
4.4.2 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 unabhängig von der Shell gestartet werden:
nohup dsmc sched 1>/dev/null 2>&1 &
Es ist dringend erforderlich, den Scheduler über ein Startup-Skript zu starten, damit
dieser auch nach einem Reboot der Maschine aktiv ist. Folgendes Init-Skript (für RedHat Linux) kann dazu verwendet werden. Diese sollte in /etc/rc.d/init.d/ liegen und entsprechende Links fü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
}
34
Einführung in TSM
35
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 rootRechten gestartet wird, um Zugriff auf alle zu sichernden Dateien zu haben.
Um zu überprüfen, ob der Scheduler-Prozess läuft, kann das folgende Kommando verwendet werden:
ps -ef | grep -v grep | grep dsmc
Das Kommando liefert als Ausgabe den Scheduler-Prozess. Die Ausgabe enthält neben
einigen Prozessinformationen das zugrundeliegende Kommando dsmc sched.
4.4.3 Aufgaben des Administrators
Der Client ist jetzt konfiguriert, um tägliche, automatisierte Backups durchzuführen.
Nach Einrichtung des Schedulers sollte regelmäßig überprüft werden, ob der Scheduler noch korrekt läuft, weiterhin sollten die beiden Logfiles dsmsched.log und
dsmerror.log regelmäßig auf ein korrekt durchgeführtes Backup hin überprüft
werden. In dsmsched.log ist nach jedem Backup ein Backupbericht vorhanden.
Weisen die Dateien keine aktuellen Einträge auf, so ist davon auszugehen das der
Scheduler nicht mehr korrekt läuft. Ein Neustart behebt in der Regel das Problem.
Sind andere Fehlermeldungen vorhanden, müssen die entsprechenden Probleme behoben werden, um ein korrektes Backup zu garantieren.
Beim ersten Start des Schedulers muß eine Information über das nächste auszuführende Backup in der dsmsched.log vorhanden sein. Sollte dies nicht der Fall sein, gab
es ein Problem beim Starten des Schedules.
Sollten Änderungen an der dsm.sys/dsm.opt vorgenommen werden, muss der
Scheduler neu gestartet werden, damit die Änderungen wirksam werden.
35
Einführung in TSM
36
4.5. WEITERE PARAMETER FÜR DSM.SYS/DSM.OPT
Eine häufige Ursache fü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 15
4.5 Weitere Parameter für dsm.sys/dsm.opt
Es gibt eine Fülle weiterer Parameter die in der dsm.sys/dsm.opt angegeben werden kö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 enthält
Verwendung eines speicherschonenden
Backupalgorithmus
Systemkommando, das vor der Ausführung
des Schedules abgesetzt wird
Systemkommando, das nach der Ausführung
des Scheudles abgesetzt wird
Anzahl der Tage, die Einträge im
Schedulerlogfile gehalten werden
Anzahl der Tage, die Einträge im
Errorlogfile gehalten werden
Datumsformat definieren
Zeitformat definieren
Zahlenformat definieren
Anzahl der Clientsession definieren
Rückkehr zum Hauptfenster oder zum
Backup/Restore-Fenster festlegen
Alle weiteren Optionen können der offiziellen Dokumentation fü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 nützliche
Links” auf Seite 4
4.5.1 Datums-, Zeit- und Zahlenformat
Bei den Optionen DATEFORMAT, TIMEFORMAT, NUMBERFORMAT muss eine Zahl
als Parameter angegeben werden, die das zu verwendende Format spezifiziert.
Die für Deutschland üblichen Formate können mit folgenden Angaben gewählt werden:
36
Einführung in TSM
37
4.6. UNICODE
DATEFORMAT
4
TIMEFORMAT
1
NUMBERFORMAT 4
Dadurch werden Fomate der folgenden Form verwendet:
Datum
20.02.2003
Zeit
23:48
Zahl
1 000.00
4.6 Unicode
Bei der Sicherung von Dateien, die Umlaute oder Sonderzeichen im Dateinamen enthalten, kann es zu Problemen kommen, so dass diese Dateien nicht gesichert werden.
4.6.1 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 durchgeführt haben,
kann eine Umwandlung, nach Update auf den aktuellen Client, erzwungen werden.
Für alle Windows Systeme ist diese Umwandlung bereits eingerichtet, so dass nach
einem Clientupdate eine Umwandlung ins Unicode-Format durchgeführt wird. Dabei
werden die alten Filespaces auf dem TSM-Server umbenannt und ein neues Fullbackup
im Unicode-Format durchgeführt.
Sollte eine Unicodeumwandlung noch nicht stattgefunden haben, ist es empfehlenswert Kontakt mit dem Rechen- und Kommunikationszentrum aufzunehmen und diese
Umwandlung durchzuführen.
4.6.2 Unix
Um unter Unix-Systemen Dateien sichern zu können, die Umlaute oder Sonderzeichen
im Dateinamen enthalten, muss die Umgebungsvariable LANG auf en_US gesetzt sein.
Ein Aufruf des Kommandos locale gibt Auskunft darü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
37
Einführung in TSM
38
4.7. OPEN FILE SUPPORT (OFS)
Achtung: Die Variable wird nicht permanent systemweit gesetzt. Entweder sollte sie
vor dem Aufruf des Schedulers oder in einem geeigneten Skript gesetzt werden.
4.6.3 Samba
Bei der Verwendung von Samba muss die korrekte Codepage (850) verwendet werden, damit Dateien mit Umlauten oder Sonderzeichen im Dateinamen gesichert werden
können. Folgende Einträge müssen dazu in der Samba-Konfigurationsdatei (smb.conf)
eingetragen werden:
character set = iso8859-1
client code page = 850
valid chars = \344:\304 /366:\326 \374:\334 \337
Ab Samba 3 müssen folgende Einträge im globalen Abschnitt der smb.conf verwendet werden:
display charset = ISO8859-1
unix charset = ISO8859-1
dos charset = CP850
4.7 Open File Support (OFS)
”Open File Support (OFS)” ist für Windows 2000 und Windows XP Systeme ab Clientversion 5.2 verfügbar und ermöglicht eine Sicherung von offenen, bzw. gesperrten Dateien. Dabei wird eine Schnittstelle des Betriebssystems genutzt, die vor dem Backupvorgang einen Online-Snapshot von geöffneten und gesperrten Dateien durchführt.
Dieser Snapshot kann dann problemlos gesichert werden.
Um OFS nutzen zu können müssen folgende Voraussetzungen erfüllt sein:
auf dem zu sichernden System müssen mindestens zwei Partionen vorhanden
sein
Betriebssystem Windows 2000 oder Windows XP
TSM Client Version 5.2.x
die Konfiguration des Clients muss abgeschlossen sein
4.7.1 Installation des LVSA mit ”Open File Support”
Um den ”Open File Support” zu aktivieren, muss zunächst der ”Logical Volume Snapshot Agent” (für ”Open File Support” installiert werden). Folgende Schritte sind dazu
notwendig:
1. Starten des TSM-Client
2. über den Menüpunkt Utilities den Setup-Wizard starten
38
Einführung in TSM
39
4.8. AUTOMATISCHES AUSSCHALTEN EINES RECHNERS NACH EINEM
AUTOMATISIERTEN BACKUP (WINDOWS)
3. das Modul ”LVSA für Open File Support” installieren
4. nach der Installation ist ein Reboot des Systems notwendig
4.7.2 Konfiguration
Die Konfiguration von OFS wird über die zentrale Konfigurationsdatei dsm.opt durchgeführt. Hierzu muss für jede mittels DOMAIN eingetragene Partition ein entsprechendes INCLUDE.FS-Statement gesetzt werden, welches OFS für die jeweilige Partition
aktiviert, bzw. deaktiviert und gleichzeitig festlegt, wo der Online-Snapshot abgelegt
wird.
Das INCLUDE.FS-Statement unterliegt dabei folgender Syntax:
INCLUDE.FS <dom> FILELEVELTYPE:<SNAPSHOT|DYNAMIC>
SNAPSHOTCACHELOCATION=<directory>
<dom>
: Auswahl der zu konfigurierenden Partition
FILELEVELTYPE: SNAPSHOT aktiviert OFS, DYNAMIC deaktiviert OFS
<directory> : gibt an, wohin der Online-Snapshot gespeichert wird
ACHTUNG: darf nicht auf <dom> liegen
Beispiel
Auf dem zu sichernden System gibt es vier Laufwerke (Partitionen) C:, D:, E:, F:. Alle
Partionen sollen gesichert werden, wobei für D: und E: OFS aktiviert werden soll, C:
und F: ohne OFS gesichert werden sollen. Der Snapshot von Laufwerk D: soll auf
C: und der Snapshot von Laufwerk E: auf F: abgelegt werden. Dazu sind folgende
Einträge in der dsm.opt notwendig:
...
DOMAIN
DOMAIN
DOMAIN
DOMAIN
c:
d:
e:
f:
INCLUDE.FS
INCLUDE.FS
INCLUDE.FS
INCLUDE.FS
...
c:
d:
e:
f:
FILELEVELTYPE=DYNAMIC
FILELEVELTYPE=SNAPSHOT SNAPSHOTCACHELOCATION=c:\
FILELEVELTYPE=SNAPSHOT SNAPSHOTCACHELOCATION=f:\
FILELEVELTYPE=DYNAMIC
4.8 Automatisches Ausschalten eines Rechners nach einem automatisierten Backup (Windows)
Aus verschiedenen Gründen (z. B. Energiesparmassnahmen) kann es in Einzelfällen
sinnvoll sein, den Rechner nach einem erfolgreich abgeschlossenem, automatisiertem
39
Einführung in TSM
40
4.8. AUTOMATISCHES AUSSCHALTEN EINES RECHNERS NACH EINEM
AUTOMATISIERTEN BACKUP (WINDOWS)
Backup auszuschalten.
Dazu muss zum Einen der Scheduler-Dienst mit Administrator-Rechten laufen und
zum Anderen nach dem Backup ein Kommando abgesetzt werden, dass den Rechner
kontrolliert ausschaltet.
4.8.1 Scheduler-Dienst mit Administrator-Rechten laufen lassen
Standardmässig läuft der Scheduler-Dienst unter dem Benutzerkonto ”Lokales System”. Unter Systemsteuerung->Verwaltung->Dienste den Scheduler Dienst
(im Regelfall ”TSM Client Scheduler”) mit der rechten Maustaste anklicken und die Eigenschaften auswählen. Den Reiter ”Anmelden” auswählen und im oberen Bereich von
”Lokales Systemkonto” auf ”Dieses Konto” wechseln. Unter ”Dieses Konto” dann den
Administratornamen und -passwort eintragen. Anschliessend den Scheduler-Dienst neu
starten.
4.8.2 Ausschalten des Rechners konfigurieren
Ein kontrolliertes Ausschalten des Rechner kann durch das Kommando ”shutdown -s”
erreicht werden (ev. muss dieses Kommdo erst nachinstalliert werden). Diese Kommando muss in eine Datei (z. B. c:\skripte\dsm_shutdown.bat) geschrieben
werden. Das Ausführen des Skriptes (als Administrator) würde den Rechner-Shutdown
bereits initiieren (ohne weitere Optionen, shutdown in 30 sec). Um das Herunterfahren
unmittelbar im Anschluss an ein erfolgreich gelaufenes, automatisiertes Backup durchzuführen, muss in der Konfigurationsdatei dsm.opt eine Option gesetzt werden, die
das zuvor generierte Skript im Anschluss an das Backup ausführt. Dazu muss folgende Zeile in der dsm.opt ergänzt werden (Eintrag zwischen TXNBYTELIMIT und
DOMAIN vornehmen):
POSTSCHEDULECMD
"c:\skripte\dsm_shutdown.bat"
Hinweis: Ein bereits eingeleitetes ”shutdown” kann durch den Administrator durch
Absetzen des Kommandos shutdown -a abgebrochen werden.
40
Einführung in TSM
Kapitel 5
Backup von Dateien
Neben der empfohlenen automatisierten Sicherung durch den Scheduler, die im vorigen Kapitel beschrieben wurde, ist es in Einzelfällen notwendig, z.B. bei der Sicherung
von Laptops, periodische von Hand initiierte Sicherungen durchzuführen und auf die
automatisierte Sicherung zu verzichten. Im folgenden werden zwei Möglichkeiten vorgestellt, händische Sicherungen durchzuführen.
5.1 Sicherung über grafische Oberfläche (dsm)
Nach dem Start des grafischen Client kann eine Sicherung auf zwei unterschiedliche
Weisen durchgeführt werden:
1. manuelle Auswahl zu sichernder Dateien (selective backup)
2. inkrementelle Sicherung der in dsm.sys/dsm.opt angegeben Domains
41
42
5.1. SICHERUNG ÜBER GRAFISCHE OBERFLÄCHE (DSM)
5.1.1 Manuelle Auswahl zu sichernder Dateien
Durch klicken auf Aktionen -> Sichern wird ein neues Fenster geöffnet. Im linken Teil können durch Markieren der grauen Boxen ganze Filesysteme oder einzelne
Verzeichnisse selektiert werden. Im rechten Teil können einzelne Dateien eines Verzeichnisses selektiert werden. Dazu muss zunächst im linken Teil das entsprechende
Verzeichnis durch Klick auf den Namen ausgewählt werden. Die Dateien dieses Verzeichnisses werden dann im rechten Teil angezeigt und können ausgewählt werden.
Durch entsprechende in der dsm.sys/dsm.opt eingetragenede EXCLUDE-Statements,
können Dateien, für die diese Statements zutreffen, nicht selektiert und somit auch
nicht gesichert werden.
Durch Klick auf Sichern wird die Sicherung aller selektierten Dateien durchgeführt.
Der grafische Client bietet eine Fülle weiterer Optionen, auf die hier nicht weiter eingegangen wird. An dieser Stelle sei auf die eingebaute Hilfefunktion und die Dokumentation verwiesen.
5.1.2 Inkrementelle Sicherung der in dsm.sys/dsm.opt angegebenen Domains
Durch Auswahl von Aktionen -> Domäne sichern wird eine inkrementelle
Sicherung der Laufwerke bzw. Filesysteme, die in der dsm.sys/dsm.opt mittels
des DOMAIN-Statements eingetragen sind, durchgeführt.
Hier ist darauf zu achten, das die Include-/Exlucde-Liste in der dsm.sys/dsm.opt
greift und nur Dateien gesichert werden, die nicht ausgeschlossen sind. Durch entsprechende INCLUDE-Statements werden Dateien auch über unterschiedliche Managmentklassen gesichert.
42
Einführung in TSM
43
5.2. SICHERUNG ÜBER DIE KOMMANDOZEILE (DSMC)
5.1.3 Statusbericht
Nach dem Sicherungsvorgang wird ein Statusbericht zusammengestellt, der nützliche
Informationen liefert und ein fehlerhaftes Backup aufzeigen kann.
Folgende Informationen sind enthalten:
benötige Zeit
gesicherte Datenmenge
Durchsatzraten
Objektinformationen
Anhand der Objektinformationen kann festgestellet werden, wie viele Objekte untersucht wurden, welche gesichert wurden, wie viele fehlgeschlagen sind und welche als
inaktiv (gelöscht) markiert wurden. Detailinformationen von fehlgeschlagegenen Objekten sind durch Klicken auf Anzeigen verfügbar.
5.2 Sicherung über die Kommandozeile (dsmc)
Zur Sicherung über die Kommandozeile steht das Programm dsmc zur Verfügung. Im
folgenden wird kurz auf gängige Aufrufe eingegangen. Eine Beschreibung aller Optionen würde an dieser Stelle den Rahmen sprengen.
Die integrierte Hilfe, mit der Beschreibung zu allen Kommandos, kann durch dsmc help
aufgerufen werden.
Inkrementelles Backup aller in dsm.sys/dsm.opt angegebenen Laufwerke/Filesysteme:
dsmc incremental
43
Einführung in TSM
44
5.3. AUTOMATISIERTE SICHERUNG ÜBER DEN SCHEDULER
Inkrementelle Sicherung des Filesystems /home:
dsmc incremental /home
Inkrementelle Sicherung des Verzeichnisses /home/yd506ds inkl. aller Unterverzeichnisse
dsmc incremental -subdir=yes /home/yd506ds/*
Starten des Scheduler zur automatisierten Sicherung:
dsmc schedule
Bei einer Sicherung greifen die Include-/Exclude-Statements aus der dsm.sys/dsm.opt.
Bei einer inkrementellen Sicherung und entsprechenden INCLUDE-Statements werden
zudem unterschiedliche Managmentklassen für die Dateien verwendet.
5.3 Automatisierte Sicherung über den Scheduler
Die empfohlene automatiserte Sicherung über den Schedler wurde bereits im Kapitel
”Installation des Schedulers” auf Seite 32 erklärt.
An dieser Stelle wird kurz auf den Schedulerlogfile eingegangen, der alle Schritte des
durchgeführten Backups enthält.
5.3.1 Start des Backups
Beim Starten des Schedulers oder nach einem Backup fragt der Client beim Server nach
dem Zeitpunkt der nächsten Sicherung. Folgender Eintrag in der dsm.sys/dsm.opt
sollte zu finden sein:
19.02.03
19.02.03
19.02.03
19.02.03
19.02.03
19.02.03
19.02.03
19.02.03
19.02.03
19.02.03
01:37:14
01:37:14
01:37:14
01:37:14
01:37:14
01:37:14
01:37:14
01:37:14
01:37:14
01:37:14
--- SCHEDULEREC QUERY END
Next operation scheduled:
--------------------------------------------Schedule Name:
DAILY_EVENING
Action:
Incremental
Objects:
Options:
Server Window Start:
20:00:00 on 19.02.03
--------------------------------------------Waiting to be contacted by the server.
Der Ausgabe ist zu entnehmen, dass die nächste Sicherung am 19.02.2003 in einem
Zeitfenster ab 20:00 Uhr durchgeführt wird.
44
Einführung in TSM
45
5.3.2 Begin der Sicherung
Bei Beginn der Sicherung meldet der Scheduler zunächst welche Filespaces zur Sicherung vorgesehen sind:
19.02.03
19.02.03
20:00:17 Incremental backup of volume ’/export01’
20:00:17 Incremental backup of volume ’/export01/etc’
5.3.3 Meldungen während der Sicherung
Während der Sicherung wird für eine Datei, die sich im Vergleich zu der letzen inkrementellen Sicherung verändert hat, eine Information über die entprechende Aktion in
den Schedulerlogfile geschrieben.
Dem TSM-Server werden Änderungen in den folgenden Fällen mitgeteilt:
1. die Datei wurde geändert
2. die Datei wurde vom Filesystem gelöscht
3. die Datei wird über eine andere Managmentklasse gesichert
Ändert sich eine Datei, wird diese neu zum TSM-Server übertragen. Folgende Meldungen erscheinen deshalb während des Backupvorgangs:
...
19.02.03
...
19.02.03
...
19.02.03
...
20:00:27 Normal File-->
1,823 /etc/yp.conf [Sent]
21:15:48 Symbolic Link-->
22:15:16 Expiring-->
13 /etc/init.d [Sent]
760 /etc/inetd.conf [Sent]
5.3.4 Backupbericht am Ende der Sicherung
Nach dem Backupvorgang gibt der Backupbericht Aufschluss über den Status des
durchgeführten Backups. Folgende Informtionen sind verfügbar:
Anzahl untersuchter Objekte
Anzahl gesicherter Objekte
Anzahl aktualisierter Objekte
Anzahl neu gebundener Objekte
Anzahl gelöschter Objekte
Anzahl ausgelaufener Objekte
Anzahl fehlgeschlagener Objekte
45
Einführung in TSM
46
gesicherte Datenmenge
benötigte Zeit zur Datenübertragung
Netzwerk- und Datentransferrate
Komprimierungsgrad (an der RWTH keine Komprimierung)
insgesamt benötigte Zeit
Schedule Status (SUCCESSFULL, FAILED)
Im Schedlogfile taucht folgender Bericht auf:
--- SCHEDULEREC STATUS BEGIN
Total number of objects inspected: 5,353,643
Total number of objects backed up:
24,353
Total number of objects updated:
30
Total number of objects rebound:
0
Total number of objects deleted:
0
Total number of objects expired:
2,600
Total number of objects failed:
0
Total number of bytes transferred: 20.08 GB
Data transfer time:
5,311.13 sec
Network data transfer rate:
3,965.54 KB/sec
Aggregate data transfer rate:
1,047.04 KB/sec
Objects compressed by:
0%
Elapsed processing time:
05:35:15
--- SCHEDULEREC STATUS END
--- SCHEDULEREC OBJECT END DAILY_EVENING 19.02.03
20:00:00
Scheduled event ’DAILY_EVENING’ completed successfully.
Sending results for scheduled event ’DAILY_EVENING’.
Results sent to server for scheduled event ’DAILY_EVENING’.
Hier sollte kontrolliert werden, ob alle Dateien fehlerfrei gesichert wurden
(Total number of objects failed) und ob der Schedule mit dem Status
SUCCESSFUL beendet wurde (Scheduled event ’DAILY_EVENING’ completed successfully.).
Tritt während der Sicherung ein Fehler auf, wird der Schedule mit dem Status FAILED
und einem ”return code” beendet. Der ”return code” hat folgende Bedeutung:
46
Einführung in TSM
47
return code
0
4
8
12
Beschreibung
Der Schedule wurde erfolgreich abgeschlossen.
Der Schedule wurde bis auf einige nicht verarbeitete Dateien
erfolgreich abgeschlossen. Die meisten Gründe für nicht
verarbeitete Dateien sind:
o Die Datei ist in einer Exclude-Liste.
o Die Datei befindet sich während der Sicherung
in Zugriff durch eine andere Applikation.
o Die Datei ändert sich während der Sicherung.
Der Schedule wurde mit mindestens einer Warnung beendet.
Der Scheduler wurde mit mindestens einem Fehler beendet.
Bei Fehlern sollten der Errorlogfile und der Schedulerlogfile untersucht werden um
die betroffenen Dateien zu ermittelen und mögliche Ursachen für einen Fehler festzustellen. Sind Fehler vorhanden, sollten diese beseitigt werden, um ein fehlerfreies
Backup zu garantieren.
Interessant sind noch die beiden Werte ”Network data transfer rate” und ”Aggregate
data transfer rate”. Der erste Wert gibt den reinen Netzwerkdurchsatz an, der zweite Wert gibt den Datendurchsatz für das Backup insgesamt an. Dieser berechnet sich
aus dem Quotienten der übertragenen Datenmenge und der dazu benötigten Zeit. Aufgrund von internen Operationen auf dem TSM-Server und dem Client sowie Mountund Suchzeiten beim Lesen und Schreiben der Bänder ist dieser Wert im Normalfall
kleiner als der reine Netzwerkdurchsatz. Wird mit mehreren paralleln Session gesichert, so kann ”Aggregate data transfer rate” grösser als der reine Netzwerkdurchsatz
sein.
47
Einführung in TSM
Kapitel 6
Restore von Dateien
6.1 Fall des Datenverlustes
Im Falle eines grösseren Datenverlustes ( 10 GB ) sollte zunächst Kontakt mit dem
Rechen-und Kommunikationszentrum aufgenommen werden, um weitere Schritte abzusprechen.
In der Regel liegt die Ursache für einen grösseren Datenverlust in einem Hardwaredefekt. Erfahrungsgemäß muss dann zunächst neue Hardware beschafft werden, um
mit dem Restore der Daten beginnen zu können.
Diese Ausfallzeit sollte aber nicht abgewartet werden, da in dieser Zeit bereits serverseitig Maßnahmen getroffen werden können, die anschliessend den Restore erheblich
beschleunigen (Erzeugen von Backupsets).
Sollte eine neue Maschine neu installiert werden, ist es empfehlenswert insbesondere das Netzwerk zu testen, bevor der Restore begonnen wird, um diesen durch das
Netzwerk nicht noch weiter zu verzögern.
Sollte ein Restore sofort nach Verlust der Daten möglich sein, können Prozesse auf
dem Server so koordiniert werden, dass Laufwerke für den Restore zur Verfügung stehen.
6.2 Restore großer Filesysteme (Disaster-Restore)
Eine große Schwäche von TSM sind Restores grosser Filesysteme mit sehr vielen (kleinen) Dateien. Ein Restore kann in einem solchen Fall sehr lange dauern und sich über
mehere Tage erstrecken (bei einem langsamen Netzwerk sind noch längere Restorezeiten zu erwarten).
Dies hat folgende Gründe:
um zu ermitteln, welche Dateien restauriert werden müssen und wo sich diese
48
49
6.3. VORBEREITUNGEN
befinden, braucht der TSM-Server relativ lange um diese Informationen aus der
Datenbank auszulesen
bei großen Filesystemen mit vielen Dateien, können die Dateien über sehr viele
Bänder verstreut sein; diese Bänder müssen alle gemountet werden
am zeitaufwendigsten ist das Suchen und Ansteuern einer Datei auf dem Band;
dazu muss gespult und ständig neu positioniert werden
die zu restaurierenden Dateien befinden sich in der Regel nicht hintereinander
auf dem Band, so dass ständig neu positioniert werden muss
Leider ist die Restorezeit stark abhänig von den oben genannten Eigenschaften, die
nur in stark begrenztem Maße beeinflussbar sind, da diese direkt vom Softwareprodukt
sowie den Eigenschaften der Hardware abhängen.
Möglichkeiten zur Beschleunigung des Restores (und des Backups) sind im Kapitel
”Optimierungsmöglichkeiten” auf Seite 58 dargestellt.
Das Problem des Restores von großen Filesystemen zeigt noch einmal, dass bei der
Einrichtung eines Backup-Clients genau über die zu sichernden Daten nachgedacht
werden sollte. Eine geeignete Auswahl der Dateien bedeutet auch eine geringere zu
übertragende Datenmenge, die unmittelbar mit der Restore-Zeit zusammenhängt.
6.2.1 Alternativen / Ergänzungen für den Disasterfall
Falls die entsprechende Hardware verfügbar ist, könnte als Ergänzung und zur Beschleunigung des Restores, lokal eine Synchronisation der Dateien vorgenommen werden.
Als Beispiel dient rsync auf einem Unix System. Die Daten einer Festplatte könnten
z.B. periodisch nachts mittels rsync auf eine andere Platte kopiert bzw. synchronisiert
werden. In einem Restore Fall könnten die Daten von dieser Platte restauriert werden.
Für wichtige Daten (z.B. Benutzerdaten) könnte weiterhin ein Backup mittels TSM
durchgeführt werden (alle Vorteile wie z.B. mehere Versionen sind verfügbar), sodass
diese Daten nach dem ”lokalen Restore” von Platte, vom TSM-Server restauriert werden können.
6.3 Vorbereitungen
Bevor ein größerer Restore durchgeführt wird, müssen alle anderen ”dsm-Prozesse” beendet werden. Alle noch laufenden Backups müssen beendet werden und insbesondere
muss der Scheduler gestoppt werden. Erst danach sollte mit dem Restore begonnen
werden um Konflikte zwischen den Prozessen zu verhindern. Es ist darauf zu achten,
49
Einführung in TSM
50
6.4. RESTORE ÜBER DIE GRAFISCHE OBERFLÄCHE (DSM)
dass nach einem Totalverlust der Daten der Scheduler gar nicht mehr gestartet werden darf. Würde zum Beispiel nach einem Plattenausfall ein Backup durchgeführt, bewirkt dies ein ”expire” aller Daten dieser Platte, d.h. auf dem TSM-Server sind keine
aktiven Versionen der Dateien mehr vorhanden. Um die Daten zu restaurieren, muss
ein (langsamer) Point-In-Time-Restore durchgeführt werden. Um dies zu verhindern
kann beispielweise auf einem Unix-System vor der Ausführung des Schedules mit dem
PRESCHEDULECMD-Statement ein Skript zur Ausführung gebracht werden, das testet
ob zu sichernde Platten gemountet sind. Sind diese nicht gemountet kann der SchdulerProzess durch dieses Skript terminiert werden, so dass der TSM-Server weiterhin aktive Versionen der Dateien hält.
6.4 Restore über die grafische Oberfläche (dsm)
Durch Klicken auf das dsm-Icon oder durch Eingabe von dsm in der Kommandozeile
wird der grafische Client gestartet.
Hier muss aus dem Menüpunkt Aktionen der Punkt Zurückschreiben gewählt
werden.
50
Einführung in TSM
51
6.4. RESTORE ÜBER DIE GRAFISCHE OBERFLÄCHE (DSM)
Die Dateien, die restauriert werden sollen, müssen jetzt selektiert werden. Im linken
Teil können durch Markieren der grauen Boxen, ganze Filesysteme oder einzelne Verzeichnisse selektiert werden. Im rechten Teil können einzelne Dateien eines Verzeichnisses selektiert werden. Dazu muss zunächst im linken Teil das entsprechende Verzeichnis durch Klick auf den Namen ausgewählt werden. Die Dateien dieses Verzeichnisses werden dann im rechten Teil angezeigt und können ausgewählt werden. Mit
Zurückschreiben wird der Restore gestartet.
6.4.1 Aktive / inaktive Sicht der Dateien
Standardmäßig werden nur aktive Dateien des TSM-Servers angezeigt. Um auch inkative (also vom Filesystem gelöschte) Dateien restaurieren, bzw. zunächst selektieren zu
können, muss die Sicht umgeschaltet werden:
51
Einführung in TSM
52
6.5. AUSWAHL DER ZIELVERZEICHNISSES
Hier muss im Menüpunkt Sicht vom Punkt Nur aktive Dateien anzeigen
auf Aktive/inaktive Dateien anzeigen umgeschaltet werden. Es werden
jetzt auch inaktive Dateien angezeigt. Diese Dateien sind durch ein blaues Symbol
markiert. Auf Unix-Systemen sind inaktive Dateien durch ein rotes Quadrat vor dem
Dateinamen markiert.
Die Auswahl kann genauso vorgenommen werden, wie bei der aktiven Sicht. Zu jeder
Datei sind Informationen über Erstellungs-, Änderungs- und Sicherungsdatum vorhanden, so dass die gewünschte Version der Datei leicht ausgewählt werden kann.
6.5 Auswahl der Zielverzeichnisses
Nach Klicken auf Zurückschreiben wird der Restore gestartet. Zunächst muss
jedoch noch das Zielverzeichnis ausgewählt werden.
52
Einführung in TSM
53
6.5. AUSWAHL DER ZIELVERZEICHNISSES
In den meisten Fällen ist es gewünscht, die Dateien an die originale Position zu restaurieren. Dazu kann der bereits selektierte Punkt Ursprünglicher Standort
beibehalten werden.
Sollen die Dateien an anderer Stelle im Filesystem restauriert werden, so ist zunächst
der Punkt Folgender Standort und ein entsprechendes Zielverzeichnis auszuwählen.
Weiterhin ist eine der vier Methoden
1. Pfad vollständig zurückschreiben
2. Pfad teilweise zurückschreiben
3. Pfad teilweise ohne Basisverzeichnis zurückschreiben
4. Verzeichnisstruktur nicht beibehalten
auszuwählen.
Die verschiedenen Methoden bedeuten dabei:
1. Die gesamte Verzeichnisstruktur beginnend vom Wurzelverzeichnis (ausgenommen der Filespacename), inkl. aller Dateien, wird an der neuen Position wiederhergestellt.
2. Alle Unterverzeichnisse (ohne das Wurzelverzeichnis), inkl. aller Dateien, werden an der neuen Position wiederhergestellt.
3. Nur das Wurzelverzeichnis (keine Unterverzeichnisse), inkl. aller Dateien, wird
an der neuen Position wiederhergestellt.
4. Die Verzeichnisstruktur wird nicht wiederhergestellt. Alle Dateien werden direkt
(ohne Wurzel- und Unterverzeichnisse) im Zielverzeichnis wiederhergestellt.
Durch Klicken von Zurückschreiben wird der Restore durchgeführt.
53
Einführung in TSM
54
6.6. RESTOREBERICHT
6.6 Restorebericht
Nach einem Restore wird ein Bericht erstellt, der verschiedenen Angaben über den
durchgeführten Restore enthält.
Folgende Angaben sind enthalten:
benötigte Zeit
übertragene Datenmenge
Durchsatzraten
Anzahl restaurierter Objekte (erfolgreiche und fehlgeschlagene)
Bei den Durchsatzraten werden die zwei Werte Netzwerk und Gesamt angegeben. Netzwerk gibt den reinen Netzwerkduchsatz an. Gesamt gibt den tatsächlichen
Durchsatz an (Quotient aus übertragener Menge und benötigter Zeit). Der zweite Wert
ist aufgrund von Datenbankanfragen, Mountzeiten, sowie Spul- und Positionierungszeiten der Laufwerke kleiner als der reine Netzwerkdurchsatz.
Im unteren Teil sollte überprüft werden, ob der Restore von Dateien fehlgeschlagen
ist. Durch Klicken auf Anzeigen erhält man Informationen, welche Dateien nicht restauriert wurden.
6.7 Restore über die Kommandozeile (dsmc)
Ähnlich wie beim Backup von Dateien über die Kommandozeile ist es auch möglich
einen Restore über die Kommandozeile anzustossen. Dazu wird ebenfalls das Programm dsmc verwendet. Da auch beim Restore sehr viele Parameter angegeben werden können, werden einige ausgewählte Aufrufe vorgestellt.
54
Einführung in TSM
55
6.8. POINT-IN-TIME RESTORE
Die integrierte Hilfe mit der Beschreibung zu allen Optionen und Parametern kann
durch dsmc help aufgerufen werden.
Wiederherstellen eines Verzeichnisses ohne Unterverzeichnisse:
dsmc restore /home/ae106st/*
Wiederherstellen eines Verzeichnisses inkl. Unterverzeichnisse:
dsmc restore -subdir=yes /work/ae106st/*
Wiederherstellen eines Verzeichnisses inkl. Unterverzeichnisse mit kompletten Pfad:
dsmc restore -subdir=yes -preservpath=complete c:\ae106st
Wiederherstellen eines Verzeichnisses inkl. Unterverzeichnisse mit partiellem Pfad:
dsmc restore -subdir=yes -preservpath=partial c:\ae106st
Wiederherstellen eines Verzeichnisses inkl. Unterverzeichnisse ohne Verzeichnisstruktur:
dsmc restore -subdir=yes -preservpath=none c:\ae106st
6.8 Point-in-time Restore
Point-in-time Restore bietet die Möglichkeit beim Restore eines Filespaces den Zustand eines bestimmten Zeitpunktes wiederherzustellen. Voraussetzung ist, das inkrementelle Sicherungen durchgeführt werden und die entsprechenden Versionen der Dateien vorhanden sind. Es wird versucht diejenigen Dateien zu restaurieren, die entweder
genau zu dem angegebenen Zeitpunkt, oder davor gesichert wurden.
Beim Point-in-time-Restore werden allerdings diejenigen Dateien, die seit dem angegebenen Zeitpunkt neu erstellt wurden nicht gelöscht, so dass nach dem Restore nicht
der originale Zustand des Systems gegeben ist.
Der Point-in-time Restore kann sowohl über die grafische Oberfläche als auch über
die Kommandozeile durchgeführt werden.
55
Einführung in TSM
56
6.8.1 grafische Oberfläche
Zunächst muss durch Auswahl des Menüpunktes Aktionen -> Zurückschreiben
Zum Restore-Fenster gewechselt werden.
Hier muss auf Nach Zeitpunkt geklickt werden, sodoass sich ein neues Fenster
öffnet.
Zunächst muss die Box Beim Zurückschreiben das Datum eines Zeitpunktes verwenden
selektiert werden. Anschliessend kann das Datum und die Uhrzeit eingestellt werden,
die verwendet werden soll. Mit OK bestätigen.
56
Einführung in TSM
57
Neben der Schaltfläche Nach Zeitpunkt erscheint jetzt die eingestellte Zeit. Die
gewünschten Dateien müssen jetzt noch wie gewöhnt selektiert und mit Zurückschreiben
der Restore gestartet werden.
6.8.2 Kommandozeile
Bei der Durchführung eines Point-in-time Restores über die Kommandozeile werden
die beiden Parameter PITDATE und PITTIME verwendet.
Folgendes Kommando führt einen Point-in-time Restore mit dem Datum ”24.02.2003
16:00 Uhr” durch:
dsmc restore -subdir=yes pitdate=02/24/2003 pittime=16:00 /home/ae106st/*
57
Einführung in TSM
Kapitel 7
Optimierungsmöglichkeiten
Auf die Problematiken des Backups und Restores wurde in den vorherigen Kapiteln
bereits eingegangen. Im folgenden werden einige Möglichkeiten vorgestellt, um die
Performance des Backups und Restores zu verbessern.
An dieser Stelle sei aber nochmals darauf hingewiesen, dass die durch Hardware- und
Softwareeigenschaften gegebenen Probleme damit nicht vollständig beseitigt werden
können (siehe insbesondere auch Kapitel ”Restore großer Filesysteme” auf Seite 48).
Die folgenden Punkte stellen einige Möglichkeiten vor, zumindest in kleinerem Maße
Performancesteigerungen zu erreichen.
7.1 Parallele Backup Sessions
Eine Möglichkeit Performancesteigerungen beim Backup zu erzielen, kann durch Einrichten mehrerer paralleler Backup Sessions erreicht werden.
Voraussetzung sind mehrere Filespaces (mehrere DOMAIN-Einträge in der dsm.sys/dsm.opt)
die gesichert werden. Durch die Option RESOURCEUTILIZATION kann die Anzahl
der Backup Sessions eingestellt werden. Der Eintrag muss in der dsm.sys/dsm.opt
vorgenommen werden.
Werden beispielsweise sechs Filespaces gesichert und ist in der dsm.sys/dsm.opt
die Option
RESOURCEUTILIZATION
4
angegeben, so werden beim Backup vier Sessions mit dem TSM-Server aufgebaut, so
dass drei Filespaces parallel gesichert werden (eine Session wird als Kontrollsession
verwendet).
Dabei ist darauf zu achten, das genügend Netzwerkperformance vorhanden ist. Werden die Sessions durch das Netzwerk wieder ”ausgebremst” kann dies auch zu einem
58
59
7.2. PARALLELE RESTORE SESSIONS
Performanceverlust führen.
Zudem wird mehr Rechenleistung und Speicher vom Client benötigt. Hierbei ist darauf zu achten, dass das System nicht komplett durch den Backupprozess ausgelastet
ist, sonderen noch genug Ressourcen für andere Dienste zur Verfügung stehen.
Wichtig: Aus den oben genannten Gründen sollte die Option RESOUREUTILIZATION
mit Vorsicht verwendet werden. Es sollte zunächt mit einem niedrigen Wert getestet
werden, ob eine Perfomanceseteigerung erzielt wurde und dann in kleinen Schritten
inkrementiert werden, bis eine optimale Einstellung gefunden wurde. Zudem ist eine
Absprache mit dem Rechen- und Kommunikationszentrum notwendig, da serverseitig
Parameter erhöht werden müssen, um mehrere parallele Sessions zuzulassen.
7.2 Parallele Restore Sessions
In einem Restore Fall kann der Restore, ähnlich dem oben beschriebenen Backup, auch
mit mehrerenen parallelen Sessions durchgeführt werden. Die Vorgehensweise unterscheidet sich allerdings.
Um mehrere Restoresessions aufzubauen, müssen mehrere dsm bzw. dsmc Prozesse
gestartet werden. Dies bedeutet, dass entweder mehrere grafische dsm-Clients aufgerufen werden, oder mehrere Restores mittels dsmc angestossen werden.
Werden mehrere grafische Clients gestartet, muss mit jedem Client ein anderer Filespaces restauriert werden. Dies gilt ebenfalls für den Aufruf mittels dsmc über die
Kommandozeile.
Auch hier sollte darauf geachtet werden, dass die Anzahl der Sessions im Verhältnis zur
Restoreperformance stimmt. Es können die selben Problematiken auftreten wie im vorigen Kapitel ”Parallele Backup Sessions” beschrieben und weiterhin ist es vorstellbar,
dass sich Prozesse gegenseitig ausbremsen wenn Sie auf das gleiche Band zugreifen
müssen.
Zudem ist die Performance auch durch die Backup-Hardware des TSM-Servers begrenzt. Würden z.B. 20 Filespaces parallel restauriert, die alle auf unterschiedlichen
Bänder in der Library liegen, so müssten alleine für den Restore 20 Laufwerke zur
Verfügung stehen. Hier sei auch noch einmal darauf hingewiesen, dass im Falle eines
grösseren Datenverlustes Kontakt mit dem Rechen- und Kommunikationszentrum aufgenommen werden sollte. Siehe dazu auch Kapitel ”Fall des Datenverlustes” auf Seite
48.
59
Einführung in TSM
60
7.3. JOURNAL BASED BACKUP
7.3 Journal Based Backup
Eine weitere Möglichkeit das Backup zu beschleunigen, wird durch den Einsatz von
”Journal Based Backup” möglich. Leider ist dieses Feature zur Zeit nur für Windows
Systeme verfügbar.
Bei einer inkrementellen Sicherung muss der Client, um Änderungen im Filesystem
zur vorherigen inkrementellen Sicherung festzustellen, durch das komplette Filesystem ”laufen” und jede Datei untersuchen. Bei grossen Filesystemen kann dies viel Zeit
in Ansprch nehmen.
Hier setzt ”Journal Bases Backup” an. Für lokale Filesysteme (keine Netzlaufwerke)
können sogenannte Journale geführt werden, in denen Änderungen im Filessystem protokolliert werden. Technisch werden diese Journale mittels einer Datenbank umgesetzt.
Die Protokollierung erfolgt durch den TSM-Client, der sich dazu gewisser Funktionalitäten des Betriebssystems bedient.
Bei einer inkrementellen Sicherung wird anhand der Daten des Journals festgelegt,
welche Dateien sich in welcher Weise geändert haben. Ein ”Durchlaufen” des Filesystem entfällt somit. Dies führt in der Regel zu einer erheblichen Performancesteigerung
(vor allem bei grossen Filesystemen).
Wie bereits erwähnt ist diese Journalsteuerkomponente nur für lokale Filesysteme unter Windows-Systemen verfügbar.
Im folgenden wird die Installation der Journalsteuerkomponente über den Wizard kurz
beschrieben:
Aus dem Menüpunkt Dienstprogramme den Punkt Setup Assistent auswählen
um den Wizard zu öffnen.
60
Einführung in TSM
61
Hier den Punkt TSM-Journalsteuerkomponente auswählen und mit Weiter
bestätigen.
Um eine neue Journalsteuerkomponente für das System zu installieren, den Punkt
Neue TSM-Journalsteuerkomponente installieren auswählen und mit
Weiter bestätigen.
61
Einführung in TSM
62
In diesem Fenster müssen die (lokalen) Filesysteme ausgewählt werden, für die ein
Journal geführt werden soll. Wenn der markierte Punkt ausgewählt wird, werden für
alle (lokalen) Filesysteme Journale geführt. In der unteren Box können aber auch einzelene Filesysteme ausgewählt werden.
Hier muss das Verzeichnis angegeben werden, in dem die Journaldatenbanken abgelegt
werden. Auf dem Filesystem sollte genügend freier Speicherplatz vorhanden sein. Mit
62
Einführung in TSM
63
Hier können die Filesystemaktionen ausgewählt werden, die vom Journal Service protokolliert werden. Die empfohlene Grundeinstellung sollte beibehalten werden. Mit
Hier muss für jedes Filesystem die maximale Größe der Journaldatenbank festgelegt
werden. Durch Auswahl der markierten Box und Bestätigung mit Weiter wird keine
Begrenzung festgelegt.
63
Einführung in TSM
64
Hier wird festgelegt unter welchen Systemkonto der Dienst läuft. Es sollte Das Systemkonto
selektiert werden und mit Weiter bestätigt werden.
Durch Anwählen von Ja wird der Journal Service nach der Konfiguration automatisch
gestartet. Bestätigen mit Weiter.
64
Einführung in TSM
65
Durch Klicken auf Fertig stellen wird die Installation der Journalsteuerkomponente abgeschlossen.
Nach erfolgreicher Installation erscheint eine Meldung. Mit OK beenden.
Nach der Installation sollte kontrolliert werden, ob der Dienst installiert und gestartet
ist. Der Eintrag TSM Journal Service sollte unter den Diensten sichtbar sein.
65
Einführung in TSM
66
Die Journalsteuerkomponente bietet sehr viele Konfigurationsmöglichkeiten mittels
Optionen und Pararmetern. Die zentrale Konfigurationsdatei heisst tsmjbbd.ini
und ist im Installationsverzeichnis unter baclient zu finden. Eine Installation kann
neben der Installation über den grafischen Client auch mittels dsmc durchgeführt werden.
Neben allen Vorteilen kann Journal Based Backup auch eine neue Fehlerquelle darstellen. Deswegen sollte die Errorlogdatei periodisch auf Fehler hin überprüft werden.
Die Errorlogdatei kann in tsmjbbd.ini angegeben werden.
An dieser Stelle wird darauf verzichtet auf die Einzelheiten der Journalsteuerkomponente einzugehen. Informationen sind in der offiziellen Dokumentation zu finden.
66
Einführung in TSM
Kapitel 8
Aufgaben bei der Betreuung des
Backupclients
8.1 Administrative Aufgaben
Bei einem korrekt installiertem und konfiguriertem Backupclient, der eine gewisse Zeit
lang problemlos automatisierte Sicherungen durchgeführt hat, kann es durch eine Fülle
von Ursachen zu Problemen bei der Sicherung kommen, ohne dass der Administrator
dies bemerkt. Dies ist insbesondere dann kritisch, wenn in einem Desasterfall Daten
benötigt werden, die aber aufgrund nicht durchgeführter Backups nicht auf dem TSMServer verfügbar sind. Um solche Überraschungen zu vermeiden, müssen verschiedene
administrative Tätigkeiten durchgeführt werden:
Regelmässige Kontrolle der Scheduler- und Errorlogfiles. Tauchen kritische Fehler auf, müssen diese behoben werden.
Update des Clients auf die aktuelle Version.
Ausschluss von Dateien, die durch andere Prozesse im Zugriff sind oder Einsatz
von ”Open File Support” (siehe dazu Seite 38).
Emailbenachrichtigung bei fehlerhaftem oder verpasstem automatisiertem Backup
beachten.
8.2 Sonstige Aufgaben
Weiterhin sollten folgende Dinge beachtet werden:
Bei Änderung der Daten der Ansprechpartner das Rechen- und Kommunikationszentrum informieren.
Im Falle des Restores großer Datenmengen, Kontakt mit dem Rechen- und Kommunikationszentrum aufnehmen.
67
68
8.3. FILESPACES AUS DEM BACKUP HERAUSNEHMEN
8.3 Filespaces aus dem Backup herausnehmen
Werden Filespaces aus dem Backup herausgenommen, muss dies dem Rechen- und
Kommunikationszentrum mitgeteilt werden, damit diese Daten vom TSM-Server gelöscht
werden können, da dies nicht automatisch geschieht. Nicht mehr gesicherte Filespaces
belegen Speicherplatz auf dem TSM-Server, erfüllen aber Ihren Zweck hinsichtlich
eines Backups nicht. Hier noch einmal der Hinweis, dass der Backupdienst nicht als
Langzeitarchivierung von Daten zu sehen ist.
Wird ein Filespace, der einige Zeit gesichert wurde aus dem Backup herausgenommen,
d.h. der entsprechende DOMAIN-Eintrag aus der dsm.sys/dsm.opt herausgenommen, so erhält der TSM-Server keine Information darüber, dass dieser Filespace nicht
mehr gesichert oder benötigt wird. Das heisst, aus Sicht des TSM-Servers ändert sich in
diesem Filesspace nichts, obwohl eventuell alle Dateien aus diesem Filespace vom lokalen Filesystem gelöscht wurden. Somit hält er alle aktiven Versionen für unbegrenzte
Zeit.
Um dies zu vermeiden sollten DOMAIN-Einträge entweder nicht aus der dsm.sys/dsm.opt
entfernt werden, oder das Rechen- und Kommunikationszentrum darüber informiert
werden, dass ein DOMAIN-Eintrag entfernt wurde, so dass der entsprechende Filespace
vom TSM-Server gelöscht werden kann.
68
Einführung in TSM
Kapitel 9
Sicherung von Datenbanken
Bei der Sicherung einer Datenbank ist zu beachten, dass diese nicht im laufenden Betrieb gesichert werden kann. Die Datenbank muss sich zum Zeitpunkt der Sicherung in
einem konsistenten Zustand befinden und der Backupclient muss auf die Dateien der
Datenbank zugreifen können. Im laufenden Betrieb ist dies fast immer nicht der Fall.
9.1 Tivoli Data Protection Agenten
Eine Möglichkeit Datenbanken zu sichern ist durch spezielle Agenten möglich, die eine
Sicherung im laufenden Betrieb ermöglichen. Dazu muss eine Software auf dem Datenbanksystem installiert werden, die ähnlich dem Backup-/Archivclient, als Schnittstelle
zwischen dem zu sichernden System und dem Backupserver zu sehen ist. Es existieren
für verschiedene Datenbanken und Betriebsysteme solche Agenten, die allerdings kostenpflichtig sind.
9.2 Sicherung von dumps
Für fast alle Datenbanksysteme existieren freie Programme und Tools, die eine konsistente Kopie der Datenbank oder einzelner Tabellen im laufenden Betrieb erzeugen und
im Filesystem ablegen, so dass in einem Restorefall die Datenbank problemlos mittels
dieser konsistenten Kopie wiederhergestellt werden kann. Zudem ist es möglich, diese
Kopie mit dem Backup-/Archiv-Client zu sichern und zu restaurieren.
69
70
9.2. SICHERUNG VON DUMPS
9.2.1 Beispiel: mysql-Datenbank und mysqlhotcopy
Im folgenden wird gezeigt wie eine mysql-Datenbank gesichert werden kann. Dieses
exemplarische Beispiel kann leicht auf andere Datenbanken übertragen werden, so dass
diese in ähnlicher Weise gesichert werden können.
Zunächst wird das frei verfügbare perl-Programm mysqlhotcopy benötigt. Dieses
Programm erzeugt im laufenden Betrieb eine konsistente Kopie einer mysql-Datenbank
im Filesystem, ohne diese herunterzufahren.
Die Sicherung einer mysql-Datenbank kann somit durchgeführt werden, indem vor der
Sicherung eine Kopie der Datenbank in einem Verzeichnis mittels mysqlhotcopy
erzeugt wird und anschliessend dieses Verzeichnis mit der Datenbank-Kopie gesichert
wird.
Beispielsweise kann eine Kopie der Datenbank tsm_db in das Verzeichnis /backup/dbcopy
folgendermassen erzeugt werden:
mysqlhotcopy -u <user> -p <pass> tsm_db /backup/dbcopy
Anschliessend braucht nur noch das Verzeichnis /backup/dbcopy gesichert zu
werden.
Um dieses Vorgang mit dem Scheduler zu automatisieren, kann vor der Ausführung
des Schedules ein Kommando auf Systemebene abgesetzt werden. Dazu muss in der
dsm.sys/dsm.opt folgende Option angegeben werden:
PRESCHEDULECMD <command>
Um eine automatisierte Sicherung der Datenbank tsm_db durch den Scheduler durchführen
zu lassen, sind Einträge der folgenden Form in der dsm.sys/dsm.opt notwendig:
...
PRESCHEDULECMD
...
VIRTUALMOUNTPOINT
DOMAIN
...
mysqlhotcopy -u u -p p tsm_db /backup/dbcopy
/backup/dbcopy
/backup/dbcopy
Falls mehere Datenbanken gesichert werden müssen, empfiehlt es sich die Aufrufe
von mysqlhotcopy von einem Shell-Skript durchführen zu lassen, welches mit dem
PRESCHEDULECMD-Statement vor der Sicherung zur Ausführung gebracht wird und
die konsistenten Kopien der der Datenbanken erzeugt:
#! /usr/bin/bash
#
# name:
make_db_copy.sh
# location: /home/ae106st/bin
#
70
Einführung in TSM
71
9.2. SICHERUNG VON DUMPS
# description:
# make consitent database copies
#
mkdir -p /backup/dbcopy
mysqlhotcopy -u u -p p tsm_db1 /backup/dbcopy
In der dsm.sys/dsm.opt wird das Skript dann aufgerufen:
...
PRESCHEDULECMD
...
VIRTUALMOUNTPOINT
DOMAIN
...
/home/ae106st/bin/make_db_copy.sh
/backup/dbcopy
/backup/dbcopy
In einem Restorefall können dann die Kopien mit dem Backup-/Archiv-Client restauriert werden und die originale Datenbank wiederhergestellt werden. Dazu müssen die
Kopien in das Verzeichnis der originalen Datenbank kopiert werden.
71
Einführung in TSM
Anhang A
Beispiel dsm.sys für
Unix-Systeme
******************************************************************
*
* dsm.sys option file for Unix Clients
*
******************************************************************
* TSM-Server und Ports ermitteln und eintragen
* DEFAULTSERVER, SERVERNAME und TCPSERVERADRESS sind gleich,
* z.B backup04.rz.rwth-aachen.de
* --------------------------------------------------------------DEFAULTSERVER
SERVERNAME
TCPSERVERADDRESS
TCPPORT
15XX
* Die folgenden 4 Eintrage unveraendert lassen
* --------------------------------------------------------------COMMMETHOD
tcpip
PASSWORDACCESS
generate
SCHEDMODE
polling
TXNBYTELIMIT
25600
*
*
*
*
Geben Sie mit NODENAME den Namen des Rechners an, wie er
im TSM-Server registriert ist (wird Ihnen vom
Rechenzentrum mitgeteilt):
----------------------------------------------------------------
72
73
NODENAME
mycomputer.mydomain.rwth-aachen.de
* Logfiles:
* ---------------------------------------------------------------SCHEDLOGNAME
/var/log/dsmsched.log
ERRORLOGNAME
/var/log/dsmerror.log
* Mit ’DOMAIN’ geben Sie die Verzeichnisse an, die Sie sichern
* wollen. Ein Verzeichnis, das kein Mountpoint eines Filesystems
* ist, muss zusaetzlich als VIRTUALMOUNTPOINT deklariert
* werden.
*
* Im nachfolgenden Beispiel sind /home und /etc fuer die
* Sicherung vorgesehen, wobei aber nur /home ein eigenes
* Filesystem ist.
* ---------------------------------------------------------------VIRTUALMOUNTPOINT
/etc
DOMAIN
/home
DOMAIN
/etc
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
Mit INCLUDE koennen einzelne Dateien aus zuvor ausgeschlossenen
Bereichen mit in die Sicherung aufgenommen werden. Beachten,
Sie, dass die Reihenfolge von EXCLUDE/INCLUDE-Statements
relevant ist! Fuer naehere Informationen verweisen wir Sie
auf die TSM-Dokumentation.
Die folgenden Exclude-Statements werden vom TSM-Server
vorgegeben und brauchen nicht definiert zu werden. Die
Statements schliessen die Caches fuer Konqueror, Mozilla
und Netscape sowie core-Files aus der Sicherung aus.
---------------------------------------------------------------EXCLUDE
’/.../.kde/share/cache/http/.../*’
EXCLUDE
’/.../.mozilla/.../.../Cache/.../*’
EXCLUDE
’/.../.netscape/cache/.../*’
EXCLUDE
’core’
EXCLUDE
’/.../dsmerror.log’
EXCLUDE
’/.../dsmsched.log’
73
Einführung in TSM
Anhang B
Beispiel dsm.opt für
Windows-Systeme
******************************************************************
*
* dsm.opt option file for Windows clients
*
******************************************************************
* TSM-Server und Ports ermitteln und eintragen
* DEFAULTSERVER, SERVERNAME und TCPSERVERADRESS sind gleich,
* z.B backup04.rz.rwth-aachen.de
* --------------------------------------------------------------SERVERNAME
TCPSERVERADDRESS
TCPPORT
15XX
* Die folgenden 4 Eintrage unveraendert lassen
* --------------------------------------------------------------COMMMETHOD
tcpip
PASSWORDACCESS
generate
SCHEDMODE
polling
TXNBYTELIMIT
25600
* Geben Sie mit NODENAME den Namen des Rechners an, wie er
* im TSM-Server registriert ist (wird Ihnen vom
* Rechenzentrum mitgeteilt):
74
75
* ---------------------------------------------------------------NODENAME
mycomputer.mydomain.rwth-aachen.de
* Datums-, Zeit-, und Zahlenformat festlegen
* ---------------------------------------------------------------DATEFORMAT
4
TIMEFORMAT
1
NUMBERFORMAT
4
* Logfiles:
* ---------------------------------------------------------------SCHEDLOGNAME
c:\temp\dsmsched.log
ERRORLOGNAME
c:\temp\dsmerror.log
* Haltezeit (Tage) fuer Eintraege im Schedulerlogfile
* ---------------------------------------------------------------SCHEDLOGRETENTION
14
* Haltezeit (Tage) fuer Eintrage im Errorlogfile
* ---------------------------------------------------------------ERRORLOGRETENTION
14
* Sicherung der Registry mit einschliessen
* ---------------------------------------------------------------BACKUPREG
yes
*
* Geben Sie mit DOMAIN die Laufwerke an, die Sie sichern wollen.
* Achtung: Falls Sie kein DOMAIN-Statement angeben, werden
* standardmaessig alle lokalen Bereiche, inklusive CD’s (!)
* gesichert.
*
* Falls Sie einzelne Directories sichern wollen,
* muessen Sie diese mit INCLUDE definieren.
* ---------------------------------------------------------------DOMAIN
c:
DOMAIN
d:
* Mit INCLUDE koennen einzelne Dateien aus zuvor ausgeschlossenen
* Bereichen mit in die Sicherung aufgenommen werden. Beachten,
75
Einführung in TSM
76
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
Sie, dass die Reihenfolge von EXCLUDE/INCLUDE-Statements
relevant ist! Fuer naehere Informationen verweisen wir Sie
auf die TSM-Dokumentation.
Die folgenden Exclude-Statements werden vom TSM-Server
vorgegeben und brauchen nicht definiert zu werden. Die
Statements schliessen Systemdateien, temporaere Dateien,
sowie Caches von der Sicherung aus.
---------------------------------------------------------------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
’*:\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’
76
Einführung in TSM

Skript

Transcription

Similar documents

VERITAS Software

Mehrwert für den Mittelstand

EASY Solution Guide - CTO Balzuweit GmbH

WinEdt-Minikurs Web Version

THE ALTERNATIVE LISTE WEST BERLIN AND THE