Backup ist nicht Restore: RPO, RTO und Wiederherstellungstests in der Praxis

Fast jedes Unternehmen hat Backups. Deutlich weniger Unternehmen wissen, wie lange eine vollständige Wiederherstellung dauert, wer sie durchführt und ob sie überhaupt funktioniert. Genau diese Lücke wird im Störfall sichtbar, also zu dem Zeitpunkt, an dem niemand mehr Zeit für Experimente hat. Dieser Beitrag beschreibt, welche Kennzahlen eine Backup-Strategie tragfähig machen und wie ein Wiederherstellungstest konkret aussieht.

Warum Backups oft nur auf dem Papier existieren

Ein Backup-Job, der grün meldet, sagt zunächst nur: Es wurden Daten geschrieben. Er sagt nichts darüber, ob diese Daten konsistent sind, ob sie lesbar sind und ob alle relevanten Bestandteile eines Systems enthalten sind. Typische Fälle aus der Praxis sind Datenbank-Dumps, die während eines Schreibvorgangs entstanden sind, Sicherungen ohne die zugehörige Konfiguration oder Archive, deren Verschlüsselungsschlüssel nur auf dem gesicherten System lag.

Der zweite blinde Fleck ist der Zeitfaktor. Eine Sicherung, die 200 Gigabyte über eine Leitung mit begrenzter Bandbreite zurückspielt, braucht Stunden. Kommt die Neuinstallation des Betriebssystems, das Einrichten der Dienste und das Nachziehen von DNS-Einträgen hinzu, entsteht schnell ein Ausfall von einem Arbeitstag oder mehr. Ob das akzeptabel ist, muss vorher entschieden werden, nicht während der Störung.

RPO und RTO: zwei Zahlen, die alles bestimmen

Bevor Sie über Software, Speicherziele und Aufbewahrungszeiten sprechen, brauchen Sie zwei Vorgaben pro System. Sie sind eine Geschäftsentscheidung, keine technische.

RPO: wie viele Daten dürfen verloren gehen

Das Recovery Point Objective beschreibt den maximal tolerierbaren Datenverlust, gemessen in Zeit. Ein nächtliches Backup bedeutet ein RPO von bis zu 24 Stunden. Für ein Dateiarchiv ist das oft unproblematisch. Für ein Warenwirtschafts- oder Ticketsystem, in dem tagsüber laufend gebucht wird, ist es meist zu viel. Dort helfen kürzere Intervalle oder eine kontinuierliche Sicherung der Transaktionsprotokolle der Datenbank.

RTO: wie lange darf der Ausfall dauern

Das Recovery Time Objective ist die maximal tolerierbare Ausfalldauer bis zur Wiederaufnahme des Betriebs. Das RTO entscheidet über die Architektur: Ein Ziel von vier Stunden lässt sich mit einem dokumentierten Restore aus dem Backup erreichen, wenn Zielsystem und Automatisierung bereitstehen. Ein Ziel von 15 Minuten erfordert Bereitstellung im Voraus, also Replikation, ein zweites laufendes System oder Snapshots auf der Virtualisierungsebene.

Beide Werte werden pro Anwendung festgelegt, nicht pauschal für das ganze Unternehmen. Es ist völlig normal, dass ein Shop ein RTO von zwei Stunden hat und ein internes Wiki eines von zwei Tagen. Genau diese Abstufung verhindert, dass alles teuer abgesichert wird.

Die 3-2-1-Regel und was heute dazugehört

Die Grundregel bleibt sinnvoll: drei Kopien der Daten, auf zwei unterschiedlichen Medien oder Systemen, eine davon an einem anderen Standort. Sie schützt gegen Hardwaredefekt, Brand und Bedienfehler. Gegen Ransomware schützt sie nur eingeschränkt, denn wer Administrationsrechte erlangt, löscht auch erreichbare Backups.

Deshalb kommen zwei Anforderungen hinzu. Erstens eine unveränderliche Kopie, die für einen definierten Zeitraum nicht gelöscht oder überschrieben werden kann, etwa über Object Lock auf S3-kompatiblem Speicher oder ein Ziel, auf das nur schreibend zugegriffen wird. Zweitens getrennte Zugangsdaten: Das Backup-Ziel darf nicht mit denselben Anmeldedaten erreichbar sein wie die Produktionsumgebung.

Erst der erfolgreich getestete Restore macht aus einer Datensicherung eine Notfallvorsorge. Alles davor ist eine Annahme mit Speicherverbrauch.

Was in ein Backup gehört und regelmäßig fehlt

Nutzdaten sind der offensichtliche Teil. Für eine vollständige Wiederherstellung braucht es mehr, und dieser Teil wird häufig übersehen:

