Der Wiederherstellungstest — die Übung, die über den Ernstfall entscheidet

/01Was ein Wiederherstellungstest ist — und was ein grünes Protokoll nicht beweist

Ein Backup ist eine Kopie. Ein Wiederherstellungstest ist der Beweis, dass aus dieser Kopie wieder ein lauffähiges System wird — innerhalb einer Zeit, die jemand vorher zugesagt hat. Zwischen beidem liegt mehr, als die meisten Berichte zeigen: Die Backup-Software meldet „erfolgreich", sobald die Sicherung geschrieben und ihre Prüfsumme verifiziert wurde. Ob sich aus dieser Sicherung ein Server booten, eine Datenbank öffnen oder eine ganze Umgebung wiederherstellen lässt, prüft dieser Schritt nicht. Ein Sicherungsjob kann monatelang grün laufen und trotzdem am Tag X eine beschädigte Kette, eine falsche Rechtevererbung oder ein fehlendes Zertifikat zutage fördern.

Genau diese Lücke schließt der Restore-Test: die reale, zeitgemessene Wiederherstellung auf einem Zielsystem, mit Protokoll und einem Ergebnis „bestanden" oder „nicht bestanden". Der BSI-Standard 200-4 fasst das in seiner Terminologie so: Ein Test ist eine besondere Form der Übung, bei der ein objektiv gemessenes Ergebnis erwartet wird, während eine Übung allgemeiner formulierte Ziele verfolgt. Für die Wiederherstellung heißt das konkret: kein Tabletop, kein Gedankenspiel am Whiteboard, sondern ein Vorgang, der tatsächlich ausgeführt wird und eine Uhr mitlaufen lässt.

Zwei Zahlen gehören dabei zusammen und werden trotzdem selten gemeinsam betrachtet: das RPO/RTO-Paar. Der Recovery Point Objective legt fest, wie viel Datenverlust maximal hinnehmbar ist — meist eine Frage des Sicherungsintervalls. Der Recovery Time Objective legt fest, wie lange die Wiederherstellung maximal dauern darf — und das ist eine Zusage, keine Messung, solange niemand sie überprüft hat. Dieser Artikel behandelt ausschließlich den zweiten Teil: Wie eine Institution die RTO nicht nur vereinbart, sondern regelmäßig gegen die Realität hält. Wie die Sicherung selbst aufgebaut wird — 3-2-1-Regel, Immutabilität, Ransomware-resistente Kopien —, behandeln andere Artikel in dieser Reihe; hier zählt nur, was am Ende bei einer echten Wiederherstellung herauskommt.

/02Vier Testarten: von der Einzeldatei zum kompletten Standort

Nicht jeder Test kostet gleich viel, und nicht jeder Test prüft dasselbe. Ein Mittelständler, der nur die aufwendigste Form kennt, testet in der Praxis gar nicht — der Aufwand schreckt ab, und das Vorhaben verschwindet im nächsten Quartal. Vier abgestufte Testarten decken die relevanten Szenarien ab und lassen sich unterschiedlich oft durchführen.

Die ersten beiden Stufen lassen sich mit vertretbarem Aufwand häufig durchführen und liefern trotzdem echte Information — ein Restore einer einzelnen Datei aus dem Backup-Repository dauert selten länger als eine Kaffeepause. Die dritte Stufe, der komplette Serverrestore, ist der Punkt, an dem die meisten Institutionen zum ersten Mal überrascht werden: Ein System bootet, aber ohne den passenden Netzwerktreiber, oder die Windows-Lizenzaktivierung verlangt telefonische Bestätigung, weil sich die Hardware-ID geändert hat. Ein realistischer Ablauf für diese Stufe sieht in Proxmox-Umgebungen mit Proxmox Backup Server so aus — bewusst in ein isoliertes Testnetz, nicht in die Produktion:

root@pve01:~# date +%T
14:02:11
root@pve01:~# qmrestore pbs-store:backup/vm/114/2026-08-30T02:15:00Z 9114 \
    --storage local-lvm --unique 1
restoring 'pbs-store:backup/vm/114/2026-08-30T02:15:00Z' now..
progress 100% (read 34359738368 bytes, duration 1612 sec)
root@pve01:~# qm set 9114 --net0 virtio,bridge=vmbr99   # isoliertes Testnetz, keine Produktivroute
root@pve01:~# qm start 9114
root@pve01:~# date +%T
14:41:53

Knapp 40 Minuten zwischen Startbefehl und laufendem System — für eine einzelne VM. Das ist der Wert, der in die Testtabelle gehört, nicht die pauschale RTO aus dem Konzeptpapier. Die vierte Stufe, der komplette Standort, ist die aufwendigste und seltenste — sie prüft, ob Disaster Recovery als Ganzes funktioniert: Netzwerk, Namensauflösung, Abhängigkeiten zwischen Systemen, nicht nur ein einzelner Server. Wer diese Stufe nicht selbst betreiben will, findet in Disaster Recovery as a Service eine Variante, bei der der Testlauf regelmäßig durch den Anbieter erfolgt statt einmal jährlich in Eigenregie.

