The TSM Way of Backup

Benutzer, die von traditionellen Backup-Methoden auf das TSM-Backup umsteigen, sind nicht selten verwirrt von dem Ansatz, den TSM im Hinblick auf Backup verfolgt. In diesem Artikel beleuchten wir die TSM-Backup-Funktion und deren Unterschiede zu traditionellen Backup-Methoden.

In der Welt der Datensicherung existieren im Kern genau drei verschiedene Möglichkeiten, eine Sicherung, d.h. ein Backup eines Datenbereichs zu erstellen. Der einfachste Fall und auch immer die Basis für die beiden anderen, nennen wir sie Backup-Typen, ist das sogenannte Full-Backup. Das ist nichts anderes als eine vollständige Kopie des zu sichernden Datenbereichs auf einen anderen Daten­träger. Der zweite Backup-Typ ist das sogenannte Differential-Backup. Hier werden nur die Änderungen zum letzten Full-Backup auf einen anderen Daten­träger kopiert. Der dritte Backup-Typ ist das sogenannte Incremental-Backup. Hier werden nur die Änderungen zum letzten Backup, unabhängig davon, ob dieser ein Full oder ein Incremental war, auf einen anderen Datenträger kopiert.

Betrachtet man die Backup-Typen im Hinblick auf die Tatsache, dass Daten­sicherung traditionell auf Magnetbänder gemacht wird, ergeben sich einige Vor- und Nachteile, die wir im folgenden skizzieren wollen.

Beim Full-Backup ist der gravierende Nachteil, dass jedes Mal der komplette Datenbestand kopiert werden muss, was eine hohe Belastung der System­ressourcen bedeutet. Ferner ist jedes Full-Backup prinzipbedingt unabhängig von allen vorherigen Backups. Wenn sich also eine Datei zum letzten Backup nicht verändert hat, wird diese trotzdem erneut gespeichert. Dies bedeutet also Verschwendung von Speicherplatz. Der Vorteil eines Full-Backup liegt jedoch darin, dass für ein Zurückspielen der Daten, d.h. ein Restore, nur ein einziges Backup zurückzukopieren ist. Dadurch ist ein Full-Backup häufig die schnellste Lösung für eine Wiederherstellung.

Beim Differential-Backup werden die Unterschiede zum letzten Full-Backup mit jedem Tag größer, so dass man jeden Tag mehr Daten auf das Backup-Medium übertragen muss, auch wenn sie sich zum letzten Differential-Backup nicht geändert haben. Man sollte also in regelmäßigen Abständen ein neues Full-Backup erstellen, auf das dann weitere Differential-Backups aufsetzen können. Im Vergleich ist diese Methode deutlich ressourcenschonender im Hinblick auf die täglich zu kopierenden Daten und natürlich auf die zu speichernde Gesamtmenge der Backup-Daten. Allerdings wird immer noch mehr Speicher­platz als eigentlich nötig verbraucht, da weiterhin Redundanzen zwischen den Differential-Backups bestehen. Im Restore-Fall wird bei einem Differential-Backup zuerst das letzte Full-Backup zurückgespielt und dann das letzte Differential-Backup darüber kopiert. Es sind also zwei Schritte nötig.

Die Incremental-Backup ist hinsichtlich der zu übertragenden und zu speichernden Datenmenge optimal, da nur die Änderungen gegenüber der letzten Sicherung aufgezeichnet werden müssen, unabhängig davon, ob es sich um eine vollständige oder inkrementelle Sicherung handelt. Das große Problem zeigt sich jedoch im Restorefall. Wenn man keine zusätzlichen Informationen hat, wie TSM sie zusätzlich speichert, muss man zuerst die letzte Full-Backup einspielen und dann sämtliche seit diesem Zeitpunkt erstellte Incremental-Backups. Es sind also in der Regel soviele Schritte nötig, wie Incremental-Backups seit dem letzten Full-Backup erstellt wurden.

