20090910e Opitz Consulting Disaster Recovery Business Continuity Lösungen

»manage it« als

E-Paper 5-6 2011
E-Paper 3-4 2011
E-Paper 1-2 2011
E-Paper 11-12 2010
E-Paper 9-10 2010
E-Paper 7-8 2010
E-Paper 5-6 2010

Disaster Recovery im Datenbankumfeld

Einordnung in die Business-Continuity-Lösungsansätze

Katastrophen – unabhängig davon, ob sie menschlichen oder natürlichen Ursprungs sind – können ein Unternehmen jederzeit treffen. Telekommunikationskabel, die vom Bagger des Straßenausbesserungsdienstes durchtrennt werden, Überflutungen oder Kabelschmorbrände, die ganze Rechenzentren außer Betrieb setzen … Der Totalausfall von IT-Komponenten ist jederzeit denkbar und jederzeit möglich!

tudien namhafter Analysten wie Gartner u. a. zeigen, dass viele Unternehmen den Totalausfall geschäftskritischer IT-Prozesse über einen längeren Zeitraum hinweg nicht verkraften und in der Folge ihr Geschäft aufgeben müssen.

Doch auch, wenn ein IT-K-Fall nicht zwangsläufig zu einem Gesamt-K-Fall eines Unternehmens führt, ist der Totalausfall auch nur eines kritischen Prozesses in der Regel mit hohen Folgekosten verbunden, was nicht zuletzt an der stetig wachsenden Komplexität und Verzahnung von Betriebsprozessen liegt. Dass Unternehmensnetze und damit die angeschlossenen Prozesse empfindlich gestört werden können, hat sich mittlerweile in den meisten Betrieben herumgesprochen. Firewall-Systeme, aufwendige hochautomatisierte Update-Systeme und komplexe Antivirenprogramme gehören heute zum Standardprogramm EDV-gestützter Betriebe. Die Notwendigkeit solcher Sicherheitsmaßnahmen muss heute kein Administrator gegenüber seinem Vorgesetzten mehr rechtfertigen.

Im K-Fall können unscheinbare Kleinigkeiten die Kosten einer Wiederherstellung explosionsartig in die Höhe treiben, wie etwa:

· nicht notierte Kennwörter

· fehlerhafte oder gänzlich fehlende Dokumentation der Sicherungs- und Wiederherstellungsprozeduren

· nicht lesbare Sicherungsbänder

· verlorengegangene Lizenzschlüssel, die für die Softwareinstallation benötigt werden

· nicht vorhandener Ersatz von (veralteten) Hardwarekomponenten

Nicht selten ist die falsche Strategie zur Sicherung und Wiederherstellung die Ursache für eine finanzielle Folgekatastrophe: Wenn ein Unternehmen durch die Unterbrechung eines kritischen Prozesses in der Stunde mehrere hunderttausend Euro Verlust schreibt, kann im schlimmsten Fall ein Wiederherstellungsverfahren, das mehrere Stunden oder gar Tage dauert, die tatsächliche Ursache einer Betriebsaufgabe sein, und nicht die Komponente, die den Ausfall ursprünglich ausgelöst hat.

Business Continuity versus Disaster Recovery

Betriebliches Kontinuitätsmanagement (engl. Business Continuity Management, BCM) erhielt in den 1950er Jahren Einzug in die Betriebswirtschaftslehre und bekam seit den Anschlägen vom 11. September 2001 und den Bombenattentaten in London und Madrid neuen Aufschwung. BCM beschreibt Methoden, die es einem Unternehmen erlauben, den betrieblichen Prozess unter Krisenbedingungen und unvorhersehbar erschwerten Bedingungen abzusichern und somit den Fortbestand eines Unternehmens zu gewährleisten.

Für die erfolgreiche Entwicklung eines BCM-Programms ist es notwendig, das Unternehmen sehr genau zu analysieren hinsichtlich

· der Unternehmensziele,

· des Wegs, auf dem diese Ziele erreicht werden sollen,

· der tatsächlich erbrachten Produkte und Leistungen

· sowie der Art und Weise, wie diese Leistungen zu erbringen sind.

