RPO und RTO in IT und Produktion

RPO (Recovery Point Objective) definiert, wie viel Datenverlust nach einem Systemausfall maximal akzeptabel ist – gemessen in Zeit zwischen dem letzten Backup und dem Ausfallzeitpunkt. RTO (Recovery Time Objective) definiert, wie lange ein System maximal ausfallen darf, bevor der Geschäftsbetrieb kritisch beeinträchtigt wird – gemessen von Ausfall bis zur vollständigen Wiederherstellung.

Warum diese zwei Kennzahlen nicht optional sind

Beide Werte stammen aus dem Business Continuity Management (BCM) und sind in regulierten Industrien keine theoretischen Planungsgrößen. Wer Systeme wie ein MES, ein ERP oder eine Qualitätsdatenplattform betreibt, ohne RPO und RTO schriftlich definiert zu haben, hat de facto keine Disaster-Recovery-Strategie – er hat nur die Hoffnung, dass nichts passiert.

In der Fertigung ist die Abhängigkeit von IT-Systemen heute so hoch, dass ein unerwarteter Systemausfall innerhalb von Minuten zu Maschinenstillstand, fehlender Rückmeldung, Produktionsblindflug und Compliance-Risiken führt. Qualitätsprotokolle, Chargendaten, Auftragsstatus und OEE-Werte – all das liegt heute im System, nicht mehr im Kopf des Schichtleiters.

Recovery Point Objective (RPO) im Detail

Der RPO beantwortet eine einzige, aber kritische Frage: Wie alt dürfen die Daten nach der Wiederherstellung maximal sein?

Ein RPO von 15 Minuten bedeutet: Im schlimmsten Fall gehen 15 Minuten an Produktions-, Auftrags- oder Qualitätsdaten verloren. Ein RPO von 24 Stunden bedeutet: Im schlimmsten Fall ist ein kompletter Arbeitstag an Daten weg.

Je kleiner der RPO, desto höher die technischen Anforderungen. Ein RPO unter einer Stunde ist mit klassischen Nacht-Backups nicht erreichbar – er erfordert kontinuierliche Replikation oder synchrone Datensicherung in Echtzeit. In Produktionsumgebungen betrifft das konkret:

• Maschinendaten und Prozessparameter
• OEE-Werte und Verfügbarkeitsprotokolle
• Qualitätsprüfungen und Messergebnisse
• Serien- und Chargennummern für die Traceability
• Auftragsstatus und Fertigungsfortschritt

Recovery Time Objective (RTO) im Detail

Der RTO beantwortet eine ebenso kritische Frage: Wie lange darf das System maximal ausfallen, bevor der Schaden nicht mehr kontrollierbar ist?

Ein RTO von 30 Minuten bedeutet: Produktion, Leitstand oder Datenplattform müssen spätestens nach einer halben Stunde wieder produktiv laufen. Ein RTO von 8 Stunden bedeutet: Ein halber Arbeitstag Ausfall gilt als tolerierbar.

Was ein zu hoher RTO in der Produktion konkret auslöst:

RPO und RTO gemeinsam denken – die entscheidende Wechselwirkung

Hier liegt das häufigste Missverständnis in der Praxis: Viele Unternehmen optimieren nur eine der beiden Kennzahlen.

Ein niedriger RPO ohne niedrigen RTO bedeutet: Die Daten sind zwar gut gesichert und aktuell – aber die Produktion steht trotzdem stundenlang still, weil die Wiederherstellung des Systems zu lange dauert. Alle gesicherten Daten nützen nichts, wenn die Plattform nicht läuft.

Ein niedriger RTO ohne niedrigen RPO bedeutet: Das System ist zwar schnell wieder online – aber mit einem Datenstand von vor acht Stunden. Qualitätsprotokolle fehlen, Auftragsstatus ist veraltet, Traceability ist lückenhaft.

Beide Kennzahlen müssen aufeinander abgestimmt und gemeinsam gegen die Geschäftsrisiken kalibriert werden. Die entscheidende Frage lautet: Was kostet eine Stunde Ausfall? Was kostet eine Stunde verlorener Daten? Die Antwort auf diese Fragen liefert die wirtschaftliche Grundlage für jede technische Entscheidung.

Typische Zielwerte nach Systemkritikalität

Diese Werte sind keine Normen, sondern Orientierungswerte aus der Fertigungspraxis. Der tatsächliche Zielwert hängt vom Produktionstakt, der Kundenanforderung und dem Automatisierungsgrad ab.

Praxisbeispiel: Ransomware-Angriff in einem Automotive-Zulieferer

Ein Tier-1-Zulieferer wird Freitagabend um 22:00 Uhr Opfer eines Ransomware-Angriffs. Die MES-Datenbank wird verschlüsselt. Die Frühschicht startet Montag um 06:00 Uhr.

