WikiDer > Ziel des Wiederherstellungspunkts

Ziel des Wiederherstellungspunkts (RPO) bedeutet Ziel des Wiederherstellungspunkts und ist ein Konzept aus der Welt der Informationstechnologie. RPO ist das Ziel, den vereinbarten maximal zulässigen Datenverlust nach einem Computer Crash, durch die IT-Abteilung und/oder einen IT-Dienstleister. RPO ist verwandt mit RTO, beides sind Zeitintervalle.

Schema der Konzepte RPO und RTO. In diesem Beispiel die vereinbarten Werte von RPO und RTO nicht erkannte.

Erreichbare Werte

Null RPO

Ein RPO nahe Null ist seit 2019 unter Verwendung von . erreichbar ein NetApp MetroCluster in Kombination mit VMWare HA ^[1]

Minimal erreichbare Werte

Störungen innerhalb eines Computernetzwerks führen immer zu Datenverlust. Die folgende Tabelle bietet einen globalen Überblick über die Servicezahlen, die in vielen 'SLAs“ werden vereinbart.

^(H) Manuell basierend auf detaillierte Verfahren
^(EIN) Automatisch
^* erhöhte Kostenfaktoren werden zu 50 % durch Geräte- und Lizenzkosten und zu 50 % durch Arbeitsstunden für intensive Tests und die Entwicklung von Notfallverfahren bestimmt.

Komplizierende Faktoren

Verteilte Geschäftslogik

In den 1960er und 1970er Jahren wurden Mainframe- und Midrange-Computer (damals Minicomputer genannt) für den Geschäftsmarkt verwendet. Die gesamte Datenverarbeitung wurde in einem Computer zentralisiert und der Benutzer arbeitete an einem „dummen“ Terminal (ASCII-Terminal). Programme wurden geschrieben in COBOL, Pascal, fortran und C. Gerade wegen seiner nicht verteilten Natur führte dies (mehr oder weniger zwingend) zur Bündelung von Datenbank, Geschäftslogik und Benutzeroberfläche in einem Rechner. Moderne Anwendungen sind auf eine Vielzahl von Systemen verteilt und bestehen aus verschiedenen Plattformen, Produkten und Technologien. Dies macht es in der Praxis schwierig, die Geschäftslogik an einem Ort zu halten. Diese ungewollte Verbreitung wird auch dadurch verstärkt, dass Anwendungen über längere Zeiträume entwickelt werden und sich das Verständnis der Softwarearchitektur ständig ändert. Dadurch landet die Geschäftslogik (unbeabsichtigt) an mehreren Stellen in der Kette, sowohl auf der Präsentationsschicht als auch auf der Anwendungs- und Datenbankschicht (jeweils Javascript, Berechnungscode oder 'gespeicherte Prozedur'), verursacht immer mehr 'Einschränkungen', um die Datenbank konsistent zu halten. Auch Transaktionen haben einen verteilten Charakter und müssen daher eine längere Distanz über mehrere physikalische Systeme zurücklegen. Das Erstellen eines 'Schnappschusses' wird schwierig (wenn nicht unmöglich), einfach weil es nicht möglich ist, gleichzeitig einen Schnappschuss der gesamten Kette zu machen. Theoretisch könnte dieses Problem gelöst werden, indem die gesamte Anwendungskette in einer (virtuellen) Maschine ausgeführt wird, was jedoch aus Performance-Sicht nicht machbar ist. Dennoch wird dieser Snapshot immer in der Vergangenheit liegen, was niemals zu Zero RTO führen wird.

Informationsverlust (rot und grau) bei einem ICT-Crash-Vorfall

Zurückgestellte Datenbanktransaktionen

Relationale Datenbanken verwenden bei der Verarbeitung von Transaktionen "Change-and-Confirm"-Regeln. Eine Anwendung kann einige Felder ändern, aber erst später den Abschluss der Transaktion bestätigen. In manchen Datenbanken erfolgt die Bestätigung einer Transaktion aus Performancegründen bereits im internen Speicher des Applikationsservers, sodass Transaktionen relativ lange unbestätigt bleiben. Wenn die Datenbank während dieser Zeit abbricht, ist sie nicht mehr konsistent und es muss ein 'Rollback' durchgeführt werden.

Große Nutzerzahlen in Kombination mit langen Ketten

