Backup vorhanden – Betrieb trotzdem still: So planen Unternehmen einen Wiederherstellungstest

Die Datensicherung meldet „erfolgreich“. Trotzdem lässt sich die Warenwirtschaft nach einem Serverausfall nicht rechtzeitig starten: Die Datenbank ist vorhanden, aber ein benötigter Dienst fehlt. Oder die Sicherung ist verschlüsselt, und der Schlüssel lag ausgerechnet auf dem ausgefallenen System.

Solche Situationen zeigen, warum ein erfolgreiches Backup allein keine ausreichende Aussage über die Wiederherstellbarkeit liefert. Ein Wiederherstellungstest – auch Restore-Test genannt – prüft, ob Daten und Anwendungen unter definierten Bedingungen wieder nutzbar werden.

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) macht solche Tests im IT-Grundschutz zur Basis-Anforderung: „Es MUSS regelmäßig getestet werden, ob die Datensicherungen wie gewünscht funktionieren, vor allem, ob gesicherte Daten einwandfrei und in angemessener Zeit zurückgespielt werden können“ (BSI: Baustein CON.3, Anforderung A15). Entscheidend ist dabei nicht nur, ob sich Dateien zurückkopieren lassen, sondern wann Mitarbeitende wieder arbeiten können.

Was ein Restore-Test tatsächlich nachweisen soll

Eine Integritätsprüfung kontrolliert, ob gespeicherte Sicherungsdaten technisch unbeschädigt sind. Ein Starttest zeigt, ob ein wiederhergestelltes System hochfährt. Beides ist wertvoll, beantwortet aber noch nicht alle Fragen: Für einen Geschäftsprozess müssen auch Benutzeranmeldung, Datenbank, Berechtigungen und Schnittstellen funktionieren.

Backup-Hersteller unterscheiden diese Ebenen ausdrücklich. Veeam etwa bietet eine reine Prüfung von Sicherungsintegrität und Inhalten sowie eine vollständige Wiederherstellbarkeitsprüfung, bei der Systeme in einer isolierten Umgebung gestartet und Anwendungen getestet werden (Veeam: SureBackup). Bei Proxmox Backup Server prüfen Verify-Jobs, ob Sicherungen noch zu ihren Prüfsummen passen; Proxmox selbst empfiehlt zusätzlich, das Zurückspielen und Starten von Sicherungen regelmäßig zu testen (Proxmox Backup Server: Dokumentation).

Ein sinnvoller Test hat deshalb ein konkretes Ziel – etwa: „Die Auftragsbearbeitung kann mit einem definierten Datenstand wieder genutzt werden.“

Schritt 1: Geschäftliche Ziele festlegen

Bevor die IT einen Test plant, sollten Geschäftsführung und Fachbereich zwei Fragen beantworten:

• Wie viel Datenverlust ist höchstens akzeptabel? Dieser Wert heißt Recovery Point Objective (RPO). Er beschreibt, wie weit der wiederherstellbare Datenstand im Ernstfall höchstens zurückliegen darf.
• Wie schnell muss der Dienst wieder nutzbar sein? Die Recovery Time Objective (RTO) beschreibt die angestrebte Wiederherstellungszeit.

Ein beispielhaftes Ziel könnte lauten: Die Auftragsbearbeitung soll spätestens vier Stunden nach einem Ausfall wieder nutzbar sein; höchstens eine Stunde an Änderungen darf fehlen. Das sind Planungsannahmen, keine allgemeine Empfehlung für jedes Unternehmen.

Eine Sicherung pro Nacht passt nicht zu einem RPO von einer Stunde. Umgekehrt sagt ein kurzer Abstand zwischen Sicherungen noch nichts darüber aus, wie lange die Wiederherstellung dauert. Legen Sie zusätzlich fest, was „nutzbar“ bedeutet: Reicht ein eingeschränkter Notbetrieb, oder müssen sämtliche Schnittstellen verfügbar sein? Auch die Reihenfolge, in der Systeme wiederhergestellt werden, gehört laut BSI in den Datensicherungsplan (CON.3.A4).

Schritt 2: Ein realistisches Ausfallszenario auswählen

Ein Restore-Test ist nur so aussagekräftig wie seine Annahmen.

Beginnen Sie mit einem geschäftlich wichtigen, aber kontrolliert testbaren Dienst. Erweitern Sie den Umfang anschließend so, dass weitere kritische Bereiche abgedeckt werden. Wird ein Cyberangriff simuliert, muss zusätzlich geklärt sein, wie ein sauberer Datenstand ausgewählt und die Zielumgebung abgesichert wird – ein erfolgreicher Restore allein beweist nicht, dass die Ursache eines Angriffs beseitigt ist.

Schritt 3: Eine geeignete Testumgebung vorbereiten

Wiederhergestellte Systeme dürfen nicht unbeabsichtigt in den Produktivbetrieb eingreifen: Eine Kopie kann dieselben Namen, IP-Adressen oder geplanten Aufgaben besitzen wie das Original. Veeam empfiehlt für manuelle Tests deshalb ein isoliertes Netzwerk, in dem abhängige Systeme in der richtigen Reihenfolge gestartet werden – etwa DNS, dann Domänencontroller, dann das zu prüfende System (Veeam: Manuelle Prüfung).

Legen Sie fest, welche Verbindungen erlaubt sind, und verhindern Sie beispielsweise echte Zahlungsaufträge, E-Mail-Versand oder Schreibzugriffe auf produktive Schnittstellen. Die Umgebung benötigt außerdem ausreichend Rechenleistung und Speicher. Ist die Testhardware deutlich langsamer als die vorgesehene Notfallumgebung, muss das bei der Bewertung der gemessenen Zeiten berücksichtigt werden.