Szenario A – kein definierter RPO/RTO, Backup läuft einmal täglich: Das IT-Team stellt fest, dass das letzte Backup von Freitagmorgen 02:00 Uhr stammt. Fast 20 Stunden Produktionsdaten sind verloren. Die Wiederherstellung dauert wegen fehlender Notfallprozedur bis Montagmittag – 14 Stunden nach Schichtstart. Qualitätsprotokolle der Freitagsproduktion existieren nicht mehr, eine lückenlose Traceability für bereits versandte Teile ist nicht herstellbar. Das Ergebnis: Lieferstopp, Kundeneskalation, potenzielle Rückrufprüfung.

Szenario B – RPO 15 Minuten, RTO 1 Stunde, High-Availability-Architektur: Das System erkennt den Angriff automatisch und isoliert die betroffenen Knoten. Die Replikation auf ein isoliertes Backup-System hat um 21:45 Uhr zuletzt gespeichert. Bis 23:00 Uhr ist das System auf dem Standby-System wiederhergestellt. Montagmorgen läuft die Produktion planmäßig an. Datenverlust: 15 Minuten. Ausfallzeit: unter eine Stunde.

Praxis-Warnung: SLA ≠ RTO

Ein häufiger Fehler bei der Auswahl von Software-Anbietern: Der Anbieter garantiert eine SLA (Service Level Agreement) von 99,9 % Verfügbarkeit – das klingt gut, bedeutet aber bis zu 8,7 Stunden Ausfall pro Jahr. Diese 8,7 Stunden können in einem einzigen Ereignis auftreten. Wenn der RTO des Unternehmens bei 1 Stunde liegt, ist eine 99,9%-SLA keine ausreichende Garantie. Die relevante Vertragsklausel ist die maximale Single-Incident-Downtime, nicht die jährliche Gesamtverfügbarkeit.

FAQ: RPO und RTO in der Fertigungspraxis

1. Müssen RPO und RTO für alle Systeme gleich sein? Nein – und das ist der Kerngedanke des Business Impact Analysis (BIA)-Prozesses. Kritische Produktionssysteme benötigen deutlich niedrigere Werte als Archiv- oder Reporting-Systeme. Eine einheitliche Strategie für alle Systeme ist in der Regel entweder zu teuer oder zu riskant.

2. Welche Norm schreibt RPO und RTO vor? ISO 22301 (Business Continuity Management) definiert den Rahmen, in dem RPO und RTO als Recovery Time Objective bzw. Recovery Point Objective formalisiert werden. Im OT-Umfeld sind zudem IEC 62443 und für kritische Infrastrukturen NIS2 relevant, die explizit Wiederherstellungsanforderungen für Produktionssysteme adressieren.

3. Was kostet eine Stunde Produktionsausfall konkret? Das ist branchenabhängig, aber in der Automotive-Fertigung werden Bandstillstandskosten bei OEMs häufig mit 10.000–50.000 € pro Stunde beziffert. Bei Tier-1-Lieferanten liegt der Wert je nach Liefervertrag und Strafklauseln ebenfalls schnell im fünfstelligen Bereich. Diese Zahl ist der wichtigste Input zur Kalkulation des wirtschaftlich sinnvollen Investitionsaufwands für niedrige RPO/RTO-Werte.

4. Wie testet man, ob der RTO realistisch ist? Durch einen Disaster-Recovery-Test (DR-Test) – mindestens einmal jährlich. Viele Unternehmen haben RTO-Zielwerte dokumentiert, die noch nie unter realen Bedingungen gemessen wurden. Ein DR-Test zeigt, ob die definierten Werte mit der tatsächlichen Infrastruktur erreichbar sind oder nur auf dem Papier existieren.

5. Wie hängen RPO, RTO und High Availability zusammen? High Availability (HA)-Architekturen mit redundanten Systemen und automatischem Failover sind die technische Voraussetzung für sehr niedrige RTO-Werte (< 5 Minuten). Kontinuierliche Datenreplikation ist die Voraussetzung für sehr niedrige RPO-Werte. Wer beides erreichen will, braucht beides – eine HA-Architektur allein sichert keine Daten, und häufige Backups allein sichern keine schnelle Wiederherstellung.

Strategischer Mehrwert

Klar definierte RPO- und RTO-Werte sind keine IT-Hausaufgabe – sie sind eine unternehmerische Entscheidung darüber, welches Risiko bewusst akzeptiert wird. Wer diese Entscheidung nicht trifft, trifft sie trotzdem: implizit, mit unbekannten Konsequenzen. In regulierten Fertigungsumgebungen mit Traceability-Pflicht, OEM-Lieferbindung und zunehmender Cyberbedrohungslage ist das keine akzeptable Position.