Wiederherstellung der Daten

Die Nutzung eines Datensicherungssystems wie etwa des LRZ-Archiv- und Backup-Systems lässt sich wie eine Risikolebensversicherung verstehen. Die regelmäßige Durchführung der Sicherungsläufe sowie die Kontrolle und Pflege der Backup-Software stellen sozusagen die von Ihnen zu zahlenden Versicherungsbeiträge dar und der Tag, an dem Sie verlorene Daten aus dem Backup-System wiederherstellen müssen, entspricht der Auszahlung der Versicherungssumme im Versicherungsfall. Im vorliegenden Artikel möchten wir Ihnen Informationen und Ratschläge geben, wie Sie im „Versicherungsfall“ möglichst schnell und ohne viel Aufregung an Ihre Daten kommen.

Wichtiger Hinweis

Bitte zögern Sie im Falle einer wichtigen Wiederherstellung von Daten nicht, umgehend den LRZ-Servicedesk zu verständigen. Wir setzen uns dann schnellstmöglich mit Ihnen in Verbindung und können Ihnen mit Tipps und Tricks zur Seite stehen und z.B. auch dafür sorgen, dass Ihnen Ressourcen bevorzugt zur Verfügung stehen.

Wie läuft eine Wiederherstellung von Daten, ein Restore, mit TSM ab und was ist dabei zu beachten?

Ausgehend von einem lauffähigen und korrekt konfigurierten TSM-Client gliedert sich ein Restore in der Regel in folgende Schritte:

  1. Sie wählen die Daten aus, die wiederhergestellt werden sollen und starten dann die Wiederherstellung.
  2. TSM durchsucht seine Datenbank nach den gewünschten Dateien und bringt diese in eine Reihenfolge, so dass möglichst wenig Bandwechsel beim Auslesen nötig sind.
  3. Der TSM-Server legt ein Backupband nach dem anderen in ein freies Bandlaufwerk ein, liest die gewünschten Dateien aus und sendet sie an den Client, welcher diese an die gewünschte Stelle auf Ihrem Rechner schreibt.

Schon bei der Auswahl der Daten, die wiederhergestellt werden sollen, gibt es einige Dinge, die beachtet werden müssen. Zuallererst sollten Sie sich vergegenwärtigen, dass Ihnen TSM – ohne weitere Angabe – nur die Dateien bzw. Dateiversionen anzeigt, die sich beim letzten Sicherungslauf noch auf Ihrem System befunden haben. In TSM-Jargon sind das die „aktiven Daten“. Wenn Sie außerdem die zum letzten Sicherungszeitpunkt bereits gelöschte Dateien bzw. ältere Versionen von Dateien angezeigt bekommen wollen, müssen Sie TSM explizit sagen, dass es auch die „inaktiven“ Daten anzeigen soll. Das machen Sie durch Auswahl des folgenden Symbols im Restore-Dialog des GUI bzw. durch die Angabe des Parameters –inactive beim query backup bzw. restore Kommando.

inactive

Über das sogenannte „Point In Time“-Restore können Sie einen Zeitpunkt in der Vergangenheit wählen und sich alle Dateien bzw. Dateiversionen anzeigen lassen, die zu diesem Zeitpunkt „aktiv“ waren. Bitte seien Sie sich aber bewusst, dass wir nach unseren Benutzungsrichtlinien „inaktive“ Daten nur für 180 Tage bzw. maximal 3 Versionen aufbewahren. Es werden Ihnen also nur die Daten für den Zeitpunkt angezeigt, die auch noch auf Basis dieser Richtlinien im Backup-System vorhanden sind.

Bei der Auswahl der zurückzuspielenden Daten gibt es einen weiteren Punkt zu beachten. TSM unterscheidet zwischen einem sogenannten „Standard Restore“ und einem „No Query Restore“. Auf den Unterschied zwischen den beiden Methoden wird weiter unten eingegangen. Um TSM dazu zu bringen, ein „No Query Restore“ auszuführen, muss folgendes gegeben sein:

  1. Es wird nur ein einziger kompletter Verzeichnisast ausgewählt
  2. Es werden keine weiteren Einschränkungen der wiederherzustellenden Dateien gemacht.
  3. Es werden keine inaktiven Dateien aus diesem Ast ausgewählt.

Auf Kommandozeilenebene führt die Angabe des folgenden Kommandos