Prüfen Sie auch den Zugang zu Verschlüsselungsschlüsseln. Bei verschlüsselten Sicherungen mit Proxmox Backup Server sind die Daten ohne den passenden Schlüssel nicht zugänglich; lag der Schlüssel nur auf dem ausgefallenen System, ist keine Wiederherstellung möglich. Der Hersteller empfiehlt daher unter anderem, eine Papierkopie des Master-Schlüssels sicher zu verwahren (Proxmox Backup Server: Verschlüsselung). Auch das BSI sieht bei erhöhtem Schutzbedarf vor, verwendete Schlüssel mit einer getrennten Datensicherung zu schützen (CON.3.A13).

Schritt 4: Den gesamten Wiederanlauf messen

Starten Sie die Zeitmessung am zuvor definierten Beginn des Szenarios – und erfassen Sie nicht nur die Datenübertragung. Zur Wiederherstellung können gehören:

• zuständige Personen erreichen und den Vorfall einordnen,
• Sicherungsstand auswählen und Zugänge bereitstellen,
• Zielressourcen vorbereiten,
• Systeme und Daten zurückspielen,
• Dienste in der erforderlichen Reihenfolge starten,
• technische und fachliche Funktion prüfen,
• den Betrieb freigeben.

Fiktives Rechenbeispiel: Für eine Anwendung gilt ein RTO von vier Stunden. Im Test dauern die Vorbereitung 30 Minuten, die Rücksicherung 110 Minuten, der Start abhängiger Dienste 40 Minuten und die fachliche Abnahme 35 Minuten. Insgesamt sind das 215 Minuten oder 3 Stunden und 35 Minuten. Das Ziel wird unter den getesteten Bedingungen erreicht – allerdings mit nur 25 Minuten Reserve.

Ob das ausreicht, hängt vom Szenario ab. Wurden beispielsweise alle Zugänge vorab bereitgelegt, obwohl sie im Ernstfall erst beschafft werden müssten, ist die Messung nur eingeschränkt auf einen echten Ausfall übertragbar.

Schritt 5: Den Fachbereich prüfen lassen

Die technische Prüfung sollte durch eine fachliche Abnahme ergänzt werden. Bei einer Warenwirtschaft könnte der Fachbereich etwa einen Auftrag öffnen, Positionen prüfen und einen Testbeleg erzeugen. Bei einer Dateiablage sind Stichproben aus unterschiedlichen Ordnern sinnvoll: Lassen sich die Dateien öffnen, und haben die richtigen Personen Zugriff?

Besonders aussagekräftig sind vorab definierte Prüfschritte – „sieht gut aus“ ist keine reproduzierbare Abnahme. Dokumentieren Sie außerdem den tatsächlichen Datenstand: Eine Anwendung kann fehlerfrei starten und trotzdem einen älteren Stand enthalten, als das vereinbarte RPO zulässt.

Was gehört ins Testprotokoll?

Ein kompaktes Protokoll macht Ergebnisse vergleichbar und verhindert, dass erkannte Mängel liegen bleiben. Nutzen Sie diese Struktur als Vorlage:

Ein fehlgeschlagener Test ist ein verwertbares Ergebnis – wenn die Ursache behoben und anschließend erneut geprüft wird.

Wie häufig sollten Unternehmen Wiederherstellungstests durchführen?

Einen gesetzlich oder vom BSI festgelegten Turnus gibt es nicht; das IT-Grundschutz-Kompendium fordert regelmäßige Tests. Der BSI-Standard 200-4 zum Notfallmanagement nennt als Beispiel einen mindestens jährlichen Funktionstest für Prozesse und Ressourcen mit einer Wiederanlaufzeit unter 24 Stunden (BSI-Standard 200-4). Kritikalität, Änderungsrate, technische Komplexität und bisherige Testergebnisse sollten die Häufigkeit bestimmen.

Als beispielhafter Ausgangspunkt, der an die eigene Umgebung angepasst werden muss, bietet sich an:

• monatlich ausgewählte Dateien oder einzelne Sicherungsstände prüfen,
• quartalsweise einen wichtigen Dienst einschließlich seiner Abhängigkeiten wiederherstellen,
• jährlich einen umfangreicheren Wiederanlauf unter einem definierten Notfallszenario üben,
• nach wesentlichen Änderungen gezielt erneut testen, etwa nach einer Migration oder dem Austausch der Backup-Lösung.

Automatisierte Prüfungen können den Ablauf unterstützen. Sie ersetzen jedoch nicht sämtliche fachlichen Prüfungen und organisatorischen Übungen.

Fazit: Datensicherung, deren Nutzen nachgewiesen ist

Ein belastbares Backup-Konzept verbindet Sicherung, Schutz der Sicherungen und praktische Wiederherstellung – wie es auch die 3-2-1-Backup-Regel mit ihrer Erweiterung um getestete Wiederherstellungen vorsieht. Entscheidend ist, ob Ihre geschäftskritischen Daten rechtzeitig und in nutzbarer Form zurückkehren. Für Cloud-Daten gilt das genauso, wie unser Beitrag zur Sicherung von Microsoft 365 zeigt.

oneCorp unterstützt Unternehmen mit Backup as a Service bei Einrichtung, Überwachung und Wiederherstellung; regelmäßige Restore-Tests lassen sich ergänzend vereinbaren (Backup as a Service). Gemeinsam legen wir fest, welche Systeme Vorrang haben und welche Ergebnisse ein Test nachweisen soll.

Stand: Oktober 2026. Anforderungen zitiert nach dem IT-Grundschutz-Kompendium, Edition 2023, Baustein CON.3. Das BSI löst das Kompendium schrittweise durch „Grundschutz++“ ab. Testintervalle in diesem Beitrag sind Planungsvorschläge, keine Vorgaben.