RPO und RTO für KMU: Datenverlust und Ausfallzeit richtig bewerten

Die letzten Stunden an Auftragseingaben fehlen. Oder die Daten sind vollständig vorhanden, aber die Warenwirtschaft bleibt einen Arbeitstag lang unerreichbar. In einem dritten Fall wurde die Anwendung wiederhergestellt, kann ohne Netzwerk, Identitätsdienst oder Datenbank jedoch noch nicht genutzt werden.

Diese Situationen betreffen drei unterschiedliche Fragen: Wie viel Datenverlust ist vertretbar? Wie schnell muss ein Dienst wieder nutzbar sein? Und ab wann werden die betrieblichen Folgen einer Unterbrechung untragbar? Die Antworten liefern keine Backup-Software und kein allgemeiner Standardwert. Sie müssen aus den Geschäftsprozessen des Unternehmens abgeleitet werden.

RPO, RTO und Ausfallgrenze auseinanderhalten

Das Recovery Point Objective (RPO) beschreibt den maximal vertretbaren Datenverlust in zeitlicher Betrachtung. Ein RPO beantwortet die Frage, bis zu welchem früheren Datenstand ein Unternehmen im Störungsfall zurückgehen könnte.

Die Zeitangabe allein reicht für eine sinnvolle Bewertung nicht aus. Der zuständige Fachbereich sollte zusätzlich klären:

• Welche Vorgänge müssten erneut erfasst werden?
• Lassen sich die fehlenden Informationen vollständig rekonstruieren?
• Welche Belege oder anderen Systeme wären dafür erforderlich?
• Wie hoch wären Arbeitsaufwand und Fehlerrisiko?
• Gibt es Tages- oder Saisonzeiten mit besonders wichtigen Änderungen?

Das Recovery Time Objective (RTO) ist das angestrebte Zeitfenster für die Wiederherstellung. Dafür müssen Anfang und Ende eindeutig definiert sein. Ein gestarteter Server ist nicht automatisch ein wiederhergestellter Dienst. Je nach Prozess müssen sich Beschäftigte anmelden, auf einen konsistenten Datenbestand zugreifen und erforderliche Schnittstellen verwenden können. Auch muss feststehen, ob zunächst ein begrenzter Notbetrieb genügt oder die volle Leistung benötigt wird.

Die maximal tolerierbare Ausfallzeit bezeichnet dagegen die geschäftliche Grenze, ab der die Auswirkungen nicht mehr akzeptabel sind. Sie ergibt sich aus der Betrachtung des Geschäftsprozesses. Das RTO ist ein daraus abgeleitetes Wiederherstellungsziel. Zwischen technischer Verfügbarkeit und der vollständigen Wiederaufnahme des Prozesses können weitere Arbeiten liegen – etwa fachliche Prüfungen oder das Abarbeiten aufgelaufener Vorgänge.

Beim Geschäftsprozess beginnen, nicht beim Server

Eine Systeminventarliste zeigt noch nicht, was zuerst wiederhergestellt werden muss. Ein wenig sichtbarer Basisdienst kann Voraussetzung für mehrere geschäftskritische Anwendungen sein. Umgekehrt muss ein großer Datenbestand nicht automatisch zeitkritisch sein.

Eine praktikable Reihenfolge für die Planung lautet:

1. Wichtige Geschäftsprozesse benennen.
2. Auswirkungen einer Unterbrechung über selbst gewählte Zeitstufen beschreiben.
3. Die Grenze bestimmen, ab der die Folgen nicht mehr tragbar sind.
4. Den maximal vertretbaren Datenverlust festlegen.
5. Anwendungen, Daten und Infrastruktur den Prozessen zuordnen.
6. Technische und organisatorische Abhängigkeiten dokumentieren.
7. Wiederanlaufreihenfolge sowie RPO und RTO festhalten.
8. Technische Umsetzbarkeit, Aufwand und bestehende Lücken gemeinsam prüfen.

Die Rollen sollten dabei klar bleiben: Geschäftsführung und Fachbereiche beurteilen, welche Folgen akzeptabel sind. Die IT bewertet Wiederherstellungswege, Abhängigkeiten und technische Möglichkeiten. Belastbare Ziele entstehen erst durch diese Abstimmung.

Auswirkungen in passenden Zeitstufen erfassen

Statt sofort eine Stundenzahl zu verlangen, sollte das Unternehmen die Folgen über passende Zeitstufen untersuchen. Diese können je nach Prozess unterschiedlich sein.

Für die Bewertung helfen konkrete Fragen:

• Welche Tätigkeiten stehen sofort still?
• Was kann vorübergehend manuell oder mit einem Ersatzverfahren erledigt werden?
• Ab wann sind Kunden, Lieferanten oder Geschäftspartner betroffen?
• Welche Rückstände entstehen, und wie lange dauert deren Aufarbeitung?
• Welche Mindestfunktionen, Daten, Standorte und Beschäftigten werden für einen Notbetrieb benötigt?

Die Tabelle gibt bewusst keine allgemeinen Stunden- oder Tageswerte vor. Ein Ersatzverfahren kann die Ausfallgrenze verändern, muss aber selbst realistisch vorbereitet und verfügbar sein.

Warum das Backup-Intervall noch kein RPO ist

Die Aussage „Unser Backup läuft täglich, daher beträgt unser RPO einen Tag“ greift zu kurz. Das Sicherungsintervall ist nur ein Planungswert. Für den tatsächlich erreichbaren Wiederherstellungspunkt kommt es außerdem darauf an,

