IBM Tivoli Storage Manager (Teil III):

Sichern und Archivieren

Nachdem wir uns in den vorangegangenen Teilen dieser Reihe mit dem grundsätzlichen Aufbau und einigen internen Details beschäftigten, widmen wir uns in dieser Ausgabe der Konfiguration der Hauptfunktionen von TSM, dem Sichern und Archivieren von Clients.

Abb. 1: Policies und Client-Optionen steuern Backup und Archivierung.

Sichern und Archivieren

TSM kennt drei Grundfunktionalitäten: Das Sichern (Backup), das Archivieren von Client-Dateien und das Restaurieren von Dateien. Wie schon erwähnt, sprechen wir an dieser Stelle über das Sichern und Archivieren. Die beiden Methoden Sichern und Archivieren unterscheiden sich durch ihre Ansätze (siehe Abbildung 2).

Abb. 2: Die Grundfunktionen des TSM.

Archivierung

Die Archivierung wird in vielen Anwendungsfällen eher sporadisch durchgeführt und dient der Langzeitsicherung von Daten. Wie lange die Aufbewahrungsfrist ist, wird durch den Parameter RETVER bestimmt. Voreinstellung ist 365 Tage.

Sicherung

Sicherungen finden zyklisch in regelmäßigen Abständen statt. Außer den aktuellen Dateien – im TSM-Jargon "activ" genannt – möchte man in der Regel einige Kopien alter Stände ("inactive") aufbewahren (VEREXISTS).

Werden Dateien auf dem Client gelöscht, benötigt man normalerweise nur noch ein oder einige wenige Backups (VERDELETED) auf Band. Außerdem ist es nicht nötig, inaktive Versionen unendlich lange aufzubewahren.

Durch die Definition von bestimmten Sperrfristen (RETEXTRA, RETONLY) kann man diese inaktiven Objekte aus der Sicherung "herausaltern" lassen.

Abbildung 3 zeigt ein typisches Beispiel für die Sicherung von Client-Dateien im Verlauf einer Woche. Ein Client C, der jeden Abend gesichert wird, erzeugt am Montag eine Datei A und verändert diese täglich.

Abb. 3: Die Sicherung einer Client-Datei im Verlauf einer Woche.

Am Montag wird A in den Sicherungspool kopiert und dort als "active" markiert. Am Dienstag wird die geänderte Datei A1 gesichert und ihrerseits als "active" gekennzeichnet. Die vormals aktive Kopie wird damit inaktiv. Nach der Sicherung am Mittwoch ist die VEREXIST-Grenze erreicht und ab Donnerstag fallen alte Kopien aus der Sicherung heraus. Am Freitag wird die Datei auf dem Client gelöscht.

Beim nächsten Sicherungslauf wird die aktive Version inaktiv und alle Kopien > VERDELETED fallen aus der Sicherung heraus.

Sicherungspolitik

Der grundsätzliche Ablauf von Backup beziehungsweise Archivierung wird über Policies geregelt. Hier wird z. B. festgelegt, welcher Storage Pool benutzt wird, wie viele Versionen gehalten werden, nach wie vielen Tagen alte Versionen gelöscht werden sollen, etc.

Dazu existiert für jede der beiden oben genannten Grundfunktionen des TSM eine eigene Regelwerkgruppe, also eine "Backup Copy Group" (BCG) und eine "Archive Copy Group" (ACG).

Um einem Client genau definierte Regeln sowohl für Backup als auch für Archivierung zuzuschreiben, werden sogenannte Management Classes (MC) definiert, die die Definitionen der Copy Groups enthalten. Fehlt eine der beiden Copy Groups, kann der Client (über diese Management Classes) die entsprechende Funktion nicht wahrnehmen!

Um möglichst flexibel zu sein, lassen sich mehrere Management Classes parallel definieren und in einem "Policy Set" zusammenfassen.

Darüber hinaus lassen sich auch mehrere Policy Sets definieren. Jedoch ist immer nur eines davon aktiv und damit einsetzbar. So hat man die Möglichkeit, Policy Sets für den späteren Gebrauch vorzubereiten, sei es um komplett neue Regelwerke einzuführen, oder bestehende, bereits eingesetzte und damit bewährte, zu variieren. Durch diese Struktur wird ein einfaches und schnelles Wechseln des aktiven Policy Sets unterstützt.

