Tipp

Best Practices für Backups mit Tivoli Storage Manager von IBM

Was Sie in diesem Artikel erfahren können: Wir erläutern einige der Best Practices für Backups im Zusammenhang mit der Planung und Implementierung einer TSM-Backup-Umgebung.

Bei der Realisierung einer Backup-Umgebung mit Tivoli Storage Manager (TSM) gilt es eine ganze Reihe von Aspekten zu berücksichtigen. So müssen wie für die meisten Backup-Produkte grundlegende Anforderungen wie Netzwerk-Bandbreite, I/O-Performance, Durchsatz von Band-Laufwerken und ähnliches erfüllt werden. Darüber hinaus gibt es allerdings speziell bei der Verwendung von TSM noch einige weitere Anforderungen, die der Architektur des Produkts geschuldet sind. Im Folgenden finden Sie allgemein akzeptierte Best Practices zu den speziellen Kriterien für das Infrastruktur-Design sowie zur Implementierung von TSM.

Kapazität des Disk-Pools

Für die Bereitstellung von Backup-Daten und ihre spätere Migration auf Band kann Tivoli Storage Manager Festplatten-Storage-Pools verwenden. Dies bietet neben anderen Vorteilen die Möglichkeit für gleichzeitige Backup-Sessions, ohne hierfür eine große Anzahl von Band-Laufwerken zu benötigen. Zudem lassen sich auch Verfahren wie Daten-Interleaving oder Multiplexing auf Band einsetzen. Die Kapazität des bzw. der Disk-Pools muss groß genug sein, um zumindest die Menge der in einem nächtlichen Backup aufgelaufenen und an die Festplatten weitergeleiteten Daten zu speichern. Andernfalls könnte die Migration der Daten auf Band automatisch anstatt

    Kostenlose Registrierung notwendig

    • Um diesen Artikel vollständig zu lesen, melden Sie sich bitte kostenlos an. Falls Sie schon ein Mitlgied sind, loggen Sie sich einfach oben links auf der Webseite an.

      Mit dem Absenden bestätige ich, dass ich die Bedingungen und die Einverständniserklärung gelesen habe und diese akzeptiere.

nach Plan ausgelöst werden und so mit anderen Prozessen kollidieren.

Kapazität des Band-Subsystems

Die Kapazität des Band-Subsystems muss für die Speicherung aller Backup-Daten vor Ort ausgelegt sein. Bei nicht ausreichender Kapazität werden die vollen Bänder ausgeworfen, um so Platz für leere (Arbeits-)Bänder zu schaffen. Diese Vorgehensweise führt jedoch zu einem Konflikt mit der automatischen Daten-Verwaltung von Tivoli Storage Manager. Bei der Festlegung der Kapazität müssen Faktoren wie Backup-Daten vor Ort, Arbeitsbänder und steigende Datenvolumen einkalkuliert werden.

Ein weiteres Kriterium ist die Ausstattung der Band-Bibliothek mit einer ausreichenden Anzahl an Band-Laufwerken. Nur so lassen sich alle Anforderungen für direkte Backups auf Band, Daten-Migration, Storage-Pool-Backups für externe Standorte, Weiterverwertung von Bändern und Wiederherstellung eines beliebigen täglichen Zyklus erfüllen.

Storage-Pool-Kollokation

Mithilfe der Kollokation speichert Tivoli Storage Manager die Daten unterschiedlicher Systeme auf separaten Bändern (im Gegensatz zu Multiplexing). Allerdings kann die Kollokation bei der Sicherung kleinerer Systeme zu einer schlechten Auslastung der Medien führen. Dies wirkt sich auch spürbar auf die Kapazität der Bibliothek aus.

Änderungshäufigkeit und Aufbewahrung von Backup-Daten

Die Häufigkeit von Daten-Änderungen sowie die Dauer der Aufbewahrung von Backup-Daten sind wichtige Faktoren hinsichtlich der Kapazitätsplanung für TSM. Die Menge der täglich gesicherten Daten gibt die Anforderungen für Netzwerk-Kapazität, Server-Performance und Disk-Pools vor. Zudem ist sie auch ausschlaggebend für die Anzahl der erforderlichen Band-Laufwerke bei einem direkten Backup auf Band. Die Aufbewahrungsdauer von Backups wirkt sich zudem direkt auf die erforderliche Kapazität der Band-Bibliothek aus.

TSM-Datenbank und Protokolle

