Woran erkennen Sie, ob Ihr Backup wirklich funktioniert?

Warum beweist ein erfolgreicher Backup-Job nicht, dass Sie wiederherstellen können?

Weil ein Backup-Job und eine Wiederherstellung zwei verschiedene Dinge sind. Der Job bestätigt, dass Daten auf das Backup-Ziel kopiert wurden. Für eine Wiederherstellung muss diese Kopie vollständig, unbeschädigt und nutzbar sein, und es braucht einen Ablauf, dem Menschen auch unter Druck folgen können.

Ein Beispiel: Jede Nacht zeigt das Dashboard grüne Häkchen. Dann fällt ein Server aus, und die Wiederherstellung stockt, weil der Verschlüsselungsschlüssel nicht dort liegt, wo ihn jemand erwartet, oder weil die Datenbank ohne die Konfiguration zurückkommt, die die Anwendung braucht. Das Backup war in Ordnung. Die Wiederherstellung nicht. Deshalb misst man jedes Backup as a Service, für das es sich zu zahlen lohnt, an Wiederherstellungen und nicht an Häkchen.

Umfragen zeigen, wie häufig diese Lücke ist. Im Unitrends State of Backup and Recovery Report 2025 glaubten mehr als 60 % der Organisationen, sie könnten einen Ausfall innerhalb von Stunden beheben, aber nur 35 % konnten es. Der Data Trust and Resilience Report 2026 von Veeam ergab, dass 90 % der Organisationen sicher waren, sich von einem Cybervorfall erholen zu können, aber nur 28 % der Ransomware-Opfer alle betroffenen Daten vollständig wiederherstellten.

Wiederherstellungen scheitern meist aus drei Gründen:

1. Unvollständiger Umfang: Ein System, eine Datenbank oder eine Konfiguration war nie im Backup.
2. Beschädigte Daten: Der Job lief erfolgreich, aber Speicherfehler oder unterbrochene Schreibvorgänge haben die Kopie beschädigt.
3. Fehlende Abhängigkeiten: Die Wiederherstellung braucht Software, Lizenzen, Verschlüsselungsschlüssel oder Identitätseinstellungen, die nicht verfügbar sind.

Automatische Prüfungen finden die ersten beiden Ursachen. Die dritte zeigt sich erst, wenn Sie wirklich wiederherstellen.

Welche Stufen hat ein Wiederherstellungstest, und wie oft sollten Sie testen?

Es gibt drei Stufen, und jede beweist mehr als die vorige. Testen Sie kritische Systeme auf allen drei Stufen, weniger kritische auf den ersten beiden.

Verstehen Sie das als Ausgangspunkt, nicht als Regel. Testen Sie außerdem nach jeder wesentlichen Änderung: einer Migration, einem neuen System, einem Software-Upgrade oder einer Änderung der Backup-Konfiguration.

Offizielle Empfehlungen gehen in dieselbe Richtung. Der CISA #StopRansomware Guide fordert Organisationen auf, „regelmäßig die Verfügbarkeit und Integrität von Backups in einem Disaster-Recovery-Szenario zu testen“. Der Leitfaden des britischen NCSC für kleine Organisationen sagt, dass Sie nach dem Erstellen eines Backups wissen müssen, wie Sie es wiederherstellen, und prüfen müssen, ob es alle wichtigen Daten enthält. Trotzdem testen viele Organisationen selten: Laut Unitrends testen 25 % ihre Disaster Recovery nur einmal im Jahr oder seltener.

Für einen Test der Stufe 3 sehen Sie am Beispiel eines strukturierten Disaster-Recovery-Service, wie Failovers auf einer Standby-Infrastruktur ablaufen.

Wie läuft ein Wiederherstellungstest Schritt für Schritt ab?

Wählen Sie ein Szenario, stellen Sie es genau nach Dokumentation in einer isolierten Umgebung wieder her und prüfen und messen Sie dann das Ergebnis. Ziel ist, Probleme zu finden, solange nichts brennt.

