Demo ansehen×
×

Sehen Sie NinjaOne in Aktion!

Mit dem Absenden dieses Formulars akzeptiere ich die Datenschutzerklärung von NinjaOne.

RTO vs. RPO: Wo liegt der Unterschied?

RPO vs RTO Blog banner

MSPs haben gegenüber ihren Kunden die Pflicht, Ausfallzeiten zu minimieren und dafür zu sorgen, dass Ihre Infrastruktur stets online und voll funktionsfähig bleibt. Dazu gehört auch, sich auf das Unerwartete vorzubereiten, um Ausfallzeiten zu verkürzen. Die Festlegung von Zielen für die Problemenlösung und die Wiederaufnahme des Betriebs ist entscheidend für die Verringerung von Ausfallzeiten bei Kunden.

Recovery Time Objective (RTO) und Recovery Point Objective (RPO) sind Kernkonzepte des Disaster-Recovery-Prozesses, der die Wiederherstellung von Daten und Systemen im Notfall steuert. Managed Service Provider sollten diese Kennzahlen überprüfen, ihre Rolle im Wiederherstellungsprozess definieren und darauf hinarbeiten, diese Ziele in die Resilienzpläne ihrer Kunden zu integrieren.

In diesem Artikel werden folgende Fragen beantwortet:

  • Was sind RTO und RPO?
  • Wo liegen die Unterschiede zwischen Recovery Time Objectives und Recovery Point Objectives?
  • Warum sind RTO und RPO für Managed Service Provider wichtig?
  • Wie werden RTO und RPO berechnet?
  • Wie können IT-Tools Sie bei der Einhaltung dieser Wiederherstellungsziele wirkungsvoll unterstützen?

Was ist ein RTO?

Ein Recovery Time Objective (RTO) definiert Parameter dafür, wie schnell ein Unternehmen seine Systeme nach einem Ausfall wiederherstellen können muss. Dies wird für jeden einzelnen Kunden berechnet und ist individuell auf den jeweiligen Betrieb zugeschnitten.

Die Festlegung eines RTO ermöglicht es Ihnen, fundiertere Entscheidungen über Backup- und Disaster-Recovery-Lösungen (BDR) und deren Implementierung zu treffen. Harte Zahlen machen es einfacher, die Dinge realistisch und objektiv zu planen, anstatt sich auf zweideutige Phrasen wie „so schnell wie möglich wieder zum Laufen bringen“ zu verlassen. Solche Verallgemeinerungen sind in rechtlichen Vereinbarungen (Service Level Agreements) ohnehin schwer zu definieren.

Es ist relativ einfach, sich ein RTO in der Praxis vorzustellen: Es handelt sich um ein Ziel, das durch die Analyse der mit Ausfallzeiten verbundenen Kosten und Risiken festgelegt wird (es macht dabei Sinn, zu definieren, was „Ausfallzeit“ für den jeweiligen Kunden bedeutet) und wie lange er auf die Wiederherstellung warten kann, bevor die Verluste erheblich werden.

Einige Faktoren, die das RTO eines Benutzers beeinflussen können, sind:

  • Wie viel Umsatz verliert das Unternehmen pro Stunde Ausfallzeit
  • Wie viel finanzieller Verlust kann im Notfall verkraftet werden
  • Verfügbarkeit der für die Wiederherstellung des Betriebs erforderlichen Ressourcen
  • Toleranz der eigenen Kunden gegenüber Ausfallzeiten

Wenn ein Kunde seine Systeme innerhalb von drei Stunden wiederherstellen können muss, ist dies sein RTO. Wenn die berechnete durchschnittliche Zeit bis zur tatsächlichen Wiederherstellung fünf Stunden beträgt, hat er sein RTO also um zwei Stunden verfehlt. Diese vorausgehende Rechnung zeigt also, dass mehr in Backup Disaster and Response (BDR-Lösungen) investiert werden muss, um die tatsächliche Zeit bis zur Wiederherstellung zu verkürzen.