Jede Benutzertransaktion kennt das sogenannte "Mehrschichtarchitektur", ein langer Weg der Verarbeitung. Von der Bestätigung durch den Benutzer bis die Daten tatsächlich auf die Festplatte geschrieben wurden und sich die Datenbank in einem konsistenten Zustand befindet, können mehrere zehn Sekunden vergangen sein. Die Anwendung hat Hunderte von Benutzern gleichzeitig, es ist also nicht nur eine einzige Änderung, sondern es müssen eine Vielzahl von Transaktionen gleichzeitig durchgeführt werden. Üblicherweise wird ein Teil der vorzunehmenden Änderungen temporär in eine Warteschlange gestellt (TransaktionWarteschlange), da es Beziehungen zwischen Datensätzen gibt, die zunächst erhoben werden müssen, um Kohärenz herzustellen. Darüber hinaus verwendet das logische und physikalische Zwischen-Engineering selbst auch leistungssteigernde Mechanismen. Daten werden zwischengespeichert, um der übergeordneten Komponente bereits eine Abschlussbestätigung (Commit) zu senden, was in etwa so bedeutet: "Betrachten Sie dies als abgeschlossen, dann können Sie wahrscheinlich mit dem folgenden Befehl fortfahren". Dies verbessert die Leistung, der Nachteil ist jedoch mehr Datenverlust bei Defekten. Schließlich verteilt sich dieses Phänomen auch über eine lange Kette der of persönlicher Computer, FrontendAnwendung, LAN, Anwendungsserver, 'Backbone' IT Infrastruktur, Datenbankserver, SANInfrastruktur, zwischengespeicherte Festplattencontroller und schließlich die Festplatten selbst.

Geteilte und/oder kombinierte Verantwortung

Die kombinierte Verantwortung wird die Netzverfügbarkeit unwiderruflich beeinträchtigen. Eine bekannte Tatsache ist, dass die Komplexität der Anwendungsunterstützung exponentiell mit der Anzahl verschiedener Parteien wächst, die Verantwortung tragen und Autorität über ein einzelnes Gerät oder System haben. Durch einen exponentiellen Anstieg der MLDT (Mean Logistics Delay Time) sinkt die Nettoverfügbarkeit stark. Obwohl das fragliche Problem einfacher Natur sein kann, geht viel Zeit durch Verweise und langwierige Diskussionen verloren. Probleme, die theoretisch in einer Stunde gelöst werden können, dauern oft Tage. Im Idealfall wären alle Verantwortlichen und Beteiligten direkt vor Ort, um Probleme zu lösen. Die Lösung besteht daher darin, die gesamte Verantwortung einer zuständigen Partei zu übertragen. Diese Partei darf selbst nicht von externem Wissen abhängig sein.

Datenkorruption und menschliches Versagen

Zentral gespeicherte Dateien und Datenbanken können auch durch den Ausfall zentraler Geräte vollständig beschädigt werden. In solchen Situationen sind RPO und RTOWerte summieren sich schnell zu Stunden. Dies gilt auch für menschliches Versagen, wenn Dateien oder große Mengen von Datenbankdaten versehentlich gelöscht werden. In dieser Situation muss ein Backup verwendet werden, das in der Regel aus der Nacht davor stammt. Bei Datenbanken können Sie sich für einen „Rollback“ entscheiden, bei dem die Datenbank vorübergehend keine neuen Transaktionen verarbeiten kann. Es wird oft angenommen, dass das Replizieren der Datenbank eine Lösung ist, um einen RPO/RTO von Null zu erreichen, aber in der Praxis löst dies das obige Problem nicht, da die Daten sowohl in der ursprünglichen als auch in der replizierten Datenbank gelöscht wurden. Diese Technik kann jedoch für eine höhere Verfügbarkeit nützlich sein, indem eine der beiden Datenbanken für neue Transaktionen angehalten und ein "Rollback" durchgeführt wird. Die andere Datenbank kann für Lesetransaktionen auf den verbleibenden Daten aktiv bleiben. In der Praxis steigt die RTO für eine vollständige Wiederherstellung auf einen Wert, der dem Rest des Arbeitstages entspricht. Der RPO bleibt jedoch innerhalb von Minuten erhalten, sofern die DBA versteht seinen Job.