Ausgehend von den oben beschriebenen Backuptypen, lassen sich nun unendlich viele Backup-Strategien entwickeln. Eine der am geläufigsten Strategien ist das sog. Großvater-Vater-Sohn-Prinzip. Um dieses umzusetzen, benötigt man bei einer Fünf-Tage-Woche und einer Aufbewahrungszeit von 6 Monaten die folgende Anzahl Medien:

  • 4 Sohn-Medien (Montag-Donnerstag)
  • 4 Vater-Medien (Freitag)
  • 6 Großvater-Medien (letzter Tag im Monat)

Mittels dieser Strategie kann man auf die Datenstände der letzten vier Tage, der letzten vier Freitage und der letzten 6 Monatsenden zugreifen. Dafür benötigt man aber mindestens 14 Bänder, auch wenn die jeweiligen Sicherungen viel kleiner sind als die Bandkapazität.

Die Backup-Strategie von TSM unterscheidet sich fundamental von den traditionellen Backup-Strategien. Ziel war es, Backups im Hinblick auf den Ressourcenverbrauch so effizient wie möglich zu machen und dabei trotzdem ein praktikables Restore-Verfahren bereitzustellen. Das ist den TSM-Entwicklern dadurch gelungen, dass sie das Incremental-Backup-Verfahren mit zusätzlichen Metadaten angereichert haben und dadurch eine sog. Progressive-Incremental Backup-Strategie realisieren konnten. Die Metadaten werden in einer DB2-Datenbank gespeichert. Bei der Progressive-Incremental-Strategie werden nur Incremental-Backups gemacht. Nur ist der erste Backup-Lauf quasi ein Full-Backup. In den Metadaten wird aber zusätzlich gespeichert, wo auf welchem Band sich welche Version einer Datei befindet. Die einzelnen Backups eines Rechners werden einfach hintereinander auf ein Band geschrieben, bis es voll ist und dann wird das nächste Band verwendet. Somit ist es auch für die Kapazitäts­aus­lastung der einzelnen Bänder optimal. Im Restore-Fall sucht TSM aus den Metadaten die jeweils benötigten Versionen der Daten heraus, sortiert diese so, dass möglichst wenig Bandwechsel und Positionierungsoperationen ausgeführt werden müssen und erzeugt daraus quasi ein synthetisches Full-Backup von dem vom Benutzer gewünschten Zeitpunkt, das dann an den Client gesendet wird.

Leider ist es aber auch mit der Progressive-Incremental-Strategien in der Praxis oft nicht möglich, einfach alle Versionen einer Datei für unbegrenzte Zeit aufzubewahren, da die Kosten für den Speicherplatz unverhältnismäßig hoch zum Nutzen wären. Deshalb bietet TSM die Möglichkeit, Aufbewahrungs­richt­linien im Hinblick auf die Aufbewahrungszeit und der Anzahl an aufbewahrten Versionen einer Datei zu definieren.

Um den Mechanismus dieser Aufbewahrungsrichtlinien zu verstehen, ist das Konzept der aktiven und inaktiven Daten essentiell. Für TSM ist jede Sicherungskopie einer sich noch auf dem Quellsystem befindlichen Version einer Datei eine aktive Version. Aktive Daten werden in TSM nie gelöscht. Damit ist gewährleistet, dass nach einem Datenverlust der Stand der Daten zum letzten Backup-Lauf komplett wiederhergestellt werden kann. Wird eine Datei auf dem Quellsystem gelöscht oder durch eine neue Version ersetzt, so wird bein nächsten Backuplauf die vorher aktive Sicherungskopie von TSM als inaktiv markiert. Bei Überschreiben der Datei wird die neue Version von nun an als aktive Sicherungskopie geführt. Ab dem Zeitpunkt, ab dem eine Sicherungskopie einer Datei als inaktiv markiert wird, unterliegt sie den Aufbewahrungsrichtlinien. Das bedeutet, sie wird ab diesem Zeitpunkt maximal so lange aufbewahrt, wie die Aufbewahrungszeit in der Richtlinie definiert ist, oder bis es mehr aktuellere, Versionen dieser Datei gibt, als es die Aufbewahrungsrichtlinie für die maximale Anzahl an Versionen zulässt.