Was ist ein RPO?

Ein Recovery Point Objective (RPO) ist ein ähnlicher Schwellenwert zur Definition verkraftbarer Verluste bzw. Risiken. Während ein RTO die Zeitspanne definiert, die verstreichen kann, bis es kritisch wird, wird bei einem RPO die Datenmenge festgelegt, die Ihr Kunde verlieren kann, ohne dass dies erhebliche oder katastrophale Folgen hat.

Dabei geht es vor allem um die Kadenz der Datensicherung – also die Frequenz des letzten Sicherungspunkts. Wenn Ihr Kunde von jetzt auf gleich sämtliche Systeme verlieren würde und nur noch sein letztes Backup übrig bliebe, wie viele für die Fortführung des Geschäftsbetriebs notwendigen Daten wären dann noch vorhanden?

Viele verwenden das Gesundheitswesen als gutes Praxisbeispiel für ein RPO. Während einige Unternehmen es sich leisten können, alle Daten, die sie im Laufe einer Woche eingeben, zu verlieren (sie können sie vielleicht einfach aus Papierdokumenten neu eingeben), haben Krankenhäuser im Allgemeinen keine solche Fehlertoleranz. Bei Dutzenden von medizinischen Fachkräften, die jeden Tag Tausende von Medikamenten ausgeben, ist die Wahrscheinlichkeit sehr gering, dass sich das Personal an alles erinnert, was es in Bezug auf die Behandlung getan hat oder tun muss.

Und da es sich um Arzneimittel handelt, könnte der Verlust von Daten auch nur eines einzigen Tages bedeuten, dass die Dosierung verwechselt oder die Medikamente vermischt werden. Dies sind potenziell lebensbedrohliche Probleme, sodass ein solches Unternehmen seine Daten regelmäßig sichern muss. Dieser Bedarf an aktuellen Daten bildet die Grundlage für RPOs im Gesundheitsbereich.

RPOs sind für den MSP wichtig, weil sie seine Empfehlungen für den Einsatz von Daten-Backup-Lösungen leiten – insbesondere wenn es um Speicherplatz und Voraussetzungen geht. Häufigere Backups bedeuten einen höheren Datenverbrauch. Es ist wichtig, dass die Kunden verstehen, warum ihr RPO wichtig ist, wenn sie den Wert dieser zusätzlichen Kosten erläutern müssen.

Einige Faktoren, die das RPO eines Benutzers beeinflussen können, sind:

  • Komplexität und Anzahl der kritischen Anwendungen und Systeme
  • Datenvolumen und Zugriffsanforderungen
  • Wie häufig sich Daten ändern (d. h. wie oft wichtige Informationen in einer Datei hinzugefügt oder geändert werden)
  • Häufigkeit und Methode der Datensicherung

Was ist der Unterschied zwischen RTO und RPO?

Beide Metriken sind bei der Formulierung von Plänen für Backups und Datenwiederherstellung relevant. RPO und RTO helfen Ihnen bei der Entscheidung über die wichtigsten Sicherungs- und Wiederherstellungsfunktionen und somit sind Sie in der Lage, Ihren Kunden die richtigen BDR-Lösungen zu empfehlen. Letztendlich ist es Ihr Ziel, sicherzustellen, dass kritische Daten und Systeme bei Bedarf verfügbar sind. Diese Berechnungen können Ihnen helfen, dieses Ziel zu erreichen.

Beide sind im Rahmen der Wiederherstellungsplanung von Bedeutung, unterscheiden sich aber in der Praxis. Aktive RTOs werden in der Regel nach dem Eintreten eines Ereignisses festgelegt (ausgenommen solche, die theoretisch während der Planung verwendet werden). RPOs werden immer festgelegt, bevor eine Wiederherstellung erforderlich ist.