1. Szenario wählen: eine Datei vom letzten Monat, eine Datenbank oder ein kompletter Server.
2. Isolierte Umgebung nutzen: ein separates Netzwerk, damit das wiederhergestellte System nicht mit der Produktion kollidiert.
3. Der schriftlichen Anleitung folgen: keine Abkürzungen und keine Hilfe von der einen Person, die alles auswendig kennt.
4. Jeden Schritt messen: von der Entscheidung zur Wiederherstellung bis zu dem Moment, in dem Nutzer arbeiten können.
5. Daten validieren: Dateien öffnen, die Datenbank abfragen, sich in der Anwendung anmelden.
6. Wiederherstellungspunkt prüfen: Wie aktuell sind die neuesten wiederhergestellten Daten?
7. Ergebnis festhalten: was funktioniert hat, was gescheitert ist, was länger gedauert hat als geplant.
8. Beheben und erneut testen: Umfang, Konfiguration oder Notfallhandbuch anpassen, dann wiederholen.

Schritt 5 ist der Punkt, an dem viele Tests zu früh enden. Die AWS-Well-Architected-Empfehlung zur Zuverlässigkeit (REL09-BP04) nennt „Wiederherstellung ohne Validierung“ als Anti-Pattern, ebenso wie die Annahme, dass Wiederherstellungszeit und Datenverlust die Ziele erfüllen, ohne sie zu messen.

Was ist, wenn der Test scheitert?

Ein gescheiterter Test liefert nützliche Informationen. Eine gescheiterte Wiederherstellung bei einem echten Vorfall ist der eigentliche Schaden. Suchen Sie die Ursache (Konfiguration, fehlender Umfang, beschädigtes Backup oder fehlende Dokumentation), beheben Sie sie und wiederholen Sie denselben Test, bis er besteht.

Mit Mindtime können Sie eine gesicherte VM sofort in einer isolierten Wiederherstellungsumgebung in einem getrennten, sauberen Netzwerk starten. Das macht Tests der Stufe 2 deutlich weniger störend.

Wie prüfen Sie, ob Ihr Backup vollständig ist?

Erstellen Sie ein Inventar für die Wiederherstellung, also eine Liste von allem, was Sie nach einem Totalverlust brauchen, und vergleichen Sie es mit dem, was tatsächlich im Backup liegt. Alles, was auf der Liste steht, aber nicht im Backup, ist eine Lücke.

Vollständigkeit bedeutet mehr als die Daten selbst. Prüfen Sie für jede Art von System:

• Server und VMs: Betriebssystem, Anwendungen, Konfiguration, Daten und Lizenzinformationen.
• Microsoft 365: Exchange-Postfächer, OneDrive, SharePoint-Websites und Teams. Auch die Konten ausgeschiedener Mitarbeitender zählen.
• Datenbanken: die Daten plus Schema, gespeicherte Prozeduren, Sichten und die Jobs, die davon abhängen.
• Endgeräte und NAS: die Dateien, die Mitarbeitende außerhalb zentraler Systeme speichern.
• Wichtiges für die Wiederherstellung: Verschlüsselungsschlüssel, Administrator-Zugangsdaten, Notfallhandbücher und Lieferantenkontakte, aufbewahrt an einem Ort, den Sie auch bei ausgefallener Produktion erreichen.

Prüfen Sie das Inventar immer, wenn Sie ein System hinzufügen. Neue SaaS-Anwendungen und Schatten-Datenbanken sind die typischen Stellen für Lücken. Was dazugehört, sehen Sie beim Microsoft-365-Backup und beim Backup von SQL-Server-Datenbanken.

Welche Kennzahlen zeigen, dass Ihre Backup- und Wiederherstellungsstrategie wirkt?

Messen Sie Ergebnisse, nicht Aktivität. Die wichtigsten Zahlen sind, wie oft Wiederherstellungen gelingen, wie viele Daten Sie verlieren würden und wie lange die Wiederherstellung dauert, jeweils im Vergleich zu den Zielen, die Sie mit dem Unternehmen vereinbart haben.