Die LRZ-Standard-Aufbewahrungsrichtlinien arbeiten mit einer maximalen Aufbewahrungsdauer von 180 Tagen von maximal 3 inaktiven Versionen. Über die dedizierte Auswahl der sogenannten Managementklasse für einzelne Dateien und Verzeichnisse bieten wir zusätzlich die Möglichkeit, maximal 10 inaktive Versionen aufzubewahren. Diese Vorgaben stellen nach unserer Erfahrung einen guten Kompromiss zwischen den Kosten für die Aufbewahrung der Backups einerseits und den Vorteilen im Hinblick auf die Chance, dass Daten nach einem Datenverlust noch im Backup gefunden werden können, andererseits dar.

Vergleicht man nun die traditionelle Generationenstrategie mit der Progressive-Incremental-Strategie des LRZs ergeben sich für beide Verfahren unterschied­liche Vor- und Nachteile.

Pro Progressive-Incremental-Strategie:

  • geringerer Speicherplatzverbrauch
  • bessere Speicherplatzausnutzung
  • geringerer Ressourcenbedarf für Backup
  • geringere Kosten
  • Jede gelöschte Datei kann 180 Tage lang in ihrer letzten Version restauriert werden.
  • Es werden die letzten 3 bzw. 10 Versionen einer Datei aufgehoben.

Contra Progressive-Incremental-Strategie:

  • Metadaten-Datenbank nötig
  • Alte Versionen einer Datei altern früher als 180 Tage heraus, wenn die maximale Anzahl der Versionen erreicht ist.
  • höherer Aufwand beim Restore

Pro Generationenstrategie:

  • keine Metadaten-Datenbank nötig
  • geringerer Aufwand beim Restore
  • Sofern eine Datei zum Zeitpunkt der Monatssicherung existiert, lässt sich diese garantiert auch nach 180 Tagen noch restaurieren, und zwar unabhängig von der Anzahl der Versionen, die es von dieser Datei gegeben hat.

Contra Generationenstrategie:

  • höherer Speicherplatzverbrauch
  • schlechtere Speicherplatzausnutzung
  • höherer Ressourcenbedarf für Backup
  • höhere Kosten
  • Schon länger gelöschte Dateien können u.U. nicht in der letzten Version restauriert werden, weil nur noch Wochen- bzw. Monats-Backups existieren.
  • Es werden nicht die letzten 3 oder 10 Versionen einer Datei aufbewahrt, sondern nur der Stand der Datei zu den Backup-Zeitpunkten.
  • Dateien, die z.B. nur zwischen zwei Monatssicherungen oder zwei Wochensicherungen existiert haben, können nicht restauriert werden.

Für Daten, die längerfristig aufbewahrt werden müssen, bietet TSM die sog. Archivierungsfunktion. Mir ihr können Sie Daten standardmäßig für 10 Jahre in TSM aufbewahren. Auf Anfrage bieten wir auch die Möglichkeit, Archivdaten ohne Verfallsdatum zu speichern. Allerdings ist zu beachten, dass die Archivfunktion nicht im Progressive-Incremental-Modus arbeitet, sondern einem Full-Backup entspricht. D.h. wenn ein und dieselbe Version einer Datei 100 Mal archiviert wird, wird diese auch 100 Mal in TSM gespeichert. Da dies natürlich eine Verschwendung von Speicherressourcen und damit am Ende von Steuergeldern ist, gilt es, bei der Auswahl von zu archivierenden Dateien extreme Sorgfalt walten zu lassen. Wir beobachten z.B. immer wieder, dass Benutzer wohl aus Gründen der Bequemlichkeit in regelmäßigen Abständen ihr gesamtes Dateisystem archivieren. Das ist natürlich nicht im Sinne des Erfinders und führt zu massiven technischen Problemen beim Zurückholen der Daten und ist nicht zuletzt unfair gegenüber denjenigen Benutzern, die sich Gedanken darüber machen, welche Daten archivierungs­würdig sind und welche nicht.

Auf weitere semantische Unterschiede, die verschiedenen Einsatzbereiche der TSM-Backup- und Archiv-Funktionen und welche Anforderungen wie mit diesen Funktionen erfüllt werden können, werden wir in einem weiteren Artikel näher eingehen.