Automated Restore Testing

"Sichern ist nur die Hälfte der Arbeit"

Speicherverantwortliche wissen, dass nichts zählt ausser der Wiederherstellung
Alles andere, sei es das Korrigieren und Wiederanstoßen von abgebrochenen Sicherungen, Leistungsoptimierung oder auch Auswertungen bzw. Reports zählen nur insofern, als sie bei der Wiederherstellbarkeit ausgefallener Systeme einen Beitrag leisten. Viele sprechen davon, nicht ihren Arbeitsplatz in der Sicherung von Daten angesiedelt zu betrachten, sondern vielmehr in der Wiederherstellbarkeit ausgefallener Systeme und in der Wiederherstellbarket gelöschter Daten.
Aber das Testen der Wiederherstellbarkeit ist nicht einfach. Immer wieder wird es sogar unterlassen, denn:

&nb

• "Wo soll ich den mit 2000 Server- und Desktopsystemen das Testen beginnen?"
• "Wir haben genaue Regeln, was Änderungen an Systemen anbetrifft. Eine Datei auf ein Produktivsystem zu Testzwecken wiederherstellen? Das ist nicht machbar!“
• Ich müßte dann ja ein komplettes Reportingsystem schreiben… noch eines. Dazu habe ich gar nicht die Zeit"

ART macht Wiederherstellungstest einfach und unkompliziert:

• wird als appliance ausgeliefert, das erleichtert den Start
• entdeckt alle Client Nodes, es ist fast keine Implementierung von nöten.
• schreibt keine Änderungen auf die Backup-Clients, dadurch ist es der beste Weg, die Rücksicherung von Produktionsservern zu testen
• beeinflußt die Leistung des TSM-Servers nahezu nicht
• weist eine einfache und pragmatische Oberfläche mit allen wichtigen Informationen auf einen Blick auf
• erlaubt es sehr schnell und einfach auf Detailinformationen hinunterzubrechen – zum Beispiel ein ausgefallenes Volume oder ander Fehlerursachen
• ist bezahlbar – 3500 Dollar für 100 TSM-Nodes [größere Umgebungen auf Anfrage]

Zusatznutzen:

ART hat Hunderte von Kundenumgebungen getestet und unerwartete Punkte identifiziert, wie diese Teilauswahl exemplarisch aufzeigt:

• Bänder ausserhalb der Bandbibliothek: Bänder wurden für Maintenance aus der Library genommen, einige kamen nicht zurück, bis ART eines davon für den Restore benötigte. Die Administratoren haben dann das Problem für alle fehlenden Bänder korrigiert.
• TSM-Clients ohne Integration in ein TSM Backup-Schedule: ART zeigt auch Backup-Clients auf, die längere Zeit nicht gesichert wurden. Es gab Administratoren, denen plötzlich auffiel, dass TSM installiert war, ein manueller Backup erstellt wurde, aber nie ein automatischer Backup eingerichtet wurde.
• Verschwendeter Speicherplatz:   Ein Server wurde ausser Betrieb genommen, aber nach 90 Tagen war der Backupsatz immer noch in TSM. ART wies darauf hin, worauf eine genauere Untersuchung aller solcher Backup-Nodes eingeleitet wurde. Der Kunde konnte hinterher über vier Terabyte an Speicherplatz zurückgewinnen
• Inkostistente  Include / Exclude Definitionen: wenn “excludes” oder andere Einstellungen in der Client-Config-Datei dafür sorgen, dass komplette Filespaces bei der Sicherung ignoriert werden, zeigt ART es auf.  Bald wird auch ein Auditing der kompletten Exclude-results möglich sein.
• Langsame Wiederherstellung: Wenn eine Wiederherstellung einer Datei länger als zehn Minuten benötigt ist das für Nutzer definitiv unzumutbar. ART kennzeichnet diese TSM-Clients als Failure.
• Ungenügende Anzahl freier Bandlaufwerke: wenn ART herausfindet, das nicht genügend freie Laufwerke zur Verfügung stehen, belegt es die Daten mit einem “failed”-Kennzeichen. Wenn Nutzer versuchen würden, eine dieser Daten wieder herzustellen, würde es auch zu einem Fehler kommen. Hierdurch läßt sich ein Nachweis für eventuell zusätzlich benötigte Bandlaufwerke aufstellen.

volker.schlenker(at)bridge2.eu