Häufig ist die Systemlandschaft, die gesichert werden soll, nicht flach organisiert, sondern hierarchisch aufgebaut. Diese Hierarchie kann aufgrund von Kunden-, Plattform-, internen oder sonstigen Kriterien strukturiert sein. Um auch diese Strukturen im Sicherungskonzept abzubilden, existiert eine weitere, übergeordnete Organisationseinheit, die "Policy Domain" (PD) die die Policy Sets zusammenfasst (siehe Abbildung 4).

Abb. 4: Der Aufbau einer Policy Domain (ORDIX_PB).

Defaults nach der Installation

Nach der Installation von TSM sind je eine Default Policy Domain, ein Default Policy Set und eine Default Management Class inklusive Copy Groups vorbereitet. Mit diesen kann man zunächst erste Erfahrungen sammeln und sich mit der Arbeitsweise von TSM vertraut machen. Für einen praktischen Einsatz sind sie aber eher ungeeignet, deshalb muss für den Produktivbetrieb an dieser Stelle besondere Sorgfalt bei der Entwicklung eines auf die Gegebenheiten zugeschnittenen Konzeptes – Stichwort Service Level Agreement – und dessen Umsetzung aufgewendet werden!

Die Anforderungen eines Unternehmens an die Sicherung (und das Restore) können sehr vielfältig sein. Spielen wir an dieser Stelle ein Beispiel durch:

• Die File-Server sollen einmal pro Woche voll gesichert werden und täglich inkrementell. Es genügt eine Kopie der Backups.
• Die Web-Server sollen einmal pro Woche voll gesichert werden, wobei 3 Versionen gehalten werden.
• Von den Schulungsrechnern sollen Images erzeugt werden, die dann freitags für die kommende Woche neu aufgespielt werden sollen.
• Die sonstigen Clients (Notebooks) werden – wenn im Netz – einmal pro Woche voll gesichert.

Schauen wir uns die Vorgehensweise für den Aufbau einer Domain an einem einfachen Beispiel an.

Domains, Klassen, Gruppen ...

Es soll für ein Unternehmen für den Standort Paderborn eine Sicherungsdomain aufgebaut werden.

(1) Anlegen der Policy Domain auf der TSM-Server Konsole:
tsm: SERVER> def dom ORDIX_PB descr="Sicherung Paderborn"

Ohne weitere Angaben werden an folgenden Stellen Standardwerte für die Domain verwendet:

• Anzahl von Tagen, die eine Datei im TSM aufbewahrt wird, nachdem sie auf dem Client gelöscht wurde (Backup Retention).
• Aufbewahrungsfrist für Archiv-Kopien (Archive Retention).

Das Ergebnis dieser Aktion kann man sich im Browser ansehen oder per CLI verifizieren (siehe Abbildung 5 und 6).

Abb. 5: Die soeben angelegte Policy Domain, auf der TSM-Konsole betrachtet.

Abb. 6: Die fertige Backup Copy Group, im Browser betrachtet.

(2) Darin kann nun ein Policy Set erzeugt werden:
tsm: SERVER> def policyset ORDIX_PB File-Server descr="Schulung Verwaltung Web Ablage"

Verifizieren der Aktion auf der Kommandozeile:
tsm: SERVER> q pol ORDIX_PB f=d

(3) Nun muss noch (mindestens) eine Management Class eingerichtet werden:
tsm: SERVER> def mgmtcl ORDIX_PB File-Server Weekly_V3 descr="woechentliche Sicherung mit 3 Kopien"

Das Ergebnis an der Server-Konsole ansehen:
tsm: SERVER> q mgmt ORDIX_PB file-server

(4) Diese nimmt eine Copy Group vom Typ BACKUP auf:
tsm: SERVER> def copygroup ORDIX_PB file-server weekly_v3 type=backup verexists=3

(5) Anschließend sollte eine Copy Group vom Typ ARCHIV analog zu oben angelegt werden.

Die Struktur wird also von "außen" nach "innen" erzeugt. Alternativ kann man auch eine bestehende Domain kopieren und modifizieren.

Damit die neue Domain eingesetzt werden kann, müssen noch folgende Schritte durchgeführt werden (diesmal von "innen" nach "außen"):

