Disaster Recovery - Opitz Consulting

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!
S
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 Anwendungsoder
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