/03Wie oft getestet wird — Frequenz nach Wiederanlaufzeit gestaffelt

Die häufigste falsche Antwort auf „wie oft testen" lautet: einmal im Jahr, für alles gleich. Das ist praktikabel, aber es ignoriert, dass nicht jedes System gleich kritisch ist. Der BSI-Standard 200-4 schlägt in Kapitel 13 einen risikoorientierten Ansatz vor und liefert in Tabelle 37 ein konkretes Beispiel: Für Prozesse und Ressourcen mit einer Wiederherstellungszeit unter 24 Stunden empfiehlt der Standard einen Funktionstest mindestens jährlich, auf Ebene einzelner Komponenten und einzelner Ressourcen bis hin zu ressourcenübergreifenden Abläufen. Für Prozesse und Ressourcen, deren Wiederherstellungszeit bis zu fünf Tage betragen darf, reicht danach ein Test mindestens alle drei Jahre. Das ist ausdrücklich ein Beispielwert für den risikoorientierten Ansatz, keine feste Vorschrift — aber die Logik dahinter trägt: Je enger die zugesagte RTO, desto öfter muss sie überprüft werden, weil ein enges Zeitfenster weniger Spielraum für Überraschungen lässt.

Wer der NIS2-Regulierung unterliegt, hat ohnehin keine Wahl mehr, ob getestet wird. Die EU-Durchführungsverordnung 2024/2690 verlangt in Nummer 4.2.6 ausdrücklich: „Die betreffenden Einrichtungen führen regelmäßige Tests der Wiederherstellung von Sicherungskopien und Redundanzen durch, um sicherzustellen, dass sie bei der Wiederherstellung zuverlässig sind und alle Kopien, Verfahren und Kenntnisse abdecken, die nötig sind, um eine wirksame Wiederherstellung durchzuführen." Eine feste Zahl — „einmal jährlich" oder ähnlich — nennt die Verordnung an dieser Stelle nicht; sie verlangt „regelmäßig" und in Nummer 4.1.4 zusätzlich, dass der Notfallplan „in geplanten Zeitabständen sowie bei erheblichen Sicherheitsvorfällen oder wesentlichen Änderungen der Betriebsabläufe oder der Risiken" getestet wird. Wer die Frequenz selbst festlegen muss, tut deshalb gut daran, sich an der RTO-Staffelung von BSI 200-4 zu orientieren, statt eine Zahl zu erfinden.

Für die deutsche Rechtslage kommt dieselbe Pflicht über § 30 Absatz 2 Nummer 3 BSIG, der unter den Risikomanagementmaßnahmen wichtiger und besonders wichtiger Einrichtungen ausdrücklich die „Aufrechterhaltung des Betriebs, wie Backup-Management und Wiederherstellung nach einem Notfall, und Krisenmanagement" nennt. Erlässt die EU-Kommission dazu einen Durchführungsrechtsakt mit technischen Anforderungen — und das ist mit der Verordnung 2024/2690 bereits geschehen —, gehen dessen Vorgaben laut § 30 Absatz 4 BSIG den allgemeineren Formulierungen des Gesetzes vor, soweit sie entgegenstehen. In der Praxis bedeutet das: Die Verordnung, nicht das Gesetz, ist die Textstelle, an der die konkrete Testpflicht steht.

/04Wer beim Test dabei sein muss

Ein Restore-Test, den ein einzelner Administrator allein am Wochenende durchführt und danach per Kurzmail meldet, ist besser als kein Test — aber er prüft nur die Technik, nicht die Organisation. Vier Rollen gehören auf jede Testliste, auch wenn eine Person mehrere davon übernimmt:

• Technische Durchführung: führt den Restore nach dem dokumentierten Runbook aus, nicht aus dem Gedächtnis. Wer improvisiert, testet die eigene Erfahrung, nicht die Wiederholbarkeit des Verfahrens.
• Fachliche Abnahme: prüft nach dem technischen Restore, ob die Anwendung fachlich stimmt — Buchungen vollständig, Zugriffsrechte korrekt, Schnittstellen zu Nachbarsystemen funktionsfähig. Ohne diese Rolle gilt ein bootendes System fälschlich schon als Erfolg.
• Zeitnahme und Protokollführung: hält Start- und Endzeitpunkt sowie jede Abweichung fest, unabhängig von der Durchführung. Wer selbst restauriert und gleichzeitig protokolliert, vergisst im Zweifel die unangenehmen Zwischenfälle.
• Gegenzeichnung durch die Leitung: nimmt das Ergebnis ab und entscheidet über Korrekturmaßnahmen bei Abweichungen. Diese Unterschrift ist es, die aus einem internen Testlauf ein belastbares Dokument für Auditoren macht.

