Was ist Disaster Recovery (RTO und RPO)?

Disaster Recovery: Definition und Ziele

Disaster Recovery (DR) beantwortet die Frage: Was tun wir, wenn die IT ausfällt und der Normalbetrieb nicht schnell zurückkehrt? Ursachen reichen von Ransomware-Angriffen über Hardwaredefekte und Fehlbedienung bis zu Brand, Wasserschaden oder dem Ausfall eines Rechenzentrums. Ein DR-Plan legt fest, welche Systeme in welcher Reihenfolge, durch wen und wie wiederhergestellt werden.

Er ist Teil des Notfall- und Kontinuitätsmanagements (Business Continuity) und ergänzt Backup und Hochverfügbarkeit: Hochverfügbarkeit fängt Teilausfälle ab, das Backup liefert die Daten, Disaster Recovery organisiert die Rückkehr zum Betrieb als Ganzes – mit klaren Zielen, einer festen Reihenfolge, benannten Verantwortlichen und regelmäßig geübten Abläufen.

RTO und RPO: die zwei Kennzahlen

Die Recovery Time Objective (RTO) ist die Zeitspanne, in der ein System nach einem Ausfall wieder laufen muss. Die Recovery Point Objective (RPO) legt fest, wie viel Datenverlust zeitlich tolerierbar ist. Wird einmal nachts gesichert, beträgt die RPO bis zu 24 Stunden: Alles, was seit der letzten Sicherung geschah, wäre verloren.

Beide Werte leiten sich aus einer Analyse ab, was Ausfälle das Unternehmen kosten (Business Impact Analysis). Je kürzer RTO und RPO, desto aufwendiger die Technik: von einfachem Backup und Neuaufbau über ein vorbereitetes Reservesystem bis zu laufender Datenspiegelung an einen zweiten Standort.

Praxis­bei­spiel: Maschi­nen­bauer nach einem Ransomware-Angriff

Ein Maschinenbauunternehmen wird Opfer eines Verschlüsselungsangriffs: ERP, Dateiserver und Produktionsplanung stehen still. Das Unternehmen hat zwar nächtliche Backups, aber nie einen Wiederanlauf geübt. Unklar ist, in welcher Reihenfolge Systeme starten müssen, wo die Installationsmedien liegen und ob die Sicherungen selbst unversehrt sind.

Danach legt es Ziele fest: ERP mit einer RTO von acht Stunden und einer RPO von einer Stunde, übrige Systeme später. Sicherungen werden zusätzlich unveränderbar an einem getrennten Ort abgelegt, ein Wiederanlauf-Handbuch wird geschrieben und zweimal im Jahr geübt. Aus einem vagen Vorsatz wird ein belastbares Verfahren.

Typische Fehler und Umsetzung

Häufigste Fehler: Backups, die nie getestet wurden, Sicherungen im selben Netz wie die Produktivsysteme, fehlende Priorisierung und ein Plan, der nur auf dem ausgefallenen System liegt. Ebenso fehlen oft Kontaktlisten und Entscheidungswege. Ein DR-Plan ist nur so gut wie seine letzte erfolgreiche Übung.

Nano Concepts unterstützt bei Analyse, Zielwerten und Architektur: von Backup-Konzept und Cloud-Wiederherstellung über Wiederanlaufpläne bis zu Übungen. So wissen Sie vor dem Ernstfall, was Ihr Betrieb tatsächlich aushält und wie schnell er wieder läuft, und können Investitionen in Schutzmaßnahmen sachlich begründen.

• Systeme nach Geschäftsbedeutung priorisieren und RTO und RPO je System festlegen
• Sicherungen offline oder unveränderbar und räumlich getrennt aufbewahren
• Wiederherstellung regelmäßig testen, nicht nur die Sicherung
• Wiederanlaufplan und Kontaktliste außerhalb der eigenen IT griffbereit halten
• Zuständigkeiten für den Notfall benennen