Die aus dieser Analyse gewonnenen Erkenntnisse werden einer Business-Impact-Analyse (BIA) unterzogen. Die BIA bietet somit eine Grundlage, um die Folgen von Verlust beziehungsweise Störung betrieblicher Prozesse zu bestimmen und zu qualifizieren.

Maximum Tolerable Period of Disruption (MTPD)

Die MTPD beschreibt die maximal akzeptable Zeit, die eine Betriebsunterbrechung dauern darf. Sie sollte von der Geschäftsleitung festgelegt werden und muss als absoluter Basiswert für alle weiteren Maßnahmen zur Planung von Verfahrensweisen im Katastrophenfall gelten. Zur Bestimmung der MTPD stehen zwei weitere Richtlinien zur Verfügung:

Recovery Time Objective (RTO):

Die RTO legt die Zeit fest, in der ein bestimmter Betriebsablauf nach Schadenseintritt wieder vollständig funktionieren muss. Eine Festlegung von »0 Minuten« bedeutet, dass Systeme sofort verfügbar sein müssen.

Recovery Point Objective (RPO:)

RPO beschreibt den Wiederherstellungszeitpunkt für eine Information, die erforderlich ist, um einen Prozess wieder starten zu können. Hierbei wird festgelegt, wie viele Daten zwischen der letzten Sicherung und dem Schadenseintritt maximal verloren gehen dürfen. Eine »RPO = 0« bedeutet, dass Datenverlust nicht akzeptabel ist.

Disaster Recovery Management (DRM)

DRM ist prinzipiell gleichbedeutend mit Business Continuity Management (BCM), wird aber begrifflich verwendet für die Anwendung von BCM auf die IT-Infrastruktur eines Unternehmens. Aus Unternehmenssicht ist DRM daher keine vom Gesamtbetrieb losgelöste IT-Strategie, sondern integraler Bestandteil des betrieblichen Gesamtkonzepts. »Disaster« meint dabei in der Regel den Totalausfall einer IT-Komponente, die für die Bereitstellung eines IT-Services als Bestandteil eines kritischen Betriebsprozesses verantwortlich ist. Der Ausfall einer gespiegelten Festplatte (RAID 1) ist demnach kein Disaster-Recovery-Fall, da alle Informationen identisch auf beide Platten geschrieben werden. Dagegen ist der Ausfall einer Festplatte, die mit einer weiteren Festplatte zu einer logischen Einheit mit der Gesamtgröße beider Platten zusammen betrieben wird (RAID 0), ein DR-Fall, weil bei RAID 0 die Informationen getrennt und zu gleichen Teilen auf beide Platten verteilt werden. Ein Plattenausfall aller im RAID 0 zusammengefasster Platten ist daher gleichbedeutend mit dem Ausfall beider Platten und damit gleichbedeutend mit einem totalen Datenverlust.

Auf dem Weg zu DRM

Disaster Recovery ist kein Selbstläufer. Im K-Fall ist ein funktionierender DR-Plan die allerwichtigste Komponente der bestehenden IT-Sicherheitsstrategie. Katastrophen treten im Allgemeinen völlig unerwartet ein und schaffen unmittelbar brenzlige Situationen für alle Betroffenen. Es bedarf bei allen Beteiligten großer Ruhe und äußerster Sorgfalt, um die richtigen Schritte zum richtigen Zeitpunkt am richtigen Ort durchführen zu können. Wer untrainiert in eine derartige Lage gerät, kann schnell in Hektik verfallen und dabei Fehler begehen, die ein Recovery erschweren oder gar unmöglich machen können. Ein funktionierender DR-Plan stellt daher unter Umständen den entscheidenden Faktor für den Erhalt oder den Verlust eines Unternehmens dar.

Der erste Schritt zu einem erfolgreichen DR-Plan besteht darin, bei allen Beteiligten ein ausgeprägtes gemeinsames Verständnis für die Notwendigkeit des Plans und seiner Ausprägung zu schaffen. Nur wenn alle Prozesse richtig erfasst und alle Maßnahmen logisch aufeinander abgestimmt sind und diese Schritte für die Beteiligten verständlich und auch in hektischen Stresssituationen zielgerichtet ausführbar sind, ist es möglich, Disaster Recovery effizient und erfolgreich umzusetzen. Das bedeutet, dass alle Maßnahmen und einzuleitenden Schritte ebenso wie die betroffenen Prozesse vollständig und detailliert dargelegt werden müssen. Und es bedeutet, das »Mantra« jeder Sicherheitsstrategie zu verinnerlichen und konsequent zu leben: Prüfen. Testen. Anpassen. Testen. Prüfen. Testen ...

