Reality Check: Was ist ihr RTO?

Gäbe es Olympische Spiele für IT-Manager, so wäre eine der meist beachteten Disziplinen der Wettbewerb der Notfallwiederherstellung. Die eigentliche Herausforderung ist die Zeitspanne, in der das passiert – RTO lässt grüßen. [...]

Eine der wichtigsten Aufgabe einer jeden IT ist es, die Nutzung unternehmensrelevanter Applikationen ohne Unterbrechung zu garantieren. Gerade in der IT sind ganze Geschäftsmodelle darauf ausgerichtet, ihre Dienste 24/7 anzubieten, weil Kunden keinerlei Unterbrechung ihrer gebuchten Dienste akzeptieren. Viele Branchen haben sogar konkrete Vorgaben des Gesetzgebers, definiert über die RTOs, zu erfüllen. Um diese Ziele zu erreichen, haben viele Firmen in Stretched-Cluster-Technologie investiert, um bei Hardware-Ausfällen sogar für komplette Rechenzentren abgesichert zu sein. Snapshots und regelmäßige Backups auf der Softwareseite sind dazu gedacht, RPOs zu reduzieren und RTOs, also die Zeit, die verstreicht, bis alle Systeme wieder verfügbar sind, auf ein Minimum zu verkürzen.
Der Stretched Cluster bietet im Idealfall einen Transparent Failover bei einem Ausfall der Hardware. Die Nachteile eines Stretched Clusters hingegen sind die sehr hohen Kosten, die mit der Technologie einhergehende Komplexität und der oft übersehene Fakt, dass der Cluster nicht gegen logische Fehler oder verlorene Daten von Applikationen absichert.

Die Millionen-Euro-Frage
Worauf es bei einer so wichtigen Zielstellung und sehr hohen Investitionen in die entsprechenden Systeme letzten Endes ankommt: Was ist der RTO? Ein IT-Manager, dessen Aufgabe es ist, den Betrieb jederzeit zu garantieren – koste es was es wolle –, sollte eigentlich in der Lage sein, diese einfache Frage zu beantworten.

In der Praxis funktioniert es nicht ganz so einfach. Auch mit den fortschrittlichsten und teuersten Speichersystemen, aufbauend auf Stretched-Cluster-Technologie, können die meisten IT-Manager keine Antwort über den RTO des von Ihnen verwalteten Systems geben. Dies wäre natürlich möglich, indem man einen Disaster-Recovery (DR)-Test durchführt. Das sollte auch regelmäßig geschehen, um zu bestätigen, dass das System funktioniert und im Notfall, bei einem echten Desaster, bereit wäre.

In der Theorie ist DR-Testing tatsächlich sehr einfach: Man zieht einfach den Stecker und startet die Stoppuhr. In der Praxis scheint das Vertrauen der meisten IT-Manager in ihr System nicht sehr hoch zu sein – trotz der enormen Summen, die sie gekostet haben. Niemand, der seine fünf Sinne beisammen hat, würde an einem funktionierenden System einfach den Stecker ziehen – obwohl man sehr viel Geld dafür bezahlt hat, damit man genau das tun könnte. Insbesondere bei sehr großen Organisationen mit hohem Datenbestand kann es fast unmöglich sein, einen DR-Test durchzuführen. Allein die Planung kann mehrere Tage Vorbereitung benötigen, weil verschieden IT-Abteilungen involviert sind, die alle zur selben Zeit bereit sein müssen.
Und die einzige Zeit im Jahr, zu der große Unternehmen tatsächlich einen DR-Test durchführen können, ist zwischen Weihnachten und Neujahr, damit man das System im Notfall noch richten könnte, falls tatsächlich etwas schief geht. Man hat schon von Fällen gehört, dass diese Großunternehmen einen DR-Test sogar innerhalb von acht Tagen nicht erfolgreich abschließen konnten, weil die Menge an zu bewegenden Daten einfach zu groß war, um den Test zu einhundert Prozent sicher zu gestalten.