restore /<Pfad>/<zu>/<Verzeichnis>/* <Ziel> -subdir=yes

zu einem „No Query Restore“ die zusätzliche Angabe von den Optionen inactive, latest, pick, fromdate, todate, volinformation, pit führt dazu, dass ein „Standard Restore“ ausgeführt wird.

In der GUI führt das Auswählen eines einzelnen Verzeichnisses auf der linken Seite, ohne vorher das Feld „Display Inactive Files“ ausgewählt zu haben und ohne irgendwelche Suchfilter über die „Lupe“ spezifiziert zu haben, zu einem „No Query Restore“. Alles andere führt zu einem „Standard Restore“.

Sobald Sie das Restore am Client gestartet haben, beginnt TSM mit der Wiederherstellungsprozedur. Je nachdem, ob ein „Standard Restore“ oder ein „No Query Restore“ durchgeführt wird, läuft dieses etwas unterschiedlich ab.

Im Falle eines „Standard Restores“ fragt der Client den Server nach einer Liste von allen vorhandenen Dateien des Dateisystems, das wiederhergestellt werden soll. Der Client durchsucht diese Liste nach den Dateien, die den angegebenen Suchkriterien entsprechen und bringt diese in eine Reihenfolge, so dass möglichst wenig Bandwechsel nötig sind. Der Client übergibt die Liste dem Server, welcher daraufhin die Dateien und Verzeichnisse in der angegebenen Reihenfolge von den Bändern liest und an den Client sendet.

Leider gibt es in vielen TSM-Client-Versionen einen Bug, der dazu führt, dass beim „Standard Restore“ zwar die Dateien in einer optimalen Reihenfolge abgerufen werden, aber leider nicht die Verzeichnisse. Das führt dazu, dass ein Restore unter Umständen sehr lange dauert, weil der Server ständig zwischen Bändern hin und her springen muss. Auf Client-Seite sieht das Ganze dann aus, als würde das Backup stundenlang „hängen“, weil TSM zuerst die Verzeichnisstruktur und dann die Dateien wie beim „Standard Restore“ wiederherstellt. Ob Sie von dem Problem betroffen sind, können Sie hier nachlesen. Der Fix steht voraussichtlich ab den TSM-Client-Versionen 6.3.3, 6.4.3 bzw. 7.1.1 zur Verfügung. Als Workaround sollten Sie, wann immer möglich ein „No Query Restore“ anstoßen, wenn Sie größere Verzeichnisstrukturen wiederherstellen möchten.

Im Falle eines „No Query Restores“ teilt der Client dem Server mit, für welchen Dateiast ein „No Query Restore“ durchgeführt werden soll. Der Server durchsucht daraufhin seine Datenbank nach den zu restaurierenden Dateien und Verzeichnissen und bringt diese in eine Reihenfolge, so dass möglichst wenig Bandwechsel nötig sind. Der Server liest die Daten von Band und sendet sie an den Client.

Bei großen Restores sollte möglichst einem „No Query Restore“ der Vorzug gegeben werden. Erstens braucht das „Standard Restore“ deutlich mehr Arbeitsspeicher, weil in diesem Fall die Liste der Dateien im Arbeitsspeicher des Clients verarbeitet wird und zweitens können Sie bei einem „No Query Restore“ von mehreren Bandlaufwerken parallel lesen (siehe Tuning-Tipps weiter unten).

Bitte beachten Sie auch, dass ungeachtet der Restore-Methode es in Abhängigkeit der Anzahl der gespeicherten und wiederherzustellenden Objekte einige Zeit dauern kann, bis die Liste der Daten aus der Datenbank gelesen und sortiert worden ist. Bei beispielsweise 25 Millionen zu restaurierenden Dateien kann dieser Vorgang mehrere Stunden dauern. In dieser Zeit kann der Eindruck entstehen, der TSM-Client habe sich aufgehängt. Dasselbe Phänomen kann dadurch ausgelöst werden, dass aktuell alle Bandlaufwerke belegt sind und der Server auf das nächste freie Laufwerk warten muss. Das Abbrechen des Restore-Jobs in dieser Phase ist kontraproduktiv, da beim nächsten Versuch wieder von vorne begonnen werden muss. Sollten Sie Zweifel haben, ob sich Ihr Client beim Restore-Vorgang aufgehängt hat, zögern Sie bitte nicht, vor einem Abbruch den LRZ-Servicedesk oder die LRZ-Hotline zu konsultieren. Wir können dann auf Serverseite den Status Ihres Restorevorgangs überprüfen und dafür sorgen, dass Ihnen Ressourcen/Bandlaufwerke bevorzugt zur Verfügung stehen.

Um die Wahrscheinlichkeit, dass ein großes Restore wegen eines bekannten Client-Problems abbricht, zu minimieren, empfehlen wir dringend, eine möglichst aktuelle TSM-Clientversion einzusetzen.

Sollte ein Backup abbrechen, so empfiehlt es sich beim Wiederaufsetzen, zuerst immer zu prüfen, ob ein sogenanntes „Restartable Restore“ noch auf dem Server vorliegt. Dazu wählen Sie in der GUI unter „Actions“ „Restartable Restores“ aus bzw.  nutzen query/restart restore auf der Kommandozeile. In diesem Fall kann der Client genau an der Stelle weitermachen, an der er zuvor abgebrochen ist.

Welche Möglichkeiten gibt es, ein großes Restore zu beschleunigen?

In gewissen Grenzen lässt sich das Wiederherstellen großer Datenmengen beschleunigen. In gewissen Grenzen bedeutet, dass wir auf die Dauer der Such- und Sortierphase der wiederherzustellenden Daten keinen direkten Einfluss haben. Hier lässt sich nur im Vorfeld bei der Planung des Backups durch eine Aufteilung in mehrere Nodes bzw. Filespaces eine Verbesserung erzielen. Dies lohnt sich aber erst bei Dateisystemen mit mehreren 10-Millionen Dateien. Der Hauptansatzpunkt bei der Performance-Optimierung liegt bei der Optimierung bzw. Parallelisierung der Datenübertragung.

Folgende Werte in den Konfigurationsdateien dsm.sys und dsm.opt haben sich in der Vergangenheit als oftmals vorteilhaft erwiesen:

TCPBUFFSIZE    512
DISKBUFFSIZE   1023
TCPNODELAY     YES

 Bis einschließlich TSM 6.1:

TXNBYTELIMIT   2097152

 Ab TSM 6.2:

TXNBYTELIMIT   20G

 Falls Ihr Betriebssystem „TCP Window Autotuning“ unterstützt:

TCPWINDOWSIZE 0

Als weitere Möglichkeit bietet sich an, bei einem „No Query Restore“ mehrere Bandlaufwerke parallel zu verwenden. Dies macht aber nur dann Sinn, wenn die Performance Ihrer Netzanbindung und Ihres Speichersystems entsprechend hohe Datenraten aufnehmen können. Als Faustformel kann man sagen, dass dies ab ca. 60 MB/s  von Vorteil sein kann. Um TSM die Möglichkeit zu geben ein „No Query Restore“ zu parallelisieren, müssen Sie in der dsm.opt bzw. dsm.sys die maximale Anzahl paralleler Sessions folgendermaßen angeben:

RESOURCEUTILIZATION <Anzahl paralleler Sessions 1-10>

Parallel dazu müssen Sie sich an uns über den Servicedesk oder die Hotline wenden, damit wir Ihren Node auf Serverseite für parallele Restores frei schalten. Am besten verweisen Sie darauf, dass Sie den Parameter MAXNUMMP für Ihren Node angepasst haben wollen. Der Wert für MAXNUMMP muss gleich dem RESOURCEUTILIZATION-Wert sein. Aus Gründen der Betriebssicherheit ist dieser per Default auf 1 gesetzt, damit ein fehlkonfigurierter Client nicht übermäßige Ressourcen belegen und damit u.U. das ganze System zum Erliegen bringen kann. Wird nur der RESOURCEUTILIZATION-Parameter höher 1 gesetzt, kommt es zu Fehlern während es Restores und damit zu einem nur partiell wiederhergestellten System. Bei berechtigtem Interesse können wir für einzelne Nodes die MAXNUMMP-Parameter auch anlassunabhängig dauerhaft auf einen Wert größer 1 setzten. Falls Sie das als nötig erachten, setzen Sie sich bitte mit dem Servicedesk in Verbindung.

Ich habe Probleme beim Restore – was kann ich tun?

Ein großer Systemausfall stellt häufig eine außergewöhnliche Stresssituation für Sie als Administrator dar. Neben dem Reparieren der Hardware und des Betriebssystems und der Beruhigung der Benutzer sind Sie auch noch mit dem Restore der Daten konfrontiert. Oft handelt es sich dabei um eine Aufgabe, über die sich manch einer noch nie Gedanken gemacht hat. Das Letzte, was Sie in dieser Situation gebrauchen können, sind Probleme beim Restore Ihrer Daten.

Die beste und einzige Möglichkeit, Probleme beim Restore im Vorfeld möglichst auszuschließen ist, den Restore-Fall regelmäßig zu testen. So können Probleme in einer nicht-kritischen Situation erkannt und behoben werden. Als zusätzlichen Bonus sind Sie mit der Prozedur für den Fall der Fälle schon vertraut und können das Restore entspannt angehen.

Uns ist bewusst, dass Ihnen aufgrund von anderen Prioritäten – leider – häufig die Zeit oder die nötigen Ressourcen für solche Maßnahmen fehlen werden. Allerdings erleben wir es auch jedes Jahr, dass sich Restores aufgrund von – im Vorfeld nicht erkannten – Problemen erheblich verzögern, weil dann erst mal nach dem Fehler gesucht werden muss, bevor der Restore erfolgreich abgeschlossen werden kann.

Bitte wenden Sie sich in so einem Fall sofort an uns. Oft und sofern entsprechende Ressourcen gerade verfügbar sind, führen wir den Restore dann erst einmal lokal bei uns am LRZ durch und stellen Ihnen die Daten per Netzwerk-Share oder ISCSI-Volume bereit, so dass Ihre Nutzer wieder Zugriff auf ihre Daten haben.