Zwei Ziele bilden die Grundlage. Der RPO (Recovery Point Objective) ist der maximale Datenverlust, also wie viel Arbeit Sie verlieren dürfen, gemessen in Zeit. Der RTO (Recovery Time Objective) ist die maximale Ausfallzeit eines Systems. Legen Sie beide pro System fest und messen Sie dann dagegen. Wie Sie sie wählen, erklärt unser Ratgeber zu RTO und RPO.

Die letzte Zeile ist wichtiger, als sie aussieht. Der Report Ransomware Trends 2025 von Veeam, über den Intelligent CISO berichtet, ergab, dass nur 10 % der angegriffenen Organisationen mehr als 90 % ihrer Daten wiederherstellten. Wiederherstellungstests belegen, dass der Prozess funktioniert. Eine unveränderliche Kopie nach der 3-2-1-1-0-Regel sorgt dafür, dass überhaupt etwas zum Wiederherstellen übrig ist.

Welche Nachweise erwarten NIS2, DSGVO und Prüfer?

Aufsichtsbehörden und Prüfer wollen den Beweis, dass Sie wiederherstellen können, nicht die Aussage, dass Sie sichern. Das heißt: datierte Testprotokolle, Ergebnisse im Vergleich zu Ihren Zielen und eine Spur dessen, was Sie behoben haben.

Art. 32 Abs. 1 DSGVO verlangt „die Fähigkeit, die Verfügbarkeit der personenbezogenen Daten und den Zugang zu ihnen bei einem physischen oder technischen Zwischenfall rasch wiederherzustellen“ (lit. c) und „ein Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit“ der Sicherheitsmaßnahmen (lit. d). Art. 21 Abs. 2 lit. c NIS2-Richtlinie verlangt für besonders wichtige und wichtige Einrichtungen „Aufrechterhaltung des Betriebs, wie Backup-Management und Wiederherstellung nach einem Notfall, und Krisenmanagement“. Mehr dazu lesen Sie unter Was Art. 21 verlangt.

Eine brauchbare Nachweismappe pro System enthält:

• Den vereinbarten RPO und RTO und wer sie freigegeben hat.
• Berichte der Backup-Jobs und wie mit Fehlern umgegangen wurde.
• Wiederherstellungsprotokolle: Datum, Umfang, Dauer, Ergebnis und Korrekturen.
• Den Nachweis, dass mindestens eine Kopie unveränderlich und getrennt gespeichert ist.

Hier hilft Automatisierung. Bei Mindtime wird jeder Backup-Job automatisch geprüft und rund um die Uhr überwacht. Bei unserem Disaster-Recovery-Service validiert ein zertifizierter Engineer den ersten Test-Failover, in der Regel innerhalb von 10 Tagen, und automatisierte DR-Tests laufen jedes Quartal, mit Nachweisen für Ihre Prüfer.

Ihre nächsten Schritte

Ein ungetestetes Backup ist eine Annahme. Fangen Sie diese Woche klein an: Stellen Sie eine Datei von vor einem Monat wieder her und messen Sie die Zeit. Nächsten Monat stellen Sie einen ganzen Server in einem isolierten Netzwerk wieder her. Dann halten Sie RPO und RTO pro System schriftlich fest und verfolgen die obigen Kennzahlen dagegen.

Wenn Sie das nicht alles selbst betreiben möchten: Sehen Sie, wie Backup as a Service Prüfungen, Unveränderlichkeit und Wiederherstellungen übernimmt, oder lesen Sie, warum Cloud-Speicher nicht dasselbe ist wie Backup.

Möchten Sie eine Test-Wiederherstellung und die dabei entstehenden Nachweise sehen? Vereinbaren Sie eine kostenlose 15-minütige Demo, auf Deutsch, Niederländisch oder Englisch.

Dieser Artikel ist eine allgemeine Information und keine Rechtsberatung.