In einigen Fällen konzentriert sich die Wiederherstellungsplanung auf die Systeme und nicht auf die Daten. In diesen Fällen ist lediglich ein RTO von Bedeutung. Sobald Daten Teil der Rechnung werden, sollte ein MSP auch das RPO berechnen und entsprechend berücksichtigen. Beachten Sie: Wenn beide Berechnungen kombiniert werden, erfordert ein kurzes RTO in der Regel auch ein ebenso kurzes RPO.

Berechnung von RPO und RTO

Die relevanten RTO- und RPO-Ziele werden in der Regel im Rahmen einer Business Impact Analysis (BIA) oder einer allgemeinen Risikoanalyse ermittelt.

Bei einer BIA besteht das Ziel darin, geschäftskritische Prozesse zu identifizieren und die Technologien und Daten zu ermitteln, die zur Ausführung dieser Vorgänge benötigt werden. In diesen Berichten werden häufig die finanziellen Auswirkungen von Ausfallzeiten oder Unterbrechungen berücksichtigt und potenzielle Ausfallrisiken aufgezeigt.

Der MSP holt in der Regel die Meinung der Geschäftsführung des Kunden oder der zuständigen leitenden Angestellten ein, um Ziele festzulegen und den Wiederherstellungsszenarien entsprechende Zahlenwerte zuzuweisen. Sie können damit beginnen, Best-Case- und Worst-Case-Szenarien zu untersuchen und sich rückwärts vorarbeiten, um erreichbare, angemessene Werte zu finden.

Es gibt keine Standardformel für die Berechnung von RTO/RPO-Werten, da es sich um numerische Zeitwerte handelt, die für jedes Unternehmen individuell unterschiedlich sind. Ein kritischer Server kann ein RTO von einer Stunde haben, während das RTO eines weniger kritischen Systems vielleicht 24 Stunden betragen kann. Der gesamte Zweck der BIA besteht darin, angemessene Ziele zu finden, die darauf basieren, wie notwendig die verschiedenen Systeme für den Benutzer sind.

Wenn die Zeitspannen für RTO und RPO sinken, werden die Kosten für das Erreichen dieser Ziele wahrscheinlich steigen. In dieser Hinsicht geben Ihnen die RTO/RPO-Berechnungen die Informationen, die Sie benötigen, um Lösungen und Kosten zu ermitteln. Dies ist eine wichtige Voraussetzung dafür, dass Sie Ihre Verträge rentabel halten können.

Die BIA und die RTO/RPO-Zahlen können auch während des Verkaufsprozesses nützlich sein. Konflikte entstehen oft im Zusammenhang mit Kosten, daher ist es wichtig, den Wert der BDR-Dienste darlegen zu können. Dies ist einfacher, wenn Sie darauf hinweisen, dass weniger teure Lösungen die RTO/RPO-Anforderungen möglicherweise nicht erfüllen und im Falle eines Datenverlusts zu höheren Kosten führen werden.

Wie NinjaOne MSPs beim Erreichen von RTOs und RPOs unterstützt

Anhand der Ergebnisse Ihrer Risikoanalyse und BIA sollten Sie eine gute Vorstellung davon bekommen, welche Datenverluste und Wiederherstellungszeiträume für Ihren Kunden ein Risiko darstellen könnten. Teil der Gesamtanalyse ist die Bestimmung der Häufigkeit von Ereignissen, der Wahrscheinlichkeit von Gefahren und der möglichen Auswirkungen auf den Kunden.

Sobald Sie diese Risiko-Kennzahlen quantifiziert haben, können Sie diese Faktoren in entsprechende Empfehlungen für Investitionen und Maßnahmen verargumentieren. Eine zentralisierte Fernüberwachungs- und -Verwaltungs-Plattform wie NinjaOne macht diese beiden Prozesse wesentlich einfacher. Durch die Aggregation von Daten über wichtige Kunden-Assets und deren Verwendung erhalten Sie tiefere Einblicke in die Datengrundlage und können RPO und RTO wesentlich genauer bestimmen.