Disaster Recovery als iterativer Prozess

Analysephase

Zunächst geht es darum, die als kritisch anzusehenden Prozesse zu identifizieren. Es ist empfehlenswert, hierbei vom Gesamtprozess ausgehend kleine Assets zu bilden und diese nach ihrer Priorität und ihrer eventuellen Abhängigkeit untereinander zu gewichten. Die Analyse sollte sich dann auf die herausgehobenen Prozesse konzentrieren und diese einer strengen Risikobewertung unterziehen. Die Ergebnisse dieser Bewertung werden in Form von Recovery Time Objective (RTO) und Recovery Point Objective (RPO) maßgebend für alle weiteren Phasen sein. Diesem Schritt fällt daher strategische Bedeutung zu. Hilfreich ist es, die Risiken in Form potenzieller Katastrophenszenarien und bestehender Alternativen zu beleuchten. Solche Szenarien machen es möglich, bislang unerkannte Schwachstellen kritischer Prozesse zu entdecken; sie helfen aber auch, das tatsächliche Gefährdungspotenzial realistisch einschätzen zu können. Dass alle Ergebnisse nachvollziehbar und ausführlich dokumentiert werden, sollte selbstverständlich sein.

Designphase

Liegen die Ergebnisse der Analysephase vor, müssen im nächsten Schritt für jeden kritisch eingestuften Prozess konkrete Maßnahmen aus den Festlegungen für RPO und RTO abgeleitet und spezifiziert werden. Auch hier gilt es wieder, mögliche Abhängigkeiten der jeweiligen Schritte zu betrachten und ggf. erneut zur Analysephase zurückzukehren. Das Vorgehen sollte dabei vom Großen zum Kleinen führen: Zunächst sollte eine Unterteilung in Themenbereiche wie »Daten«, »Services«, »Kommunikation« erfolgen und im Anschluss daran eine Untergliederung in verfeinerte Unterthemen. Auch hier ist es wichtig, möglichst alle Aspekte zu erfassen, also auch Teilaspekte wie Stromversorgung, Telekommunikation oder Zugangsberechtigungen nicht unberücksichtigt zu lassen. Ein wichtiger Teilschritt in der Designphase ist die Erstellung von Testplänen, mit denen die Maßnahmen später zu prüfen sind. Es empfiehlt sich, Testpläne möglichst strikt und eindeutig zu fassen –, ohne Raum für Interpretationen. Am besten sollten die erwarteten Testergebnisse bereits in die Pläne aufgenommen werden, so dass im Test später nur noch auf eventuelle Abweichungen hin geprüft werden muss.

Implementierungsphase

In der Implementierungsphase geht es darum, die Maßnahmen, die in der Designphase festgelegt wurden, konkret umzusetzen und die technischen Gegebenheiten zu schaffen, die im DR-Plan spezifiziert wurden. Dies ist zugleich ein wichtiger erster Test für die erstellten Pläne, bei dem die Machbarkeit geprüft werden kann. Sollten während der Implementierung Fehler oder Schwächen entdeckt werden, sollte ggf. die Implementierung gestoppt und zu einer der vorherigen Phasen zurückgekehrt werden, ehe die nachfolgende Phase eingeleitet wird. Ein solches Vorgehen sollte helfen, Unstimmigkeiten oder parallele Mehrstufigkeiten in den Phasen zu vermeiden. Während der Implementierung sollten potenzielle Einflüsse unbedingt gering gehalten werden, um den erstellten Plan nicht zu gefährden. Sollte es sich nicht vermeiden lassen, während der Implementierung neuere und unter Umständen ebenfalls geschäftskritische Prozesse in Betrieb zu nehmen, so ist unverzüglich in die Analysephase zurückzukehren, um etwaige Auswirkungen und Abhängigkeiten der bestehenden Prozesse auf den neu eingeführten Prozess und vice versa zu analysieren und die bereits bestehenden Maßnahmen ggf. um weitere Designstufen zu erweitern.