Bei der vierten Testart — dem kompletten Standort — kommt eine fünfte Frage dazu, die in Testplänen regelmäßig fehlt: Ist am vereinbarten Testtermin überhaupt genug Personal verfügbar? Ein Standort-Failover, der an einem gewöhnlichen Dienstagvormittag geprobt wird, sagt wenig darüber aus, ob dieselbe Übung an einem Sonntagmorgen gelingt, wenn die Incident-Response-Kette erst per Bereitschaftstelefon aktiviert werden muss. Wer testet, wann es bequem ist, testet nicht das Szenario, das im Ernstfall tatsächlich eintritt.

/05Das Testprotokoll: was mitgeschrieben wird

Ein Restore-Test ohne Protokoll hinterlässt nach einer Woche nur noch eine vage Erinnerung „hat funktioniert". Für ein belastbares Protokoll reichen wenige, aber immer dieselben Felder — die Detailtiefe darf je nach Testart variieren, die Struktur nicht:

• Datum, Testart und betroffenes System oder Prozess
• zugesagte RTO laut Notfallplan oder SLA
• Startzeitpunkt und Endzeitpunkt der Wiederherstellung, nicht der Vorbereitung
• jede Abweichung vom Runbook, auch kleine — genau diese Abweichungen sind der eigentliche Erkenntnisgewinn
• Ergebnis: bestanden, bestanden mit Einschränkung, nicht bestanden
• Korrekturmaßnahmen mit Verantwortlichem und Termin
• Name der Durchführung und Gegenzeichnung der Leitung

Die Differenz zwischen Start- und Endzeitpunkt ist die eigentlich interessante Zahl — sie ist eine gemessene, keine geschätzte Größe und damit näher an einer belastbaren MTTR als jede Zusage im Vertrag. Ein einzelner Test liefert noch keine statistisch verlässliche Kennzahl, aber eine Serie von Tests über mehrere Quartale zeigt Trends: Wird die Wiederherstellung mit wachsendem Datenvolumen langsamer? Häufen sich Abweichungen bei einer bestimmten Systemgruppe? Genau diese Trends fehlen, wenn nur das Endergebnis „erfolgreich" archiviert wird und die Zeitmessung verlorengeht.

/06Die Lücke zwischen zugesagter RTO und gemessener Wiederanlaufzeit

Die RTO in einem Notfallplan ist fast immer eine Schätzung aus der Konzeptionsphase — meist die Zeit, die die reine Restore-Funktion der Backup-Software für die Datenmenge benötigen sollte. Die gemessene Wiederanlaufzeit ist länger, praktisch immer, und der Unterschied liegt selten an der Backup-Software selbst. Er liegt an fünf Posten, die in den meisten Rechnungen schlicht fehlen, weil sie nicht Teil des Sicherungsjobs sind, aber Teil des Wiederanlaufs:

Keiner dieser fünf Posten ist exotisch — jeder davon ist in einer gewachsenen IT-Umgebung eher die Regel als die Ausnahme. Das Muster dahinter ist immer dasselbe: Die RTO wird für die Technik geschätzt, aber im Ernstfall zählt der gesamte Weg vom Ausfall bis zum nutzbaren System, inklusive Organisation. Ein Restore-Test, der nur die Technik misst, wiederholt genau diesen Fehler und liefert am Ende wieder nur eine geschönte Zahl.

/07Wo es hakt: Grenzen des Testverfahrens

Ein Restore-Test ist kein Freibrief, der alle Unsicherheit beseitigt. Vier Grenzen sollten Sie kennen, bevor Sie sich auf ein bestandenes Testprotokoll verlassen.

Die Testumgebung ist nicht die Produktivumgebung

Ein isoliertes Testnetz mit begrenzter Bandbreite und ohne die Lastspitzen der Produktion liefert eine Wiederanlaufzeit, die im echten Ernstfall — mit gleichzeitig ausgefallener Infrastruktur und paralleler Wiederherstellung mehrerer Systeme — eher zu optimistisch ausfällt, nicht zu pessimistisch.

Personenbezogene Daten im Testlauf

Ein Restore mit echten Kundendaten in eine isolierte, aber eben doch existierende Testumgebung ist eine Verarbeitung im Sinne der DSGVO wie jede andere. Zugriffsrechte, Aufbewahrungsdauer und Löschung der Testumgebung nach Abschluss gehören ins Testkonzept, nicht in eine Grauzone.

Ein bestandener Test schützt nicht vor verschlüsselten Backups

