RTO und RPO einfach erklärt: Wie viel Ausfall kann sich Ihr Unternehmen leisten

Zwei Kennzahlen, die bestimmen, wie oft gesichert wird und wohin Systeme wiederhergestellt werden. RTO und RPO ohne Theorie erklärt, mit Beispielen aus Buchhaltung, E-Mail und Produktion.

RTO und RPO einfach erklärt: Wie viel Ausfall kann sich Ihr Unternehmen leisten

Auf die Frage „Wie lange kann das Unternehmen ohne das Buchhaltungssystem arbeiten?“ lautet die Antwort meist „Keine Stunde“. Auf die Frage „Wie viele Arbeitsstunden können Sie verlieren, wenn das System aus einem Backup wiederhergestellt werden muss?“ lautet sie „Keine“. Beide Antworten sind verständlich, aber keine ist nützlich: Ein Backup-System, das nach diesen Antworten entworfen wird, würde mehr kosten als das Unternehmen selbst.

Die wirkliche Antwort liegt immer irgendwo zwischen „keine Stunde“ und „eine Woche“, und sie ist für jedes System anders. E-Mail, Buchhaltung, Produktionssteuerung und Dateiserver haben jeweils andere Grenzen. Um über diese Grenzen konkret zu sprechen, gibt es zwei Kennzahlen: RTO und RPO.

In diesem Artikel erklären wir sie ohne Theorie: was sie bedeuten, wie eine Führungskraft ohne IT-Hintergrund sie festlegt, wie sie sich in Backup-Häufigkeit und Wiederherstellungsort übersetzen und wie Sie sie so dokumentieren, dass sie zu einem Audit nach NIS2 oder DORA passen.

RTO: Wie lange Sie warten können

RTO (Recovery Time Objective) ist die längste akzeptable Zeit vom Stillstand eines Systems bis zu seinem erneuten Betrieb. Nicht die Zeit, in der die IT die Wiederherstellung verspricht, sondern die Zeit, nach der dem Unternehmen echter Schaden entsteht.

Beispiele aus dem Alltag unserer Kunden:

  • Buchhaltung. In einem Handelsunternehmen können Sie ohne das Buchhaltungssystem keine Rechnungen ausstellen und keine Ware annehmen. Der RTO beträgt vier Stunden: Einen halben Tag lang kann man mit Lieferscheinen auf Papier arbeiten und sie später nacherfassen, einen ganzen Tag nicht.
  • E-Mail. In einem Dienstleistungsunternehmen, in dem die gesamte Kommunikation mit Kunden per E-Mail läuft, beträgt der RTO eine Stunde. In einem Logistiklager, in dem Aufträge über ein System eingehen und E-Mail nur intern genutzt wird, ist es ein Tag.
  • Produktionssteuerung. Steht die Linie ohne das System still, wird der RTO in Minuten oder Dutzenden Minuten gemessen, und die Wiederherstellung aus einem Backup ist gar nicht die erste Antwort. Die erste Antwort ist ein redundantes System.

Der RTO wird vom Geschäft festgelegt, nicht von der IT. Die IT beantwortet die Frage, ob sich der festgelegte RTO erreichen lässt und was er kostet.

RPO: Wie viel Arbeit Sie verlieren können

RPO (Recovery Point Objective) ist der längste akzeptable Zeitraum an Daten, den Sie verlieren dürfen. In der Praxis: wie viel Zeit zwischen dem letzten funktionierenden Backup und dem Vorfall vergangen ist.

Dieselben Beispiele:

  • Buchhaltung. Läuft das Backup jede Nacht, geht im schlimmsten Fall ein ganzer Arbeitstag verloren: alle Rechnungen, Zahlungen und Lagerbewegungen dieses Tages. Zwei Buchhalter würden sie über ein bis zwei Tage neu erfassen. Das Unternehmen entscheidet, dass der RPO vier Stunden beträgt, und die Backups laufen alle vier Stunden.
  • E-Mail. Nach dem letzten Backup eingegangene Nachrichten verschwinden in einem Microsoft-365-Tenant nicht, daher geht es beim RPO hier eher um gelöschte oder verschlüsselte Daten als um Zeit. Ein Tag genügt in der Regel.
  • Produktionssystem. Verlorene Stunden bedeuten, dass unbekannt ist, was aus welchen Materialien produziert wurde. Der RPO liegt bei Minuten, das heißt: nicht mehr Backups, sondern kontinuierliche Replikation.

RTO und RPO sind voneinander unabhängig. Sie können ein System haben, das Sie in einer Stunde wiederherstellen, aber einen Tag an Daten verlieren, und umgekehrt.

Wie Sie die Kosten eines Ausfalls ohne Eurobeträge abschätzen

Führungskräfte bleiben oft daran hängen, dem Ausfall einen Preis zuzuordnen. Das ist nicht nötig. Drei einfachere Fragen je System genügen:

  • Wie viele Personen können nicht mehr arbeiten, wenn das System ausfällt? Zehn Mitarbeitende im Lager und zwei Buchhalter sind zwölf Personen, die dasitzen und warten. Multiplizieren Sie mit den Stunden.
  • Wie viele Aufträge, Sendungen oder Rechnungen laufen pro Stunde über dieses System? Das muss nacherfasst werden oder geht ganz verloren.
  • Was passiert beim Kunden? Er bekommt keine Lieferung, keine Antwort, kann nicht bezahlen. Hier beginnen vertragliche Pflichten und der Ruf des Unternehmens.

