RPO und RTO: Wie Sie realistische Werte für Datenverlust und Ausfallzeit festlegen

Auf die Frage, wie viele Daten verloren gehen dürfen, ist die naheliegende Antwort „keine“. Auf die Frage, wie lange ein Ausfall dauern darf, lautet sie „gar nicht“. Beides lässt sich bauen, kostet aber ein Vielfaches einer normalen Sicherung. Deshalb legen wir bei Backup & Wiederherstellung mit jedem Kunden zwei Werte fest, bevor wir die Sicherung einrichten. Hier beschreiben wir, woraus sich diese Werte ergeben, mit Beispielen aus unserer eigenen Sicherung.

Die zwei Begriffe

• RPO (Recovery Point Objective): Wie viele Daten dürfen höchstens verloren gehen? Gemessen als Zeitraum: Ein RPO von 24 Stunden heißt, dass im schlimmsten Fall die Arbeit eines Tages fehlt.
• RTO (Recovery Time Objective): Wie lange darf es höchstens dauern, bis ein System nach einem Ausfall wieder läuft?

Beide Werte gelten pro System, nicht für die ganze IT. Das ERP braucht andere Werte als ein Testserver.

Das RPO folgt aus dem Sicherungsintervall

Wird einmal pro Nacht gesichert, liegt das RPO bei bis zu 24 Stunden. Fällt das System kurz vor der nächsten Sicherung aus, fehlt fast ein ganzer Tag. Wer weniger verlieren will, muss häufiger sichern oder die Daten laufend auf ein zweites System replizieren.

Unsere eigenen Proxmox-Cluster sichern wir jede Nacht vollständig. Für die meisten unserer Systeme ist ein Tag Datenverlust im schlimmsten Fall vertretbar, weil sich die Konfiguration aus Code wiederherstellen lässt und die wichtigen Daten an anderer Stelle zusätzlich gesichert sind.

Die Kopie außer Haus hat ein eigenes RPO

Das wird oft übersehen. Unsere nächtlichen Sicherungen landen zuerst auf einem Backup-Cluster im eigenen Rechenzentrum. Um 5 Uhr morgens werden sie verschlüsselt an zwei externe Standorte kopiert.

Bei einem defekten Server stellen wir aus der Sicherung im Haus wieder her, das RPO liegt bei bis zu einem Tag. Fällt das ganze Rechenzentrum aus, zählt die externe Kopie. Die ist im schlimmsten Fall älter: Eine Sicherung vom Abend kommt erst am nächsten Morgen außer Haus. Wer ein RPO festlegt, sollte es deshalb für beide Fälle festlegen, den Ausfall eines Systems und den Verlust des Standorts.

Ein RPO, das niemand überwacht, gilt nicht

Ein RPO von 24 Stunden ist nur so lange eingehalten, wie die Sicherung auch jede Nacht läuft. Wir haben deshalb einen Alarm, der auslöst, wenn die letzte Sicherung einer Gruppe älter als 26 Stunden ist. Fällt eine nächtliche Sicherung aus, merken wir das am nächsten Morgen, nicht erst, wenn wir etwas zurückholen wollen.

Die Aufbewahrung ist dabei etwas anderes. Wir behalten 7 tägliche, 4 wöchentliche, 6 monatliche und eine jährliche Sicherung. Das bestimmt, wie weit wir zurückgehen können, etwa wenn ein Fehler oder ein Verschlüsselungstrojaner erst nach Wochen auffällt. Wie aktuell die neueste Sicherung ist, sagt die Aufbewahrung nicht.

Das RTO besteht aus mehr als dem Zurückspielen

Die Wiederherstellung selbst ist nur ein Teil der Ausfallzeit. Dazu kommen:

1. bemerken, dass etwas ausgefallen ist
2. entscheiden, ob repariert oder wiederhergestellt wird
3. Hardware oder ein Ersatzziel bereitstellen
4. die Daten dorthin übertragen
5. Systeme in der richtigen Reihenfolge starten
6. prüfen, ob alles wieder funktioniert