Ein Restore-Test, der aus einer aktuellen Sicherung wiederherstellt, prüft nicht, ob diese Sicherung selbst bereits durch Ransomware kompromittiert wurde. Diese Frage beantwortet eine unveränderliche, getrennt aufbewahrte Kopie — nicht der Restore-Test allein, sondern die Architektur der Sicherung dahinter.

Ein Ergebnis ist eine Momentaufnahme

Ein bestandener Test im März sagt nichts über den Wiederanlauf im Oktober, wenn zwischenzeitlich neue Systeme dazugekommen, Datenmengen gewachsen oder Abhängigkeiten verändert wurden. Scheitert ein Test, gehört die Ursachenanalyse in ein kurzes, dokumentiertes Post-Mortem — mit Korrekturmaßnahme und Termin für den Nachtest, nicht mit einer stillschweigenden Wiederholung beim nächsten Routinelauf.

/08Wann sich der volle Testaufwand lohnt — und wann eine abgespeckte Version reicht

Nicht jede Institution braucht alle vier Testarten in voller Tiefe und maximaler Frequenz. Die Entscheidung hängt an der Kritikalität der Systeme und an dem, was im Vertrag oder in der Regulierung tatsächlich verlangt wird.

Der volle Aufwand lohnt sich, wenn …

• eine enge RTO zugesagt ist: Wer Kunden oder der eigenen Geschäftsführung eine Wiederanlaufzeit unter 24 Stunden verspricht, muss sie regelmäßig belegen können — sonst ist die Zusage Marketing, keine Planung.
• NIS2 oder eine vergleichbare Regulierung greift: Die Testpflicht aus der Durchführungsverordnung 2024/2690 ist keine Kann-Bestimmung, und ein fehlendes Protokoll ist im Prüfungsfall schwerer zu erklären als ein bestandener, aber unvollkommener Test.
• ein Cyberversicherungsvertrag Restore-Nachweise verlangt: Viele Policen setzen inzwischen dokumentierte, regelmäßige Wiederherstellungstests als Bedingung für die Deckung im Schadensfall voraus.
• die Systemlandschaft komplex und stark vernetzt ist: Je mehr Abhängigkeiten zwischen Systemen bestehen, desto wahrscheinlicher wird ein Reihenfolgefehler, den nur ein realer Test aufdeckt.

Eine abgespeckte Version reicht, wenn …

• die RTO großzügig bemessen ist: Bei einer zugesagten Wiederanlaufzeit von mehreren Tagen für unkritische Systeme ist ein jährlicher Funktionstest angemessen, kein Quartalsrhythmus.
• Systeme ohnehin ersetzt statt wiederhergestellt werden: Für zustandslose Anwendungen, die aus einer Konfigurationsverwaltung neu aufgesetzt werden können, ist ein klassischer Restore-Test oft der falsche Maßstab — hier zählt der Aufbau aus der Pipeline, nicht der Restore aus dem Backup.
• der komplette Standorttest wirtschaftlich nicht zu stemmen ist: Wer keinen zweiten, wirklich unabhängigen Standort betreibt, sollte diesen Aufwand nicht simulieren, sondern über DRaaS auslagern, wo der Anbieter den Failover-Test regelmäßig für mehrere Kunden gemeinsam betreibt.

Die realistische Antwort liegt fast immer dazwischen: kleine, günstige Tests häufig, den teuren Standorttest selten, aber verbindlich terminiert — nicht „wenn Zeit ist", sondern als fester Programmpunkt der Jahresplanung.

/09Die Testtabelle als Nachweisdokument gegenüber Prüfern und Versicherern

Ein Auditor nach ISO/IEC 27001 und ein Sachbearbeiter der Cyberversicherung stellen im Kern dieselbe Frage: nicht „haben Sie ein Backup", sondern „können Sie belegen, dass es funktioniert, und seit wann". Eine laufend geführte Testtabelle beantwortet genau das — vorausgesetzt, sie enthält mehr als ein Häkchen.

Die letzte Zeile ist bewusst kein Erfolg — genau solche Einträge machen eine Testtabelle glaubwürdig. Ein Nachweisdokument, in dem über Jahre ausschließlich „bestanden" steht, wirkt auf Prüfer eher misstrauisch erregend als beruhigend: Reale Systeme produzieren gelegentlich Abweichungen, und deren Fehlen legt nahe, dass entweder selten oder oberflächlich getestet wurde. Entscheidend ist nicht die makellose Bilanz, sondern die Kette aus Termin, Messung, Ergebnis und Korrekturmaßnahme mit Termin für den Nachtest — an genau der Stelle, an der die Standortübung vom 6. September durchgefallen ist, muss die nächste Zeile in derselben Tabelle die Nachbesserung samt neuem Testdatum zeigen.

/10Häufige Fragen