IBM Tivoli Storage Manager TSM

IBM Tivoli Storage Manager TSM ermöglicht sowohl eine automatische, als auch eine manuell initiierte Datensicherung. Die Steuerung und Kommunikation mit dem Server erfolgt über den Backup/Archive Client. Bei einer manuell gestarteten Sicherung werden die Daten vom Client an den Server übermittelt. Ist die Sicherung automatisiert, initiiert der Server den Ablauf.
Die Antwort erfolgt in diesem Falle durch einen Dienst, der entsprechend konfiguriert werden muss.

In beiden Fällen speichert der Server die Daten in einem ersten Schritt auf einem Fest­platten­verbund (Disk2Disk). Erst in einem zweiten Schritt wird die Sicherung auf eine Tape Library übertragen und auf die Cartridges geschrieben. Alternativ oder zusätzlich können die Daten auch auf einen anderen Pool (Filepool mit Deduplizierung) gesichert werden. Bei einer inkrementellen progressiven Sicherung wird als erstes eine komplette Sicherung aller Daten erstellt. Die darauf folgenden Backups umfassen dann nicht mehr alle Daten, sondern nur all jene, die in der Zwischenzeit verändert oder neu erstellt wurden.

Jede Datei wird als selbständiges Objekt auf dem TSM Server verwaltet. Somit ist es möglich, bei jeder Datensicherung nur die Veränderungen am Dateisystem des Client-Systems auf den TSM- Server zu übertragen. Tivoli Storage Manager erhält auch die Information, welche Dateien seit der letzten Datensicherung gelöscht wurden. Der TSM-Server benutzt die Informationen, die bei der inkrementellen Datensicherung übertragen werden, um den Status der Sicherungs­kopien zu aktualisieren. Wird beispielsweise eine Datei als gelöscht erkannt, wird sie ab diesem Zeitpunkt noch für eine voreingestellte Zeit (als inaktive Version) aufgehoben.

Für die Steuerung, welche Versionen einer Datei wie lange aufgehoben wird, ist auf dem Server eine Richtlinie konfiguriert: Die Daten durchlaufen drei verschiedene Zustände, diese werden durch eine Kombination von vier Parametern definiert. Dabei wird zwischen existierenden und gelöschten Dateien unterschieden.

  • Anzahl gehaltene Versionen der auf dem Client existierendenden Dateien (5)
  • Anzahl Tage, die eine auf dem Backup als inaktiv definierte Datei gehalten wird (33)
  • Anzahl gehaltene Versionen der auf dem Client gelöschten Dateien (1)
  • Anzahl Tage, die die aktuellste gesicherte Datei, die auf dem Client nicht mehr existiert, gehalten wird (95)

tiri GmbH empfiehlt als Basis mit o.a. Werten zu beginnen. Es ergeben sich damit folgende Auswirkungen.

  • aktiv: Es werden 5 Kopien jeder gesicherten Datei vorgehalten, die auf dem Client existiert. Davon wird die aktuellste als „aktiv“ definiert. Die anderen Versionen werden „inaktiv“ und je 33 Tage gehalten.
  • inaktiv: Daten im Status „inaktiv“ bleiben 33 Tage erhalten. Nach Ablauf der 33 Tage wechselt der Status zu „expired“.
  • expired: Diese Daten sind zum Überschreiben freigegeben und werden durch eine sog. "Space Reclamation" von den Pools entfernt.
Ab dem Zeitpunkt, an dem eine Datei auf dem Client gelöscht wird, existiert sie in der letzten gesicherten Version noch 95 Tage auf dem Server. Danach wechselt auch ihr Status auf „expired“.

Links