(6) Eine Management Class muss als DEFAULT definiert werden (selbst wenn das Policy Set nur eine Management Class enthält):
tsm: SERVER> assign defmgmt ORDIX_PB file-server weekly_v3

(7) Eines der Policy Sets muss aktiviert werden, auch wenn die Policy Domain nur ein Policy Set enthält:
tsm: SERVER> act pol ORDIX_PB file-server

Dadurch wird eine Kopie des bestehenden Policy Sets mit dem Namen "aktiv" angelegt (siehe Abbildung 7).

Abb. 7: Abfrage auf die Policy "ORDIX_PB".

Client-Anbindung

Jeder Backup-Client ist in genau einer Policy Domain registriert. Diese wiederum enthält genau einen (aktiven) Policy Set. Damit stehen dem Client die darin enthaltenen Management Classes zur Verfügung. Implizit wird immer die Standard Copy Group verwendet. Um explizit eine Copy Group zu nutzen, muss diese in einer Include-/Exclude-Liste spezifiziert werden (s. u.).

Beim Archivieren gilt in dieser Beziehung grundsätzlich das gleiche, was für das Backup gesagt wurde. Zusätzlich besteht aber die Möglichkeit, durch die Kommandozeilenoption "archmc" bzw. über die GUI die Management Class anzugeben und damit sonstige Einstellungen zu übersteuern.

Ausnahmen bestätigen die Regel

Ist nichts weiter definiert, sind alle File Systeme des Clients zur Sicherung vorgesehen. Auf Client-Seite kann aber hier eine Vorauswahl getroffen werden. Dies geschieht in den Dateien dsm.sys bzw. dsm.opt (siehe Abbildung 8).

Abb. 8: Ein Auszug aus der Datei dsm.sys.

Nur die Dateisysteme, die nach dem Schlüsselwort DOMAIN aufgelistet sind, werden in die Sicherung einbezogen. Per Include-/Exclude-Listen können weitere Spezifizierungen vorgenommen werden.

Der Übersichtlichkeit halber kann alternativ mit einer INCLEXCL-Direktive auf eine Datei verwiesen werden, die Include-/Exclude-Informationen enthält (siehe Abbildung 9). Die Include-/ Exclude-Anweisungen beziehen sich immer auf einen Server.

Abb. 9: Auszug einer INCLEXCL-Datei.

Generell werden die Include-/Exclude-Listen von unten nach oben gelesen. Dadurch wird in dem Beispiel erreicht, dass nur die Dateien unter /home/kwp gesichert werden, die auf ".conf" enden (Zeile 3, 4).

Das Verzeichnis /oracle/product wird von der Sicherung des File Systems /oracle ausgenommen (Zeile 2). Außerdem können in Include-/Exclude-Listen die Standard Managementklassen übersteuert werden (Zeile 1). Werden Änderungen an den Listen durchgeführt, ist ein Neustart des TSM-Clients notwendig.

Die momentan aktiven Einstellungen kann man sich beim Client entweder per GUI (dsm) oder per CLI (dsmc) ansehen:
tsm> q incl

Für unterschiedliche Zwecke gibt es diverse Include-/Exclude-Typen. Abbildung 10 zeigt eine Auswahl der Exclude-Typen.

Abb. 10: Eine Auswahl von Exclude-Typen.

Zu beachten ist, dass *.fs- und *.dir- Einträge entgegen der oben genannten Regel zuerst ausgewertet werden, egal an welcher Stelle sie in der Liste auftauchen!

Natürlich können auch Wildcards in den Include-/Exclude-Listen verwendet werden. Einen Überblick über die erlaubten Sonderzeichen gibt Abbildung 11. Ihre Bedeutung entspricht im Wesentlichen denen der Unix-Shell.

Abb. 11: Die Wildcards der INCLEXL-Listen.

Zusätzlich kann aber das Symbol "/..." verwendet werden, um damit null oder mehr Unterverzeichnisse zu adressieren.

Der Einsatz von Wildcards macht nicht nur Sinn, um Dateien zu gruppieren, sondern häufig lässt sich dadurch die Include-/Exclude-Liste verkürzen, was der Sicherungsperformance und der Lesbarkeit zugute kommt.

Roger Niemeyer (info@ordix.de).