Tragen Sie die Antworten in eine Tabelle mit drei Spalten ein: System, was nach einer Stunde stillsteht, was nach einem Tag stillsteht. RTO und RPO ergeben sich daraus von selbst, und meist zeigt sich, dass von zwanzig Systemen nur vier oder fünf wirklich kritisch sind. Sie verdienen den größten Teil des Backup-Budgets.

Wie sich RTO und RPO in Technik übersetzen

Hier beginnt die Arbeit der IT. Die beiden Kennzahlen treiben zwei Entscheidungen.

Der RPO bestimmt die Backup-Häufigkeit

Beträgt der RPO einen Tag, genügt ein nächtliches Backup. Beträgt er vier Stunden, sind Backups oder Snapshots alle vier Stunden nötig, was bereits Anforderungen an Speicher und Netz stellt. Liegt er bei Minuten, reichen Backups nicht mehr, und Sie brauchen Echtzeit-Replikation an einen zweiten Standort. Jeder Schritt nach unten ist teurer, deshalb sollte der RPO nicht kürzer sein, als das Geschäft tatsächlich entschieden hat.

Der RTO bestimmt, wohin und woraus Sie wiederherstellen

Die Wiederherstellungszeit hat drei Teile: bis Sie den Ausfall bemerken, bis Sie wissen, wohin wiederhergestellt wird, und bis die Wiederherstellung abgeschlossen ist. Ist der Serverraum abgebrannt, gibt es den zweiten Teil womöglich gar nicht, weil es keinen Ort zum Wiederherstellen gibt. Ein kurzer RTO bedeutet daher einen im Voraus vorbereiteten Standort.

RTOWas das in der Praxis bedeutet
Eine WocheEin Backup genügt; ein neuer Server kann bestellt und vorbereitet werden
Ein TagSie brauchen einen Ausweichstandort, an dem ein Server aus einem Backup hochgefahren werden kann
StundenSie brauchen eine vorbereitete Umgebung und ein getestetes Verfahren
MinutenSie brauchen ein redundantes System, das dauerhaft läuft

Unsere PlanB-Wiederherstellung der Infrastruktur ist genau für die Zeilen „Tag“ und „Stunden“ gedacht: Die Backups Ihrer Server liegen in unserer Cloud, und daneben steht eine vorbereitete Umgebung, in der diese Backups als laufende Server gestartet werden, während Ihre Infrastruktur repariert wird. Die Backup-Seite deckt die Server-Backups in der von Ihnen festgelegten Häufigkeit ab.

Noch eine Nuance: Ein RTO, den niemand gemessen hat, ist nur eine Zahl in einem Dokument. Die tatsächliche Wiederherstellungszeit erfahren Sie nur, wenn Sie das System in eine isolierte Umgebung wiederherstellen und auf die Uhr schauen.

So dokumentieren Sie es für NIS2 und DORA

Für beide Regelwerke sind RTO und RPO Managementinformationen, keine technischen Informationen. NIS2 verlangt Maßnahmen zur Betriebskontinuität und zum Backup-Management, DORA eine Richtlinie zur Fortführung des IKT-Geschäftsbetriebs mit klaren Wiederherstellungszielen für wichtige Funktionen. In der Praxis genügt einem Auditor ein Dokument mit dieser Struktur:

  • Eine Liste der Systeme mit der Bewertung ihrer Kritikalität.
  • Für jedes System der RTO, der RPO und wer sie auf der Geschäftsseite genehmigt hat.
  • Welche technische Maßnahme jede Kennzahl umsetzt: Backup-Häufigkeit, Speicherort, Wiederherstellungsort.
  • Wann zuletzt überprüft wurde, dass die Kennzahlen erreichbar sind, und mit welchem Ergebnis.
  • Wann das Dokument überprüft wird: mindestens einmal im Jahr und nach größeren Änderungen.

Wenn wir Unternehmen auf die DORA-Anforderungen vorbereiten, erstellen wir meist zuerst dieses Dokument, denn alle späteren Entscheidungen zu Backup und Wiederherstellung hängen davon ab.

Wo Sie anfangen

  • Listen Sie alle Systeme des Unternehmens auf und beantworten Sie für jedes die Frage, was nach einer Stunde und was nach einem Tag stillsteht.
  • Legen Sie für die fünf wichtigsten Systeme RTO und RPO gemeinsam mit den fachlich Verantwortlichen fest, nicht allein mit der IT.
  • Vergleichen Sie mit der heutigen Backup-Praxis: Beträgt der RPO vier Stunden und das Backup läuft nachts, haben Sie eine Lücke, die nur Sie kennen.
  • Stellen Sie ein kritisches System in eine isolierte Umgebung wieder her und messen Sie den realen RTO.
  • Wenn wir diese Arbeit gemeinsam mit Ihnen erledigen und ein auditgeeignetes Dokument vorbereiten sollen, melden Sie sich über das Kontaktformular.