.shock - Fotolia

Fünf vermeidbare Fehler beim Disaster-Recovery-Testplan

Vor dem Testen eines Disaster-Recovery-Plans sollte der Anwender prüfen, ob er fünf wichtige Fehler vermieden und weitere Details beachtet hat.

In einem Disaster-Recovery-Plan steckt oft viel Arbeitsaufwand. Zu den nötigen Schritten für einen DR-Plan gehören:

  • Das Test-Team bestimmen.
  • Sicherstellen, dass das Team am Tag des Tests verfügbar und vor Ort ist.
  • Zusätzliche Fachleute für diese Thematik bestimmen, wie beispielsweise Datenbankadministratoren und Netzwerkarchitekten.
  • Festlegen, was getestet werden soll und welche Resultate erwartet werden.

Während des stattfindenden DR-Tests muss der Plan einsatzbereit, die Testprozeduren dokumentiert und an alle Mitwirkenden verteilt sein. Zudem sollten alle System- und Netzwerkressourcen vorhanden sein und funktionieren. Trotz aller Vorbereitungen gibt es fünf Fehler, die bei der Planung und Umsetzung eines DR-Testplans unterlaufen können.

Fehler 1: Keinen DR-Testplan zu haben

Man benötigt einen dokumentierten Aktionsplan, der deutlich darlegt, welche Aktivitäten im Vorfeld des Tests durchzuführen sind, welche Testprozeduren eingehalten werden müssen und welche Aktionen nach dem Test notwendig sind. Darüber hinaus müssen Test-Skripte und die Mitglieder des Testteams im Plan enthalten sein. Dieser schriftlich hinterlegte Plan ist auch aus Audit-Perspektive wichtig, da es den Auditoren Aufschlüsse darüber gibt, wie der Test geplant und durchgeführt wurde.

Fehler 2: Die Technologie-Vertreter sind nicht verfügbar

Selbst wenn der Verantwortliche davon ausgeht, dass alle nötigen Mitarbeiter für den DR-Testplan festgelegt wurden, sollte er erneut abklären, ob wichtige Technologieexperten wie zum Beispiel der Systementwickler nicht vergessen wurden. Darüber hinaus müssen alle Technologieelemente sowie spezielle Implementierungen des wiederherzustellenden Systems durch entsprechende Mitarbeiter abgedeckt sein. Zu den Elementen gehören unter anderem das Netzwerk, die Hardware, Anwendungen, Datenbanken und Tools.

Fehler 3: Kein detailliertes Skript der Testaktivitäten anzulegen

Neben dem eigentlichen DR-Testplan ist dies eines der wichtigsten technischen Dokumente für den Test. Skripte sind die Vorlagen für die Durchführung von Tests und ihre Genauigkeit ist wichtig. Selbst ein Vertauschen von nur zwei Zeichen in einer Code-Zeile kann einen Systemfehler respektive einen Ausfall verursachen. Wenn möglich sollte ein Fachmann zur Verfügung stehen, der das Skript überprüft und nötige Änderungen vornimmt. Es empfiehlt sich ein Probelauf für den Test bevor man ihn live umsetzt.

Fehler 4: Testelemente fehlen oder sind nicht einsatzbereit

Da der Test für einen bestimmten Tag vorgesehen ist, sollten alle notwendigen Komponenten für den DR-Test vorhanden und einsatzbereit sein. Sollten Teile der Hard- oder Software oder des Netzwerkes nicht bereit stehen, so muss der Test abgesagt und verschoben werden, damit es zu keiner Unterbrechung des produktiven Systems kommt.

Fehler 5: Nicht abzuklären, ob andere Tests durchgeführt werden

In mittelständischen und großen IT-Abteilungen gibt es wahrscheinlich verschiedene zeitlich festgelegte Aktivitäten, wie zum Beispiel den Kompatibilitätstest eines neuen Systems, Netzwerk-Upgrades und Software-Updates. Das heißt der DR-Test muss zeitlich so abgestimmt sein, das er nicht mit anderen kollidiert. DR-Tests können oft Stunden dauern, also sollten sie soweit wie möglich im Voraus geplant werden. Dafür müssen zudem Benachrichtigungen eingerichtet werden, die das IT-Team an den geplanten Test erinnern.

Zusätzliche Faktoren für einen erfolgreichen DR-Testplan

Obwohl die fünf genannten Fehler unbedingt vermieden werden sollten, bevor der Plan getestet wird, gibt es noch zusätzlich drei Faktoren, die während und nach dem Test zu beachten und zu vermeiden sind.

1. Bei Problemen den Test nicht anhalten und neu aufsetzen. Wenn der Test nicht wie geplant verläuft, muss er angehalten werden. Dann muss der Verantwortliche prüfen, was bis zu dem Zeitpunkt passiert ist, bis der Test nicht mehr wie erwartet lief. Kann man das Störelement umgehen und den Test fortführen, dann kann man dem originalen Skript entsprechend weiter testen.

2. Den Test nicht dokumentieren. Dies umfasst das Aufzeichnen aller abgeschlossenen Testetappen und der Veränderungen die während des Tests vorgenommen wurden. Einer der wichtigsten Personen während des Tests ist derjenige, der ihn dokumentiert. Darüber hinaus sollte mit einem Zeitmesser Start- und Endzeit des Tests festgehalten werden.

3. Keinen Testreport anzulegen mit allen Erkenntnissen und Resultaten. Alle Aufzeichnungen sollten nach dem Test in einem Report zusammengefasst werden. Auditors wollen oftmals wissen, wie diese Tests durchgeführt wurden, welche Mitarbeiter daran beteiligt waren und wie auf spezifische Probleme reagiert wurde. Darüber hinaus sollte der Report festhalten, welche Infrastrukturkomponenten nicht funktionierten und welche Resultate erzielt wurden.

Falls Sie einen DR-Testplan haben und einen System- und/oder Technologie-Test durchführen, können Sie die Chancen auf einen erfolgreichen Test mit guten Vorbereitungen sowie ausführlicher Dokumentation erhöhen.

Folgen Sie SearchStorage.de auch auf Twitter, Google+ und Facebook!

Artikel wurde zuletzt im Dezember 2015 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Erfahren Sie mehr über Disaster Recovery

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchNetworking.de

SearchEnterpriseSoftware.de

SearchDataCenter.de

Close