Datensicherheit
Mit Disaster-Recovery die IT wetterfest machen
Ein umfassendes Konzept für das Disaster-Recovery ist für eine IT unverzichtbar. Dabei stehen unterschiedliche Ansatzpunkte und Verfahren zur Verfügung. Welcher Weg für ein Unternehmen der richtige ist, lässt sich nur im Einzelfall bestimmen. Disaster-Recovery gibt es nicht von der Stange.
Betriebswirtschaftlich betrachtet ist Disaster-Recovery ein Ärgernis: Die Unternehmens-IT investiert in nicht unerheblichem Umfang Mittel in eine Sache, von der man ausgehen kann, dass sie in der Regel gar nicht eintritt. Die typischen Disaster-Szenarien unterstreichen dies: In Deutschland ist schließlich noch nie ein Flugzeug oder ein Meteorit auf ein Rechenzentrum gestürzt, selbst Hochwasser und Sturm haben nur höchst selten IT-Systeme lahmgelegt. Statistisch gesehen sind derartige Großschadensereignisse für die IT nicht relevant. Umso prekärer für denjenigen, den es gegen alle Statistik doch trifft.
Mit Disaster-Recovery stellt die IT die Verfügbarkeit essentieller Services bei einem unvorhergesehenen, nicht alltäglichen Großschaden sicher. Im Grunde genommen handelt es sich um eine Art Versicherung: Man wappnet sich gegen ein Ereignis, das nicht eintreten sollte, und von dem man sich, wie bei einer Unfallversicherung, trotz aller Investitionen, auch nicht wünscht, dass es passiert. Für den Versicherten „rentieren“ sich Versicherungen so oder so nicht, aber sie verschaffen eine gewisse Sicherheit. Entsprechendes gilt auch für ein Disaster-Recovery-Konzept. Deshalb werden sie oft von internen oder externen Compliance-Richtlinien vorgeschrieben.
Grundsätzlich ist Disaster-Recovery ein komplexes Thema, für das es nicht die eine Lösung gibt – womöglich „out of the box“–, sondern nur individuelle Konzepte, die vor dem Hintergrund der Ziele und Ressourcen eines Unternehmens zu erstellen sind. Daraus ergibt sich, in welchem Maße die Services abgesichert werden müssen.
Redundant und räumlich getrennt
Ein Disaster bedeutet im Worst-Case die Zerstörung eines kompletten Standorts, inklusive aller im gleichen Standort betriebener Rechenzentren. Eine Disaster-Absicherung setzt daher zwingend eine redundante Realisierung von IT-Infrastrukturen in verschiedenen Standorten voraus. Die Standorte müssen zum Beispiel einen Mindestabstand von zehn Kilometern aufweisen, sie müssen sich in verschiedenen Gefahrengebieten befinden und durch unterschiedliche Stromanbieter oder Internetprovider versorgt werden können.
Gefahrengebiete können je nach den örtlichen Gegebenheiten verschiedene Hochwasserzonen sein, zum Beispiel in Hamburg. In Kalifornien wird man hier eher Erdbeben- oder Waldbrandgefahr berücksichtigen. Realisierungen in getrennten Rechenzentren, die sich aber am gleichen Standort befinden, sind keine Grundlage für eine umfassende Absicherung.
Die große Vielfalt an Konzepten für Disaster-Recovery erfordert die Festlegung von Zielen (KPI). Die folgenden Parameter stellen die wichtigsten Kennzahlen zur Bewertung von Konzepten dar:
- RTO (Recovery-Time-Objective): Wie viel Zeit wird benötigt, bis im Falle eines Ausfalls die Services im sekundären Rechenzentrum wieder zur Verfügung stehen?
- RPO (Recovery-Point-Objective): Wie viel Datenverlust kann man im Störungsfall akzeptieren?
Beide Parameter bestimmen darüber, wie aufwändig eine Disaster-Recovery-Lösung ist. Sie werden nicht einfach festgelegt, sondern ergeben sich individuell aus den Zielen und den Ressourcen eines Unternehmens.
Weitere für die Auswahl aus verschiedenen Konzepten relevante Parameter sind natürlich Kosten und die verfügbare Zeit für die Umsetzung eines Konzepts. Häufig nicht beachtet wird, dass wesentliche Randbedingungen festgelegt werden müssen. Dazu zählen zum Beispiel eine eventuell gewünschte Unabhängigkeit von Providern, Herstellern oder konkreten Produkten. Wichtig ist, dass Ziele und Randbedingungen im Vorfeld eines Projekts abgestimmt und festgelegt werden.
Es muss nicht nur IT-Infrastruktur im sekundären Rechenzentrum vorgehalten, sondern auch die Art und Weise von Replikation und Failover der Services geregelt werden. Auf der Basis räumlich getrennter Rechenzentren und der unternehmensspezifischen Vorgaben für RTO und RPO stellen sich für das Disaster-Recovery grundsätzlich zwei operative Aufgaben:
- Wie werden Daten repliziert, so dass ausreichend aktuelle und konsistente Daten im sekundären Rechenzentrum vorhanden sind?
- Wie erfolgt im Disaster-Fall die Umschaltung der Services im Rahmen eines Failover-Prozesses?
Die Antworten auf beide Fragen definieren letzten Endes das Disaster-Recovery-Konzept. In der Praxis wird zumeist die Aufmerksamkeit auf den ersten Punkt gelenkt, während der zweite Punkt gern vernachlässigt wird. Ganzheitliche Ansätze, die beiden Fragen genügend Aufmerksamkeit zukommen lassen, sind noch immer selten.
- Mit Disaster-Recovery die IT wetterfest machen
- Die Wege zum Disaster-Recovery
- Notfall-Prozesse
Lesen Sie mehr zum Thema