Die Datenbank von Tivoli Storage Manager muss mindestens einmal täglich gesichert werden. Im Idealfall erfolgt das Backup zweimal pro Tag, wobei eine Kopie des Backups an einen externen Standort übertragen wird und die andere vor Ort verbleibt, um eine schnelle Wiederherstellung zu ermöglichen. Bei aktivierter Roll-Forward-Protokollierung müssen stets Arbeitsbänder für Datenbank-Backups verfügbar sein. Nur so lässt sich das Erreichen der Kapazitätsgrenze von 13 Gigabyte und eines damit verbundenen Systemstopps durch TSM vermeiden.

Storage-Pool-Backups

Für alle primären Disk- und Band-Storage-Pools muss täglich eine Kopie erstellt und gesichert werden. Diese Bänder (und die Datenbank-Backups) sollten jeden Tag an einen externen Standort gebracht werden, um die langfristige Lagerung aller Backup-Daten an einem Standort auszuschließen.

Backup-Agenten für Anwendungen

Vermeiden Sie bei der Sicherung von Anwendungen wie MS SQL oder anderen Datenbanken die „Cowboy-Backup“-Methode. Dabei wird ein „Datenbank-Container“ erstellt und nach und nach gefüllt. TSM verfügt über Backup-Agenten für die Integration in Anwendungen, um Hot-Backups durchzuführen.

Planung

Zusätzlich zu den Client-Backups sollten auch alle TSM-Verwaltungsprozesse automatisiert werden. Verwenden Sie hierzu den zentralen Planer, um Fehler und Lücken im Backup zu vermeiden. Zu den Verwaltungsprozessen zählen unter anderem Ablauf-Fristen, Storage-Pool-Backups, Migration, Weiterverwertung und Datenbank-Backups, die jeweils in der richtigen Reihenfolge zu planen sind. Idealerweise handelt es sich beim letzten TSM-Prozess eines täglichen Zyklus um das Backup der TSM-Datenbank. Diesem sollte ein sofortiges Backup der History-Datei des Laufwerks folgen sowie die Erstellung der Disaster Recovery Manager (DRM)-Datei, um die Daten des aktuellen Systemzustands zu erfassen.

Disaster Recovery Manager

Für das DRM-Modul von Tivoli Storage Manager ist eine vollständige Konfiguration erforderlich sowie die sorgfältige Dokumentation und Pflege aller „Anweisungen“. Bei jeder Ausführung des Prozesses für die „TSM-Vorbereitung“ (am besten täglich) erstellt der DRM eine Datei mit einem Plan für die TSM-Wiederherstellung. In diesem finden sich alle TSM-Konfigurationsdaten sowie eine Liste der extern gelagerten Bänder und Laufwerke mit Datenbank-Backups. Im Falle eines Totalausfalls sind diese Informationen unerlässlich für die Wiederherstellung des TSM-Servers. Aus diesem Grund muss die Datei mit dem DRM-Plan zusammen mit einer Kopie der Storage-Pool-Bänder und dem Datenbank-Backup ebenfalls täglich an einen externen Standort weitergeleitet werden.

Weitere Informationen zur Architektur von Tivoli Storage Manager und den Konzepten finden Sie im IBM Tivoli Storage Management Concepts Redbook (SG24-4877).

Über den Autor: Pierre Dorion ist zertifizierter Experte für Business Continuity bei Mainland Information Systems.

Artikel wurde zuletzt im Februar 2007 aktualisiert

Ihre Meinung zum Artikel Kommentar

Teilen
Kommentare

    Ergebnisse

    Tragen Sie zu dem Gespräch bei

    Alle Felder sind erforderlich. Kommentare werden unterhalb des Artikels erscheinen.

    Haftungsausschluss: Unser Tipp-Austausch ist ein Forum, in welchem Sie technische Beratung und Fachkenntnisse mit Ihrem Peers teilen können, sowie auch von anderen IT-Profis lernen können. TechTarget bietet die Infrastruktur, um dieses Teilen von Informationen zu erleichtern. Wie auch immer, wir können nicht die Genauigkeit oder die Gültigkeit des vorgelegten Materials garantieren. Sie stimmen zu, dass Ihre Benutzung von dem „Fragen Sie den Experten“ Service, sowie auch Ihr Vertrauen von jeglichen Fragen, Antworten, Informationen oder anderen empfangenen Materialien von dieser Webseite auf Ihre eigenes Risiko läuft.