• ob der Sicherungslauf erfolgreich abgeschlossen wurde,
• ob Fehler rechtzeitig erkannt werden,
• welcher Datenstand konsistent wiederherstellbar ist,
• ob die benötigte Sicherung nach dem Vorfall verfügbar bleibt,
• und ob der Wiederherstellungsweg praktisch funktioniert.

Aus dem RPO wird somit eine Anforderung an die Datensicherung abgeleitet. Erreicht wird sie erst, wenn ein Datenstand mit dem zulässigen Alter tatsächlich wiederhergestellt werden kann. Häufig geänderte Auftragsdaten können deshalb ein anderes RPO benötigen als selten veränderte Informationen innerhalb derselben Anwendung.

Abhängigkeiten bestimmen die wirkliche Wiederanlaufzeit

Eine Anwendung unterstützt ihren Geschäftsprozess erst, wenn ihre Voraussetzungen funktionieren. Zu prüfen sind insbesondere:

• Identitäten, Anmeldung und Berechtigungen,
• Netzwerkverbindungen und Speicher,
• Datenbanken und Anwendungskomponenten,
• externe Dienste und Schnittstellen,
• erforderliche Administrationszugänge und Wiederherstellungsinformationen.

Die zentrale Frage lautet: Welche Komponenten müssen bereits funktionieren, bevor dieses System fachlich nutzbar ist? Daraus ergibt sich die Wiederanlaufreihenfolge. Ein Basisdienst kann Vorrang vor der sichtbar wichtigsten Anwendung haben.

Für kleinere Umgebungen können wenige betriebsindividuelle Wiederanlaufklassen die Planung erleichtern: von sehr schnell geschäftskritischen Prozessen über begrenzten Notbetrieb bis zu Systemen, die nachrangig wiederhergestellt werden können. Die Klassen sind nur eine Arbeitshilfe. Sie ersetzen weder individuelle Zeitziele noch die Prüfung unterschiedlicher Datenbestände.

Entscheidungstabelle für Fachbereiche und IT

Die Ergebnisse lassen sich in einer gemeinsamen Tabelle dokumentieren:

Zuerst sollten Prozesse und Auswirkungen beschrieben werden, danach die Zeitziele. Ungeprüfte Werte sind als Annahmen zu kennzeichnen. Wenn betriebliche Anforderungen und technische Möglichkeiten auseinanderliegen, muss die Abweichung sichtbar dokumentiert werden, statt stillschweigend ein nicht erreichbares Ziel zu übernehmen.

Wenn die Ziele feststehen, können sie in ein Sicherungs- und Wiederherstellungskonzept übersetzt werden. netzmal beschreibt im Leistungsbereich Backup und Archivierung unter anderem lokale und cloudbasierte Sicherungen, getrennte Kopien, Microsoft-365-Backup und dokumentierte Wiederherstellungswege. Welche Umsetzung passt, hängt von den zuvor festgelegten RPO-, RTO- und Wiederanlaufanforderungen ab.

Wiederherstellungstests liefern den Realitätscheck

Ein erfolgreicher Sicherungslauf beweist weder das RPO noch das RTO. Dafür ist ein Wiederherstellungstest erforderlich. Das Testprotokoll sollte mindestens enthalten:

• getestetes System und getesteten Datenbestand,
• verwendeten Wiederherstellungspunkt und Alter der Daten,
• Beginn und Ende der einzelnen Schritte,
• benötigte Abhängigkeiten,
• Zeitpunkt der technischen Verfügbarkeit,
• Zeitpunkt der fachlichen Nutzbarkeit,
• Bestätigung durch den zuständigen Fachbereich,
• Abweichungen von RPO und RTO,
• vereinbarte Maßnahmen und Verantwortlichkeiten.

Nach Änderungen an Geschäftsprozessen, Anwendungen, Datenmengen oder technischen Abhängigkeiten ist eine erneute Bewertung sinnvoll. Einmal festgelegte Ziele gelten nicht automatisch dauerhaft.

Checkliste für die gemeinsame Abstimmung

• [ ] Die wichtigsten Geschäftsprozesse und ihre Verantwortlichen sind benannt.
• [ ] Auswirkungen längerer Unterbrechungen wurden über passende Zeitstufen beschrieben.
• [ ] Die maximal tolerierbare Ausfallzeit wurde für jeden wichtigen Prozess festgelegt.
• [ ] RPO und RTO wurden getrennt bewertet.
• [ ] Ersatzverfahren und benötigte Mindestfunktionen sind dokumentiert.
• [ ] Anwendungen, Daten und Infrastruktur wurden den Prozessen zugeordnet.
• [ ] Abhängigkeiten und Wiederanlaufreihenfolge sind festgehalten.
• [ ] Sicherungsverfahren und RPO-Anforderungen wurden abgeglichen.
• [ ] Das RTO endet bei einem fachlich nutzbaren Zustand, nicht nur beim Serverstart.
• [ ] Abweichungen zwischen gewünschtem und erreichbarem Ziel sind dokumentiert.
• [ ] Wiederherstellungstests, Maßnahmen und Zuständigkeiten sind eingeplant.

Die Methode ist eine kompakte Orientierung für KMU und ersetzt keine vollständige Business-Continuity-Management-Konzeption. Ein gewünschtes RPO oder RTO ist zunächst eine geschäftliche Anforderung; seine technische und organisatorische Erreichbarkeit muss geprüft werden. Der Beitrag bewertet keine Backup-Produkte, verspricht keine Wiederherstellungszeiten und behandelt keine rechtlichen Aufbewahrungs- oder Archivierungspflichten.