Brian Jackson - stock.adobe.com
Oft vernachlässigt: RCO als Messkriterium für Disaster Recovery
Vielen SLAs fehlt ein wichtiger Aspekt: Die Konsistenz wiederhergestellter Umgebungen. RCO, Recovery Consistency Objective, gewinnt an Bedeutung und ergänzt die RTO und RPO.
Disaster Recovery und Business Continuity sind bekanntlich eng miteinander verknüpft. Die meisten Anwender messen die Wiederverfügbarkeit ihrer Systeme an RTO und RPO. Dabei handelt es sich um die Recovery Time Objective, also wörtlich: Zielvorgabe der Wiederherstellungsdauer, und die Recovery Point Objective, somit wörtlich: Zielvorgabe des Wiederherstellungszeitpunkts. So gängig wie diese beiden Begriffe sind, zeigen sie, dass ein wichtiges Thema oft vernachlässigt wird: Die RCO (Recovery Consistency Objective), die Zielvorgabe für die Konsistenz der wiederhergestellten Umgebung mithin die Qualität der Wiederherstellung. Dabei ist diese ja entscheiden für die Wiederaufnahme des IT-gestützten Geschäftsbetriebs.
Angesichts von Ransomware-Zeitbomben in Backup und einer Diversifizierung von Systemen über diverse Stufen des Cloud Computings wird es Zeit für mehr Augenmerk auf dieses dritte Messkriterium für Disaster Recovery: die Konsistenz der Wiederherstellung.
Konsistenz der Wiederherstellung
Nach einer Wiederherstellung beginnt die eigentliche Arbeit im Disaster Recovery. Ich habe neulich von einem Unternehmen mit nur ein paar hundert Anwendern gelernt, dass etwa vier Mitarbeiter einige Tage lang nur damit beschäftigt sind, die Vollständigkeit der Wiederherstellung zu prüfen: Sind die Benutzerdaten da? Die Datenbanken? Die Einstellungsdateien? Hat es mit allen Daten geklappt, die für das Betriebssystem benötigt werden? Sind die Daten, die nach DSGVO besonders zu schützen sind, entsprechend wiederhergestellt? Ist die Konsistenz/Integrität der Daten bewahrt?
Ein Problem ist dabei, die Sicherstellung, ob alle Transaktionen vor einem Crash noch in die Datensicherung eingegangen sind. In verteilten Umgebungen ist es durchaus vorstellbar, dass einzelne Transaktionen nicht ausgeführt worden sind, somit nicht gesichert worden sind und somit auch nicht Teil der Wiederherstellung sind. Das kann in kritischen Umgebungen zu einer Falle werden.
Anwender helfen sich in solchen Situationen damit, eine bestimmte Menge an Datenverlusten beziehungsweise an nicht ausgeführten Transaktionen in Kauf zu nehmen.
Das alles lässt sich manuell anhand von Tabellen und Templates einigermaßen kontrollieren.
Der Haken bestimmter, vor allem rein hardwaregestützter Verfahren wie zum Beispiel der Snapshot-Technologien ist, dass sie die Daten im Grunde nur duplizieren. Das ist inzwischen auch im Bewusstsein der Anwender angekommen. Dennoch ist in nur wenigen SLAs die Konsistenz der Wiederherstellung ausdrücklich enthalten – und es gibt gar nicht so viele Anbieter, die automatisiert für die Konsistenz der Wiederherstellung sorgen.
Auch die Speicherung von Daten in der Cloud macht das RCO zu einem komplexen Thema, weil Dateien und auch einzelne Daten plötzlich überall gespeichert sein können und womöglich von einem Datum verschiedene Instanzen existieren. Die DR-Lösungen müssen nach einer Störung auch solche verteilten Datenstrukturen systemübergreifend konsistent wiederherstellen können. Was vielleicht lokal ganz wunderbar funktioniert, kann in einer Cloud-Umgebung komplett versagen.
Lösungsansätze und der Markt
Lösungsansätze müssten also nicht nur einen aktuellen Stand der Daten verwalten, sondern auch die Transaktionen speichern, die nach dem zyklischen Speichern der Daten in einer Sicherung anfallen. Dann könnte bei einer Wiederherstellung zunächst das aktuelle Backup auf einen Spiegel übertragen werden und dann all die Transaktionen, die als gültig klassifiziert sind, auf dem Spiegel ausgeführt werden. Die Lösung erfordert neben der technischen Einrichtung eines Spiegelsystems zusätzlichen Speicher für das Puffern der Transaktionen.
Ein anderer Weg geht über die aufwendige Prüfung der Backup-Sets und der wiederhergestellten Daten. Checksummen und Timestamps werden auf Quell- und Zielsystemen aufwendig miteinander vergleichen. Dabei wird die Konsistenz der Wiederherstellung unter anderem dahingehend geprüft, dass keine Zeitbomben mit Schadsoftware aus dem Backup auf ein eigentlich sauberes System wiederhegestellt werden. Die Lösung benötigt für die Software vor allem Rechenzeit.
Auch die Kombination von hardware- und softwarebasierenden Verfahren kann die Konsistenz der wiederhergestellten Daten verbessern. Denkbar sind hier Snapshot-Technologien mit sehr umfangreichen Prüfsummen und Kontrollmechanismen. Hier könnten zum Beispiel Appliances mit einer Software zusammenarbeiten. Das kann kostengünstiger als das Duplizieren der Hardware für einen Spiegel sein.
Was zu berücksichtigen ist
In jedem Fall sollten die Lösung mit einer ausführlichen Erprobung geprüft werden. Wichtige Aspekte einer Ausschreibung betreffen den Aufwand, technische Voraussetzung und die Erfolgskontrolle, ob die Lösung zu den Datenvolumina passt. Eine Rolle spielt es auch, wie geschäftskritisch die Wiederherstellung ist: Reicht die Zeit für die softwareseitige Überprüfung der Checksummen und anderer Prüfpunkte für die maximal erlaubte Dauer der Nichtverfügbarkeit? Nicht zu vernachlässigen ist der Komfort bei der Einrichtung. Da sollten die Lösungen dahingehend geprüft werden, inwiefern sie über Templates leicht einzurichten sind. Wichtig ist vor allem, ob die Prüfung der Konsistenz automatisiert oder manuell stattfinden muss – und anhand welcher Kriterien diese gemessen wird.
Nicht ganz unerheblich sind beim Thema Recovery Consistency Objective die Kosten und die Standortthematik. Während manche kleine Lösung praktikabel und kostengünstig daherkommt, kann es sein, dass sie bei schweren Ereignissen wie Feuer oder Überschwemmung die gewünschte Konsistenz dennoch nicht erreicht, weil Komponenten des Backups – nämlich ausgerechnet die Systeme für die Prüfung der Konsistenz – beschädigt worden sind.
Weil kaum ein Anwender heute noch eine monolithische Umgebung betreibt, muss die DR-Lösung die Konsistenz der Wiederherstellung nicht nur für das Betriebssystem oder die SAP-Umgebung sicherstellen, sondern eben auch für alle Datenbanken, alle Client-Systeme und gegebenenfalls alle mobilen Devices und SaaS-Daten.
Dementsprechend ist die Dimensionierung der Lösung wiederum von Bedeutung: Genügt ein Speichersystem? Lässt sich die DR-Lösung womöglich mit Cloud Storage realisieren, der ja gemeinhin als einfach zu skalieren gilt?
Ein nicht zu vernachlässigender Aspekt – die DSGVO
Die sogenannten besonders schützenswerten personenbezogenen Daten (PII) und andere sensible Daten bedürfen seit Einführung der DSGVO der Aufmerksamkeit. Hier stellen sich fragen wie: Kann es sein, dass bereits gelöschte Daten bei der Wiederherstellung wieder in die Produktivsysteme gekommen sind? Haben die wiederhergestellten Daten die gleichen Eigenschaften hinsichtlich der Datenschutzeinstellungen? Neben den Antworten auf diese Fragen kommt es auch darauf an, ob die Daten auf allen beteiligten Systemen den gleichen Stand haben.
Spätestens dann, wenn Cloud-basierende Konzepte ins Spiel kommen, sollte auch nach den Kosten für die vollständige und datenschutzkonforme Zurückverlagerung von Daten gefragt werden. Dabei muss zum Beispiel das Recht auf Vergessenwerden beachtet werden, um bei einem Egress nicht versehentlich bereits korrekt gelöschte Daten wiederherzustellen.
Der Königsweg
Leider gibt es keinen Königsweg. Wichtig ist es, die SLAs zunächst dahingehend zu prüfen, ob neben den Wiederherstellungskriterien RTO und RPO auch das Recovery Consistency Objective dort enthalten ist und wie es umgesetzt wird. Fehlt die Wiederherstellungskonsistenz im SLA, sollte rasch ein Lösungskonzept gefunden werden. Durchaus schlüssig wirkt hier das Konzept der kontinuierlichen, aber zeitversetzten Datenspiegelung (CDP) auf ein entferntes System, bei dem nach dem Umschalten auf den Spiegel nur die noch gültigen Transaktionen eingespielt werden müssen.