Für Schritt 5 braucht es eine festgelegte Wiederanlauf-Reihenfolge: Netzwerk vor Verzeichnisdienst, Verzeichnisdienst vor Datenbank, Datenbank vor Fachanwendung. Fehlt sie, wird der Wiederanlauf zur Improvisation. Mehr dazu in Backup erfolgreich, Wiederherstellung gescheitert.

Oft bestimmt die Leitung die Ausfallzeit

Schritt 4 wird am häufigsten unterschätzt. Eine kurze Rechnung: 5 TiB über eine Verbindung mit 1 Gbit/s dauern selbst bei voller Auslastung rund 12 Stunden. Das haben wir selbst erlebt, als wir die erste Vollsicherung von gut 5 TiB über unser 1-Gbit-Verwaltungsnetz auf den Backup-Cluster übertragen haben: Sie lief über Nacht.

Bei einer Wiederherstellung aus der externen Kopie über eine Internetleitung wird es länger. Bei 250 Mbit/s dauert dieselbe Datenmenge rechnerisch etwa zwei Tage, bevor überhaupt das erste System startet. Wer ein RTO von vier Stunden für alle Daten verlangt, braucht deshalb entweder eine schnellere Anbindung oder ein vorbereitetes Ersatzsystem dort, wo die Kopie liegt.

Ohne Schlüssel kein RTO

Verschlüsselte Sicherungen sind richtig, aber ohne Schlüssel ist die Ausfallzeit unendlich. Bei uns liegt pro Cluster ein eigener Schlüssel verschlüsselt im Code-Repository, zusätzlich gehört eine Offline-Kopie außerhalb von Repository und Cluster dazu. Ohne diese Kopie wären die Sicherungen eines Clusters bei Verlust von Repository und Cluster nicht mehr lesbar.

Gemessen ist besser als geschätzt

Ein RTO ist so lange eine Vermutung, bis eine Wiederherstellung es bestätigt hat. Wir testen unsere Sicherungen nach festem Turnus: Proxmox-Sicherungen jedes Quartal abwechselnd je Cluster, die übrigen Sicherungen halbjährlich, und einmal im Jahr eine vollständige Wiederherstellung aus der externen Kopie auf ein neues System. Wiederhergestellt wird immer auf ein Wegwerf-Ziel, nie über ein produktives System.

Unsere bisherigen Tests haben die Kette geprüft: Die Sicherung ließ sich lesen, entschlüsseln und als Dateisystem einbinden. Eine gemessene Dauer für die Wiederherstellung eines ganzen Clusters liefert erst der jährliche Volltest. Bis dahin ist unsere eigene Zahl dafür eine Schätzung, und so behandeln wir sie auch.

So legen Sie die Werte fest

1. Systeme auflisten und jedem einen Verantwortlichen aus dem Fachbereich zuordnen.

2. Pro System fragen: Was kostet ein Tag Datenverlust? Was kostet ein Tag Stillstand? Die Antwort kommt aus dem Fachbereich, nicht aus der IT.

3. In wenige Klassen einteilen, zum Beispiel:

   Klasse	Beispiel	RPO	RTO
   kritisch	ERP, Warenwirtschaft	Stunden	unter einem Arbeitstag
   wichtig	Fileserver, E-Mail-Archiv	1 Tag	1–2 Arbeitstage
   unkritisch	Test- und Altsysteme	1 Tag oder mehr	eine Woche

   Die Werte in der Tabelle sind ein Beispiel, keine Empfehlung für Ihre Umgebung.

4. Mit der Technik abgleichen: Lässt sich das gewünschte RPO mit dem Sicherungsintervall erreichen? Reicht die Leitung für das RTO? Wenn nicht, gibt es zwei Wege: mehr investieren oder die Erwartung anpassen. Beides ist eine Entscheidung der Geschäftsführung.

5. Aufschreiben und testen: Die Werte gehören in den Wiederanlaufplan, und eine Probe-Wiederherstellung zeigt, ob sie stimmen.

---

Im Backup- & Wiederanlauf-Check prüfen wir Ihre Sicherungen gegen genau diese Fragen und stellen zur Probe einen Dienst wieder her, mit gemessener Dauer. Wie wir Sicherung und Wiederanlauf einrichten, steht unter Backup & Wiederherstellung.