IT Recovery News

In zehn Schritten zum erfolgreichen Business-Continuity- und Desaster-Recovery-Konzept

Ganz gleich, mit welchen Szenarios man seine Systeme und deren Betreuer auch testet: Wenn das oft zitierte „Disaster“ einmal zuschlägt, dann bestimmt so, wie es kein Mensch im Trockentraining vorausgesehen hat. Natürlich werden alle Applikationen, alle Server, alle Netzwerke und alle Speicher kontinuierlich von intelligenten Management-Tools überwacht; und diese schlagen Alarm, wenn gewisse Grenzen überschritten werden: Festplattenkapazität, Netzwerk-Bandbreite oder die Lebensdauer von USV-Akkus zum Beispiel. Natürlich lässt sich eine Reihe von Risiken messen und überwachen. Trotzdem: Ein effektives IT-Krisenmanagement verlangt sorgfältige Planung, genauso wie – in bestimmten Fällen – das Fachwissen eines kompetenten und erfahrenen System-Administrators und dessen ganz persönliche digitale Werkzeugkiste.

Gängige IS-Management-Methoden wie ITTL empfehlen, jede Änderung am System zu dokumentieren und regelmäßige Inspektionen und Tests durchzuführen. Dieses System setzt auf einen virtuellen Zyklus von Verbesserungen − ein Ansatz, der in den Qualitätszirkeln von Produktion und Dienstleistung hinreichend erprobt und getestet wurde, genauso wie in der physikalischen Zugangskontrolle. Effizient und vorhersehbar ist diese Herangehensweise – aber ein Plan für Business Continuity und Disaster Recovery muss Antworten auf eine ganze Reihe ganz und gar unvorhersehbarer Ereignisse parat haben. Denn von der IT hängen alle ab – vom Vorstandsmitglied bis zum Endanwender. Nur ein effektiver Disaster-Recovery-Plan gibt dem IS-Team die Möglichkeit, wirklich für die Wiederherstellung des Systems im vorgegebenen Zeitrahmen zu garantieren. Nur dieser Plan schafft das notwendige Vertrauen in die IT.
Die Tabelle auf dieser Seite zeigt die zehn Stufen, die letztlich zu einem effektiven Disaster-Recovery-Plan führen. Auf drei von Ihnen es sich genauer einzugehen:

Wenn größere organisatorische Veränderungen auftreten (Zeile 3 in der Tabelle), müssen alle geschäftskritischen Daten und Anwendungen einer Revision unterzogen werden. Dabei gilt es zu bewerten, welche Auswirkung welche Art von Unterbrechung auf das Business hat. Die Risiken müssen nach Schwere und Eintrittswahrscheinlichkeit geordnet werden. Nur auf der Basis dieser Informationen lassen sich Failover-Prozesse definieren – lässt sicher stellen, dass die kritischsten Server ganz oben auf der Prioritätsliste stehen.

Gibt es eine größere technische Veränderung (Zeile 7 in der Tabelle), ist es wichtig, dass die Infrastruktur sowohl des Produktiv- als auch des Backup-Standortes überprüft wird. Oft ist ein Update der Admin-Parameter erforderlich – damit das Failover im Bedarfsfall auch wirklich funktioniert. Hier ein Budget für Monitoring Tools einzuplanen, ist ein wichtiger Erfolgsfaktor, auch wenn Open-Source-Programme wie Nagios den Kostenaufwand verringern helfen. Große Unternehmen haben oft auch noch ältere Systeme und nutzen deswegen mehrere System-Management-Plattformen, die nebeneinander her laufen. Das kann gerade bei einem Failover zu Kompatibilitätsproblemen führen. Hier ist eine vollständige Replikation der kritischen Server oft die optimale Lösung.

Last but not least: Der gesamte Disaster-Recovery-Prozess muss gründlich getestet werden, indem man ein oder zweimal im Jahr einen Zwischenfall simuliert – einschließlich des (zeitweisen) Transfers der Operatoren und Administratoren an den Backup-Standort.

Automatisches Failover ist entscheidend

Die letzte Bestätigung erfährt der Disaster-Recovery-Plan erst in einem realistischen Test. Ein Netzwerkausfall, der zu einem „Split Brain“ führen würde, kann zum Beispiel durch das absichtliche Trennen der Verbindung zwischen Primär- und Sekundär-Server simuliert werden. Dann prüft man, ob keine Informationen verlogen gingen. Genauso wichtig: die Simulation eines Stromausfalls am Server. Dabei wird gemessen, wie schnell der Server und seine Applikationen nach einer vollständigen Unterbrechung der Energieversorgung wieder online sind. Ist ein automatisches Failover mit Full-Server-Replikation installiert, sollte das nicht länger als ein paar Minuten dauern – auch wenn es dem gestressten Administrator deutlich länger vorkommt. Wer hier nicht in die richtige Lösung investiert hat, sieht sich schnell mit einer Ausfallzeit von mehreren Stunden konfrontiert. So lange kann es dauern, bis die Backup-Server hochgefahren und die Daten-Backups zurückgeschrieben sind. Müssen gar mehrere Anwendungen neu initialisiert werden, kann sich die Downtime schnell auf einen zweiten Tag ausweiten.