Eine Schritt-für-Schritt-Anleitung für Backup-Tests

Schritt 1: Festlegen, welche Backups Tests erfordern

Man könnte denken, dass jedes Backup Tests erfordert, aber das ist nicht immer durchführbar. Jedes individuell erzeugte Backup zu testen, würde ziemlich genau dem Durchführen eines unternehmensweiten Recovery entsprechen. Stattdessen sollte man jene Backups für einen Test auswählen, die so geschäftskritisch sind, dass sich der Aufwand für ein erfolgreiches Backup auf jeden Fall lohnt.

Mit den folgenden Methoden kann man bestimmen, welche Backups getestet werden sollten:

• Starten mit der Auswahl von Daten, Systemen, Anwendungen und komplexen Workloads. Wenn diese Teile der IT-Prozesse kritisch genug sind, eine kleine Recovery Time Objective zu haben, dann sind sie wichtig genug, dass ihre Backups getestet werden.
• Die Funktionsfähigkeit der Maßnahmen überprüfen. Kein Recovery ist vollständig ohne dass die Endanwender wirklich mit den wiederhergestellten Workloads verbunden sind. Man muss seine Einstellung zum Testen von Backups dahingehend ändern, dass die Endanwender und bestimmte Verifizierungsschritte darin eingeschlossen sind, damit die wiederhergestellten Workloads auch wirklich funktionieren.
• Abhängigkeiten prüfen. Es ist (fast) wahrscheinlich, dass keines der Workload-Backups unabhängig funktioniert. Sie brauchen andere Systeme, Dateien und Directory Services, um zu funktionieren. Dieser Aspekt erweitert die Sichtweise von Backup-Tests in Richtung Disaster Recovery (DR), weil man eventuell auch abhängige Workloads als Teil des Testprozesses wiederherstellen muss.

Schritt 2: Entscheiden, wie man Backups testen will

Im Allgemeinen gibt es verschiedene Arten von Backup-Tests, die Unternehmen benutzen, um ihre Backups zu bewerten. Je nach IT-Team, Erfahrung und Bedienungskomfort ist jede Testmethode besser, als überhaupt keine Tests durchzuführen.

Das Ziel ist es auf jeden Fall, die Datenintegrität des erzeugten Backups auf einfache Art zu überprüfen. Und dies wird durch den Einsatz von Produkten erreicht, die für das Überprüfen von Backups geeignet sind. Zu den möglichen Testaspekten gehören hier:

• Testen des Startvorgangs. In den Fällen, in denen Backups von kompletten virtuellen Maschinen (VMs) erzeugt werden, unterstützen viele Backup-Produkte die Fähigkeit, ein entsprechendes System wiederherzustellen und das korrekte Booting auf dem Logon-Screen von Windows zu verfolgen. Man kann diese Aufgabe auch manuell durchführen.
• Testen der Systemfunktionalität. Dieser Test führt die vorher genannte Methode ein paar Schritte weiter. Man überprüft, ob die Services starten: Ob das System auf Pings oder Interaktionen von Anwendungen reagiert (zum Beispiel durch Betätigen des TCP Port 25 auf dem Exchange-Server, um eine Antwort zu bekommen) oder ob sogar eine Intervention des Endanwenders möglich ist, die in einer vermuteten Systemantwort resultiert. Einige Backup-Produkte enthalten Orchestrierungsfähigkeiten, um diese Art von fortgeschrittenen Tests zu automatisieren.
• Testen des Recovery. Während dieser Parameter seine Wurzeln im Disaster Recovery (DR) hat, gibt es bewährte Testmethoden von Recovery-Plänen, die für Backup-Tests angewandt werden können. Diese schließen fiktive Übungen des Wiederherstellungsprozesses ein, indem Restore-Simulationen auf Basis von Plänen und realen Situationen möglichst detailgetreu durchgeführt werden. Auf diese Weise kann auch eine vollständige Restore-Simulation der kompletten Umgebung organisiert werden.

Schritt 3: Festlegen der Häufigkeit der Backup-Tests

Sobald man die Notwendigkeit eingesehen hat, Backups zu testen, wird dieser Schritt entweder sehr leicht oder etwas schwierig – je nachdem, ob man das Testen mit seinem Backup-Produkt automatisieren kann. Lässt man das für einen Moment beiseite, stellt sich die Frage „Wie oft soll man testen?“.

Die einfache Antwort hängt von der Besonderheit des Systems, der Anwendung oder des Workloads sowie von der Festlegung eines Test-Zeitplans ab, je nachdem wie wichtig es ist, das Backup auch wieder herstellen zu können.

Unsere Empfehlungen für die Häufigkeit von Backup-Tests sehen so aus:

• Statische Workloads. Wenn sich eine gegebene Kombination von Systemen, Anwendungen und Services nicht häufig ändert – mit Ausnahme der benutzten Daten –, ändern sich auch die Backups nicht. Dies bedeutet, dass jedes in einer Reihe von Backups womöglich in der Lage sein wird, das Restore dieses Backups in dem Fall zu übernehmen, wenn das letzte Backup-Set mangelhaft gewesen sein sollte. Falls man keine automatisierte Methode für das Testen von Backups eingerichtet hat, sollte man einen Backup-Test mindestens einmal pro Jahr durchführen. Wenn man Automatisierung einsetzen kann, sollte man eine häufigere Frequenz einrichten.
• Geschäftskritische Workloads. Manchmal tendieren sogar diese Workloads dazu, sich „statisch“ zu verhalten, weil sie sich oft nicht sehr ändern, außer es handelt sich um ihre Daten. Doch sollten hier allein wegen ihrer geschäftskritischen Beschaffenheit die Backups auf einer wesentlich häufigeren Basis getestet werden. Ohne Automatisierung sollten vierteljährliche Backup-Tests genügen. Bei Automatisierung machen häufigere Backup-Tests Sinn.
• Daten. Dies ist ein schwieriger Fall, denn der einzige Weg, den Wert von Daten, von denen ein Backup angelegt wurde, beweiskräftig zu testen, besteht in ihrer Anwendung. Deshalb wird Disaster Recovery hier so wichtig. In Fällen, in denen man Backups von Daten testen will, die in den Applikationen des Unternehmens verwendet wurden, wird man ein simulationsähnliches Backup durchführen müssen. Nur so wird man herausfinden, ob das Backup etwas taugt. Das Testen von Backups, die direkt mit Daten zu tun haben, sollte zusammen mit den Workloads erfolgen, für die sie eine Rolle spielen. Man sollte sich darüber im Klaren sein, dass die Überprüfung der Backups hier mehr Arbeit erfordern kann.