Da BDR-Lösungen aufgrund der festgelegten RTO/RPO-Kennzahlen konfiguriert werden müssen, ist die integrierte Backup-Lösung von NinjaOne so flexibel ausgelegt, dass Sie diese Herausforderung nahtlos auf der selben Benutzeroberfläche meistern können, anstatt lediglich die Daten auszuwerten und Ihre Ziele festzulegen.

Fazit

Es gibt zwei Metriken, die MSPs helfen, die besten Ergebnisse bei Daten-Backup und Recovery zu erzielen: Recovery Time Objective und Recovery Point Objective. Beide Kennzahlen sind bei der Arbeit mit Daten-Backup und und Recovery-Lösungen, Business-Continuity-Strategien und Disaster-Recovery-Plänen von entscheidender Bedeutung und hängen miteinander zusammen.

Für einen MSP, der Daten-Backup und Recovery-Lösungen anbietet, sind diese Metriken für die Planung und den Vertrieb unerlässlich. RTOs/RPOs helfen bei der Bestimmung der optimalen Konfiguration und Technologiewahl der Daten-Backup-Lösung und sorgen dafür, dass Ziele im Ernstfall eingehalten werden können. Diese Zahlen können auch für die Einhaltung von Compliance-Vorschriften und für Auditierungen wichtig sein, da Auditoren nach Belegen für diese Werte als etablierte Datensicherungs-/Wiederherstellungskontrollen suchen könnten.

NinjaOne kann Ihnen dabei helfen, RPO und RTO für Ihre Kunden zu ermitteln, zu berechnen und richtig einzusetzen. So können Sie sicherstellen, dass Sie den besten Service bieten und die Erwartungen in Bezug auf zugesagte Betriebszeiträume und die Betriebskontinuität erfüllen.

Nächste Schritte

Der Aufbau eines effizienten und effektiven IT-Teams erfordert eine zentralisierte Lösung, die als vereintes Tool für die Bereitstellung von Dienstleistungen fungiert. NinjaOne ermöglicht es IT-Teams, all ihre Geräte zu überwachen, verwalten, sichern und zu unterstützen, unabhängig von ihrem Ort und komplexer Infrastruktur vor Ort.

Erfahren Sie mehr über NinjaOne Endpoint Management, schauen Sie sich eine Live-Tour an, oder starten Sie Ihre kostenlose Testversion der NinjaOne Plattform.

Das könnte Sie auch interessieren

Sind Sie bereit, ein IT-Ninja zu werden?

Erfahren Sie, wie Sie mit NinjaOne Ihren IT-Betrieb vereinfachen können.

NinjaOne Terms & Conditions

By clicking the “I Accept” button below, you indicate your acceptance of the following legal terms as well as our Terms of Use:

  • Ownership Rights: NinjaOne owns and will continue to own all right, title, and interest in and to the script (including the copyright). NinjaOne is giving you a limited license to use the script in accordance with these legal terms.
  • Use Limitation: You may only use the script for your legitimate personal or internal business purposes, and you may not share the script with another party.
  • Republication Prohibition: Under no circumstances are you permitted to re-publish the script in any script library belonging to or under the control of any other software provider.
  • Warranty Disclaimer: The script is provided “as is” and “as available”, without warranty of any kind. NinjaOne makes no promise or guarantee that the script will be free from defects or that it will meet your specific needs or expectations.
  • Assumption of Risk: Your use of the script is at your own risk. You acknowledge that there are certain inherent risks in using the script, and you understand and assume each of those risks.
  • Waiver and Release: You will not hold NinjaOne responsible for any adverse or unintended consequences resulting from your use of the script, and you waive any legal or equitable rights or remedies you may have against NinjaOne relating to your use of the script.
  • EULA: If you are a NinjaOne customer, your use of the script is subject to the End User License Agreement applicable to you (EULA).