Testphase

In der Testphase geht es darum, den DR-Plan vollständig zu testen. Dies sollte unbedingt im Rahmen eines kompletten Disaster Recovery erfolgen. Nur so kann sichergestellt werden, dass auch wirklich alle Aspekte ineinandergreifen und aufeinander abgestimmt sind. Der beste DR-Plan wird ad absurdum geführt, wenn er nicht vor dem Eintritt eines Ernstfalles geprobt und auf seine Anwendbarkeit und Durchführung hin geprüft wird. Getestet werden sollte immer auf Basis der Testpläne, die in der Designphase erstellt wurden. Auftretende Abweichungen von den erwarteten Ergebnissen, die zuvor notiert wurden, sind zu dokumentieren und müssen ggf. zur Wiederaufnahme der Designphase führen. Auf diese Weise sollte es möglich sein, Probleme und potenzielle Schwachstellen hinreichend zu entdecken und den DR-Plan entsprechend zu optimieren.

Wartungsphase

Wichtig ist es zu verstehen, dass auch Geschäftsprozesse gewissen Veränderungen ausgesetzt sind. Diese Veränderungen gilt es zeitnah in den DR-Plan einzupflegen. In der Wartungsphase geht es darum, den bestehenden DR-Plan aktuell zu halten. Ausgewechselte Kennwörter oder geänderte Sicherungsverzeichnisse sind dabei relativ einfach zu behandeln, doch infrastrukturelle Änderungen an den Geschäftsprozessen sollten in jedem Fall dazu führen, eine neue Iteration des DRM anzustoßen.

Wird es auf diese Weise von allen Beteiligten gelebt, kann DRM eine Katastrophe zwar nicht verhindert, wohl aber die Voraussetzung dafür schaffen, dass die richtigen »Rettungsmaßnahmen« zur richtigen Zeit am richtigen Ort durchgeführt werden können. DRM trägt also dazu bei, die Folgen des K-Falles effizient und zielgerichtet zu mildern und die Wiederaufnahme des Geschäftsbetriebs zu beschleunigen.

Backup/High Availability versus Disaster: Welches Recovery darf es denn sein?

Backup & Recovery (B&R) gehört (hoffentlich) längst zum Alltag eines professionellen IT-Betriebs. Wer auf eine ausgereifte Methode zur Sicherung und Wiederherstellung von Geschäftsdaten verzichtet, handelt entweder grob fahrlässig oder weiß sehr genau, was er tut. Aber leistet ein bestehendes Verfahren auch das, was aus betrieblicher Sicht, genauer: aus Sicht des Business Continuity Management (BCM), gefordert wird? Zwei Beispiele sollen die Wichtigkeit dieser Anforderung an B&R verdeutlichen.

Gut gerüstet für den K-Fall?

Für einen beispielhaften datenbankbasierten Geschäftsprozess wird nach der Business-Impact-Analyse (BIA) eine RPO=0 festgelegt, Datenverlust ist folglich inakzeptabel. Bestünde für diese Datenbank ausschließlich ein sogenanntes Cold-Backupverfahren, bei dem die Datenbank zu bestimmten Zeitpunkten gestoppt und anschließend mit Betriebssystembefehlen als Kopie der Datendateien gesichert würde, und wäre außerdem nicht gesichert, dass Änderungen am Datenbestand zwischen den Cold-Backups ebenfalls gesichert und bei einem Recovery wieder eingespielt werden könnten, würde die B&R-Strategie die geforderte RPO nicht einhalten, obwohl sie in sich wahrscheinlich korrekt wäre. Der entscheidende Punkt ist jedoch, dass im K-Fall nur auf die letzte Sicherung zurückgegriffen werden kann und alle Änderungen ab diesem Zeitpunkt verloren gehen würden.

Bei einem ähnlichen Fall besteht für eine Datenbankanwendung vielleicht eine RTO von 15 Minuten. Da eine B&R-Strategie auf Basis einer Bandsicherung im Recovery-Fall unter Umständen mehrere Stunden in Anspruch nehmen würde, wäre die Anforderung aus der RTO nicht erfüllbar.