Was jedoch sagt dies über die Compliance dieser Organisationen aus, wenn man in der Praxis unfähig ist, einen DR-Test durchzuführen? Gesetzliche Vorgaben, wie etwa in Deutschland das Bundesdatenschutzgesetz (BDSG), legen fest, dass „sichergestellt werden muss, dass personenbezogene Daten gegen zufällige Zerstörung oder Verlust geschützt werden“. Diese Anforderung wird durch die sogenannten „Acht Gebote der Datensicherheit“ spezifiziert. Dort ist unter dem Punkt „Verfügbarkeitskontrolle“ geregelt, dass als Maßnahme dafür das Vorhandensein eines Disaster- bzw. Backup-Konzepts vorgesehen ist.
Die Realität sieht für die meisten Organisationen ganz anders aus, was im Umkehrschluss bedeutet, dass die meisten Organisationen trotz teurer Stretched-Cluster-Technology die gesetzlichen Vorgaben nicht erfüllen. Zum Kreis dieser Organisationen zählen laut Industrieexperten durchaus auch sehr große und bekannte Unternehmen aus der Medizin, dem Finanz- und Versicherungswesen.

Bedrohung durch Ransomware
Ein positiver Nebeneffekt der neuesten Ransomware-Attacken scheint zu sein, dass Organisationen so langsam verstehen, dass ihr System – aufbauend auf sicherer Hardware – sie nicht vor Katastrophen wie menschlichem Versagen oder Softwareproblemen schützt und sie allein mit einem Stretched Cluster nicht ausreichend geschützt sind. Obwohl es keine offiziellen Zahlen gibt, glauben Industrieexperten, dass zirka 25 Prozent aller deutschen Krankenhäuser Opfer einer Ransomware-Attacke wurden und zum Teil monatelang an den Folgen zu leiden hatten, bevor die Systeme wieder liefen. Dies ist leider ein gutes Beispiel für eine schlechte DR-Strategie, weil natürlich niemand einen RTO von drei Monaten akzeptieren würde.
Mit diesem gravierenden Defizit konfrontiert, müssen sich Organisationen damit auseinandersetzen, über den Hardware-Ansatz hinaus zu blicken, um sich vor Katastrophen zu schützen und gleichzeitig das Vertrauen darauf zurückzugewinnen, dass ihre Systeme sich jederzeit in Kürze wiederherstellen lassen.
Ein weiteres Problem von DR-Testing ist, dass die meisten Applikationen heute konstant aktiv sind und es nicht möglich ist, sie einfach anzuhalten, was für einen Test aber notwendig wäre.
Ein Transparent Failover auf Hardwareebene schaltet einfach ohne Unterbrechung von einem Speicher auf den anderen um. Dies funktioniert leider nicht bei Applikationen, die schlimmstenfalls mit mehreren Datenbanken gleichzeitig verbunden sind. Ein DR-Test würde die Applikation anhalten und auf einem anderen System neu starten.
Eine kurze Unterbrechung ist folglich unausweichlich, weil Systeme heute in einer virtuellen Welt laufen und nicht mehr in einer physischen. Seitdem die meisten Umgebungen virtualisiert sind, muss die Frage erlaubt sein, warum viele Organisationen ihr Geld buchstäblich auf Hardware-basierte DR-Strategien setzen, die dann nicht einmal einen RTO von Null garantieren können, weil die Applikationen, die auf dem System laufen, ohnehin virtualisiert sind und es auch nicht möglich ist, einen effektiven DR-Test durchzuführen.

Replikation
Um die Nachteile der derzeitig vorherrschenden DR-Strategie auszugleichen, müssen Organisationen zuerst einmal verstehen, dass ihre Hardware-basierte Strategie mit Snapshots für ein physisches Rechenzentrum entwickelt wurde und den Bedingungen einer virtuellen Welt nicht gerecht wird. Der nächste logische Schritt, um die Notfallwiederherstellung in einem virtualisierten Rechenzentrum zu garantieren, ist Hypervisor-basierte Replikation, die nicht nur die Gefahr logischer Fehler bannt, sondern auch das Testen von DR vereinfacht und damit das Vertrauen in die Systeme wiederherstellt. Das Resultat ist DR-Testen als tagtägliche Routine, ohne Planung und ohne Unterbrechung der Dienste, mit nur ein paar Klicks und einem anschließenden Report für Audits. Dies klingt nach Zukunftsmusik für DR-gestresste IT-Admins. Dank Hypervisor-basierter Replikation ist diese Zukunftsvision jedoch bereits heute Realität.                                       

*Der Autor Johan van den Boogaart ist Regional Sales Manager bei Zerto.