• Datenbanken als konsistente Sicherung, also als logischer Dump oder über einen Snapshot mit passendem Verfahren, nicht als Dateikopie des laufenden Datenverzeichnisses
• Konfiguration der Dienste: Webserver, Reverse Proxy, Cronjobs, Firewall-Regeln, Systemdienste
• Zertifikate und Schlüssel, soweit sie nicht automatisiert neu ausgestellt werden können
• Secrets wie API-Schlüssel und Datenbankpasswörter, getrennt und verschlüsselt abgelegt, nicht ausschließlich im gesicherten System
• DNS-Zonen und die Information, wo sie verwaltet werden
• Lizenzinformationen und Zugänge zu externen Diensten, die für den Betrieb nötig sind

Ebenso wichtig ist die Frage, was bewusst nicht gesichert wird. Caches, temporäre Dateien und Abbilder, die sich jederzeit neu erzeugen lassen, blähen Sicherungen auf und verlängern die Wiederherstellung.

Der Wiederherstellungstest

Ein Test ist kein Stichwort im Protokoll, sondern ein Ablauf mit Ergebnis. Bewährt hat sich folgendes Vorgehen, ein bis zwei Mal pro Jahr je kritischem System, zusätzlich nach größeren Änderungen an der Architektur.

1. Szenario festlegen: vollständiger Verlust eines Servers, nicht nur eine einzelne gelöschte Datei
2. Auf einem separaten Zielsystem wiederherstellen, niemals in die Produktion
3. Die Zeit messen, vom Start bis zum funktionsfähigen Dienst, inklusive Wartezeiten
4. Fachlich prüfen: Anmeldung möglich, letzte Buchungen vorhanden, Anhänge lesbar, Schnittstellen erreichbar
5. Den tatsächlich erreichten Datenstand mit dem geplanten RPO vergleichen
6. Abweichungen und Stolperstellen dokumentieren und die Anleitung korrigieren

Der erste Test dauert fast immer länger als erwartet. Das ist der eigentliche Gewinn: Sie erfahren es an einem ruhigen Dienstagmorgen und nicht während eines Ausfalls. Häufige Erkenntnisse sind fehlende Paketversionen, ein Zugang, den nur eine Person kennt, oder eine Anleitung, die auf einem Wiki liegt, das ebenfalls ausgefallen ist.

Restore-Anleitung offline verfügbar halten

Die Wiederherstellungsanleitung muss unabhängig von der betroffenen Infrastruktur erreichbar sein, im Zweifel als Ausdruck oder als Datei auf einem getrennten Speicher. Sie enthält Reihenfolge der Schritte, Zugangswege, Ansprechpartner und die Kontakte des Dienstleisters.

Aufbewahrung, Löschfristen und Verantwortung

Backups unterliegen der DSGVO wie jeder andere Datenbestand. Personenbezogene Daten dürfen nicht unbegrenzt in Archiven weiterleben, gleichzeitig kollidieren Löschanfragen praktisch mit gestaffelten Sicherungsketten. Ein pragmatischer Umgang: klar definierte, endliche Aufbewahrungszeiten pro Backup-Stufe, dokumentiert im Verzeichnis der Verarbeitungstätigkeiten, und die Regel, dass gelöschte Daten nach einem Restore erneut entfernt werden. Wird die Sicherung von einem Dienstleister betrieben, gehört sie in den Auftragsverarbeitungsvertrag, einschließlich Speicherort und Verschlüsselung.

Bei Managed Hosting ist außerdem die Abgrenzung entscheidend. Ein Anbieter sichert in der Regel die Infrastruktur und die von ihm betreuten Dienste. Anwendungsdaten, die ein Dienstleister der Kundenseite einspielt, oder Daten in einem selbst verwalteten Container können außerhalb dieses Rahmens liegen. Diese Grenze sollte schriftlich festgehalten sein, ebenso die Frage, wer im Notfall den Restore auslöst und in welcher Reaktionszeit.

Ein realistischer Einstieg

Wer keine dokumentierte Strategie hat, beginnt nicht mit Software, sondern mit einer Liste: Welche Systeme gibt es, welche Daten liegen darin, welcher Ausfall wäre wie teuer. Daraus ergeben sich RPO und RTO, daraus die nötige Technik. Danach ein einziger vollständiger Wiederherstellungstest für das wichtigste System, mit gemessener Zeit und schriftlichem Ergebnis.

Diese eine Übung verändert die Diskussion nachhaltig, weil aus einer gefühlten Sicherheit eine belastbare Zahl wird. Alles Weitere ist Wiederholung in festen Abständen und Pflege der Anleitung.