Die Beispiele verdeutlichen, dass eine funktionierende B&R-Strategie auf keinen Fall mit einem DR-Plan verwechselt werden sollte. In beiden Fällen leisten die gewählten Strategien zwar eine Sicherung der Daten, sie können jedoch nicht die Anforderungen erfüllen, die sich aus der BIA ergeben. Daraus ergibt sich die Schlussfolgerung, dass B&R »Disaster Aware« sein muss. Bei der Erstellung eines DR-Plans geht es folglich darum, bestehende B&R-Strategien dahingehend zu prüfen, ob sie die Anforderungen an die Wiederherstellung, die sich aus RTO und RPO ergeben, tatsächlich erfüllen können. Niemals sollte eine bestehende Strategie dazu verwendet werden, um aus ihr einen DR-Plan abzuleiten.

Ähnlich, wenngleich mit einer anderen Zielrichtung, verhält es sich mit den klassischen Clustermodellen, die häufig als »Hochverfügbarkeitslösungen« bezeichnet werden. Cluster können dazu eingesetzt werden, Rechenlast zu verteilen, wie das beispielsweise bei Oracle Real Application Cluster (RAC) der Fall ist. Sie können auch zur Verbesserung der Systemverfügbarkeit verwendet werden. Diese kann wiederum auch mit RAC mithilfe des »Mehr-Knoten-Prinzips« erreicht werden, beziehungsweise auch mittels der Lösung Oracle Failsafe, die auf dem Aktiv-Passiv-Modell des Microsoft Cluster Servers aufsetzt und auf Microsoft Windows beschränkt ist oder auch durch Cluster-Konzepte namhafter Hersteller wie Veritas. Die trügerische Annahme, eine hochverfügbare Systemumgebung schütze im Ernstfall vor Systemverlust, wird durch den Umstand genährt, dass bei allen Cluster-Modellen durch das Bereitstellen zusätzlicher Rechner und einer mehr oder weniger intelligenten Umschaltfunktionalität der Systemausfall einer Komponente abgefangen werden kann. Allen genannten Modellen ist jedoch gemeinsam, dass sie sich lediglich auf die zum Cluster gehörenden Rechner beziehen, während die ebenfalls zu schützenden Daten in der Regel in einem singulären Speichersystem (Storage Area Network, SAN) gehalten werden. Deshalb sehen neuere Konzepte inzwischen redundante Speichersysteme vor, die sich zusätzlich in räumlich getrennten Umgebungen unterbringen lassen. Dennoch schützen auch solche Systeme nicht vor Anwendungs- oder Systemfehlern. Ein durch Softwarefehler herbeigeführtes Löschen von Daten wirkt sich ebenso auch bei einem redundanten Speichersystem aus. Eine DR-Lösung, die diesen Umstand nicht berücksichtigt, kann man deshalb nicht mit gutem Gewissen als echte Hochverfügbarkeitslösung bezeichnen.

Resümee

Disaster Recovery ist – als integraler Bestandteil eines gesamtbetrieblichen Business Continuity Managements – zweifellos ein unabdingbarer Aspekt moderner IT-Strategien. Die Abhängigkeiten der meisten Betriebsprozesse von der unterlagerten IT-Infrastruktur sind längst elementar, so dass der zwischenzeitliche Verlust einer Teilkomponente oder gar der kompletten Infrastruktur in den meisten Fällen zum betrieblichen Aus führt … Es sei denn, diese Komponente kann in einer Art und Weise wiederhergestellt werden, wie es für den Fortbestand der Unternehmung notwendig ist. Eine ultimative Lösung für alle Fälle gibt es sicherlich nicht, doch eine geschickte Kombination aus unterschiedlichen Ansätzen (etwa die Kombination eines Cluster-Systems mit Data Guard) kann durchaus helfen, einem Ausfall gelassener ins Auge zu blicken.

Martin Dohse

____________________________________

OPITZ CONSULTING GmbH

Folgen Sie »manage it«

auf Google+

Copyright © 2003-2012 ap Verlag GmbH