Eine Backup-Strategie beginnt nicht bei der Kapazität eines Mediums oder beim Namen einer Software. Sie beginnt mit einer fachlichen Entscheidung: Welche Daten dürfen nach einem Ausfall höchstens fehlen und wie lange darf ein Geschäftsprozess nicht nutzbar sein? RPO und RTO machen diese Entscheidung greifbar. Erst danach lässt sich prüfen, welche Sicherungsfrequenz, Rotation und Wiederherstellungsumgebung dazu passen.
Für ein KMU müssen die Ziele nicht kompliziert sein. Sie dürfen aber auch nicht ungeprüft von anderen Unternehmen übernommen werden. Eine Auftragsbearbeitung und ein selten genutztes Archiv haben unterschiedliche Folgen bei Datenverlust und Unterbrechung.
Zwei Begriffe, zwei Entscheidungen
Der RPO (*Recovery Point Objective*) beschreibt den Zeitpunkt, bis zu dem Daten nach einer Unterbrechung wiederhergestellt werden müssen. Praktisch beantwortet er die Frage, wie alt der wiederhergestellte Datenstand höchstens sein darf und welche kürzlich erfassten Informationen notfalls nachgearbeitet werden könnten.
Der RTO (*Recovery Time Objective*) beschreibt die maximal akzeptable Zeit bis ein Dienst wieder nutzbar ist. Dazu zählt mehr als das Zurückspielen von Daten: Vorfall erkennen, Wiederanlauf freigeben, den passenden Sicherungssatz finden, Hardware und Berechtigungen vorbereiten, Abhängigkeiten starten und die fachliche Nutzbarkeit bestätigen.
Ein niedrigeres Ziel für Datenverlust oder Unterbrechung kann höhere Frequenz, mehr Vorbereitung und einen komplexeren Betrieb erfordern. Deshalb werden RPO und RTO aus der Auswirkung auf das Geschäft abgeleitet und gegen Aufwand und Kosten abgewogen.
Nicht bei Systemen, sondern bei Prozessen beginnen
Setzen Sie sich mit den Verantwortlichen der drei bis fünf Funktionen zusammen, deren Ausfall Umsatz, Kundenservice, Produktion oder eine wichtige Verpflichtung unmittelbar blockiert. Fragen Sie nicht zuerst nach Servern, sondern nach Folgen:
- Welche Auswirkung hätte ein Ausfall nach einer Stunde, einem halben Tag oder einem ganzen Tag?
- Welche seit dem letzten Wiederherstellungspunkt erfassten Daten müssten neu erstellt werden?
- Welche Anwendungen, Daten, Konfigurationen, Zugänge und Geräte sind für die Rückkehr nötig?
- Wer bestätigt, dass der Prozess wieder arbeitsfähig ist?
So werden Abhängigkeiten sichtbar. Ein Datenbestand kann technisch vorhanden sein, während der Prozess weiter stillsteht, weil eine Anwendung, ein Benutzerzugang, eine Schnittstelle oder eine Betriebsanweisung fehlt. Der RTO umfasst diesen ganzen Weg.
Mit wenigen Klassen arbeiten
Eine kleine Organisation braucht nicht für jede Datei ein eigenes Ziel. Häufig genügen zwei oder drei verständliche Klassen, etwa kritisch, wichtig und verschiebbar. Jede Klasse erhält einen vorläufigen RPO, einen RTO, eine fachlich verantwortliche Person und einen Wiederherstellungstest.
Dadurch entstehen nachvollziehbare Prioritäten. Ein kritischer Prozess kann häufigere Wiederherstellungspunkte und einen vorbereiteten Ablauf rechtfertigen. Ein verschiebbarer Dienst darf nach den Kernprozessen zurückkommen. Das ist keine Rangliste der Technik, sondern eine transparente Zuordnung von Aufwand zu Geschäftsauswirkung.
Ziele in Anforderungen übersetzen
Der RPO beeinflusst, wie oft ein nutzbarer Datenstand verfügbar sein muss. Dabei müssen auch manuelle Eingaben, Exporte, Anwendungsprotokolle und Informationen außerhalb des üblichen Backup-Umfangs betrachtet werden.
Der RTO beeinflusst den gesamten Wiederanlauf: Datenmenge, Reihenfolge der Abhängigkeiten, Verfügbarkeit eines geeigneten Mediums, Zugriff auf eine getrennte Kopie, Ersatzhardware, Berechtigungen, Backup-Software und fachliche Abnahme. Erst jetzt werden die technischen Fragen sinnvoll: Wie viele Sicherungssätze müssen gleichzeitig verfügbar sein? Wann muss eine Kopie extern oder offline liegen? Welche Reserve verhindert einen Bruch der Rotation? Welche Kapazität passt mit ausreichender Reserve?
Ein Wechselmedium kann Teil einer getrennten Kopie sein. Es garantiert aber weder einen bestimmten RPO noch einen bestimmten RTO. Die konkrete Architektur wird immer gegen die definierten Ziele im realen Umfeld geprüft.
Ein fiktives Beispiel als Denkmodell
Nehmen wir an, die Auftragsbearbeitung eines KMU hängt von einer Anwendung und den zugehörigen Daten ab. Der Fachbereich akzeptiert, dass höchstens zwei Stunden Auftragserfassung nacherfasst werden müssen. Nach der Entscheidung zum Wiederanlauf soll der Dienst innerhalb von vier Stunden wieder nutzbar sein. Daraus entstehen als Arbeitsannahmen ein RPO von zwei Stunden und ein RTO von vier Stunden.
Die IT leitet daraus keine automatische Produktauswahl ab. Sie misst einen repräsentativen Sicherungssatz, erfasst alle Abhängigkeiten, bestimmt die verfügbare Kopie und testet den vollständigen Wiederanlauf. Dauern Rückholung des Mediums, Vorbereitung und Wiederherstellung zusammen länger als vier Stunden, wird das Ziel nicht erreicht. Dann werden Ablauf, Mittel oder die mit dem Fachbereich abgestimmte Zielsetzung angepasst.
Ein Dokumentenarchiv kann hingegen einen Datenstand vom Vortag und eine längere Unterbrechung tolerieren. Die abweichende Behandlung ist keine Lücke, sondern eine dokumentierte Entscheidung anhand der unterschiedlichen Wirkung.
Entscheidungstabelle für Gutenberg
Die Tabelle kann als Gutenberg-Block oder in einem internen Workshop verwendet werden. Sie hält Annahmen und späteren Nachweis fest, nicht ein pauschales Service-Level-Agreement.
| Geschäftsprozess | Auswirkung bei Ausfall | RPO-Ziel | RTO-Ziel | Wiederherstellungsabhängigkeiten | Fachliche Verantwortung | Letzter Test |
|---|---|---|---|---|---|---|
| Auftragsbearbeitung | Beispiel: Kundenservice blockiert | Festlegen | Festlegen | Anwendung, Daten, Zugänge | Benennen | Nach Test eintragen |
| Dokumentenarchiv | Beispiel: Zugriff verschiebbar | Festlegen | Festlegen | Daten, Suche, Berechtigungen | Benennen | Nach Test eintragen |
Überprüfen Sie die Werte, wenn sich Prozesse, Datenmenge, Lieferanten, Anwendungen oder Verantwortlichkeiten ändern. Ein Ziel ohne Verantwortliche und ohne Testergebnis bleibt eine Annahme.
Der Restore-Test liefert den Nachweis
Ein angenommener RPO wird geprüft, indem ein repräsentativer Punkt wiederhergestellt und sein Datenalter mit der vereinbarten Toleranz verglichen wird. Ein angenommener RTO wird geprüft, indem der gesamte Weg von der Auslöseentscheidung bis zur fachlichen Abnahme gemessen wird. Berücksichtigen Sie auch eine Vertretung oder die Rückholung einer getrennt verwahrten Kopie.
Verfehlt der Test das Ziel, wird die Ursache gesucht: zu geringe Sicherungsfrequenz, zu großer Satz, nicht verfügbares Medium, übersehene Abhängigkeit, fehlende Zugriffsrechte oder ein ungeübter Ablauf. Danach entscheiden Fachbereich und IT gemeinsam, ob die Wiederanlauffähigkeit verbessert oder das Ziel neu begründet wird.
Die Checkliste für Wiederherstellungstests und die 3-2-1-1-0-Regel ergänzen das Vorgehen. Die Beiträge zur Medienberechnung und zu RDX/LTO werden nach ihrer Veröffentlichung in dieser Sprache verlinkt. Wenn die Ziele eine konkrete Architektur erfordern, kann der Leser ein Projekt mit Tandberg Data fachlich abgrenzen.
Diesen Leitfaden teilen
