Der Recovery-Test-Check: Woran Sie erkennen, ob Ihr Backup im Ernstfall wirklich hilft
Ein grünes Backup-Häkchen ist kein Beweis – nur eine Behauptung
„Backup erfolgreich“ steht in fast jedem Monitoring-Dashboard, jede Nacht, in jedem Unternehmen. Was diese Meldung nicht belegt: ob sich aus der Sicherung tatsächlich ein lauffähiges System wiederherstellen lässt. Wie groß diese Lücke tatsächlich ist, zeigen zwei aktuelle Studien mit bemerkenswerter Übereinstimmung – und ein Fall aus Nordrhein-Westfalen macht sichtbar, was das in der Praxis bedeutet, selbst wenn die Backups technisch einwandfrei sind.
Inhaltsverzeichnis
Die Zahlen: Was aktuelle Studien über die Recovery-Lücke belegen
Der siebte „State of Ransomware“-Report von Sophos, veröffentlicht im Juli 2026, basiert auf einer anbieterneutralen Befragung von 2.158 IT- und Cybersecurity-Verantwortlichen aus 17 Ländern, deren Organisationen im vorangegangenen Jahr von Ransomware betroffen waren. Zentrale Befunde: Bei 56 Prozent der Angriffe gelang die Verschlüsselung der Daten. In diesen Fällen griffen 66 Prozent der Betroffenen auf Backups zur Wiederherstellung zurück – ein Anstieg um 12 Prozentpunkte gegenüber dem Vorjahr. Gleichzeitig stiegen die durchschnittlichen Wiederherstellungskosten pro Vorfall auf 1,7 Millionen US-Dollar, ein Plus von 11 Prozent gegenüber 2025. Bei kleineren Organisationen mit 100 bis 250 Mitarbeitenden gelang es nur in 34 Prozent der Fälle, einen Angriff vor der Verschlüsselung zu stoppen – bei Organisationen mit 3.001 bis 5.000 Mitarbeitenden waren es 46 Prozent.
Der „2026 State of Data Resilience Report“ von Arcserve, veröffentlicht im Frühjahr 2026, deckt eine zweite, ergänzende Lücke auf: 65,1 Prozent der befragten IT-Fach- und Führungskräfte zeigen sich zuversichtlich, ransomwarebedingte Ausfälle innerhalb von 48 Stunden beheben zu können. Tatsächlich erreichten jedoch nur 35,4 Prozent ihre definierten RPO- und RTO-Ziele in echten Wiederherstellungstests. Ergänzend zeigt die Studie, dass bereits 52,3 Prozent der Befragten von einem Ransomware-Angriff betroffen waren, 19,0 Prozent über kein SaaS-Backup verfügen und 88,7 Prozent zwei oder mehr Datensicherungslösungen parallel einsetzen – ein Umstand, der laut Arcserve zu uneinheitlichen Richtlinien und blinden Flecken bei der Wiederherstellung führt.
Fallbeispiel: Wie intakte Backups elf Monate Krisenmodus nicht verhinderten
Am 30. Oktober 2023 verschlüsselte die Ransomware-Gruppe „Akira“ die Systeme der Südwestfalen-IT (SIT), eines kommunalen IT-Dienstleisters, der zu diesem Zeitpunkt bis zu 103 Kommunen in Nordrhein-Westfalen versorgte. Der Fall ist gut dokumentiert und öffentlich nachvollziehbar, unter anderem durch Berichterstattung von heise online und die eigene Bilanz der SIT ein Jahr nach dem Vorfall.
Der entscheidende Punkt: Die Backups der SIT waren vom Angriff nicht betroffen und technisch vollständig nutzbar. Trotzdem dauerte der offiziell erklärte Krisenmodus insgesamt elf Monate. Der Grund lag nicht in fehlenden Sicherungen, sondern im fehlenden geübten Wiederherstellungsprozess: Mehr als 700 einzelne Daten-Backups mussten nacheinander geprüft und eingespielt werden, dazu kamen mehrere hundert externe Systemverbindungen – etwa zu Vergabeportalen oder Fachverfahren –, die einzeln kontrolliert und neu eingerichtet werden mussten. Rund 170 Personen waren zeitweise mit der Bewältigung befasst. Die SIT bezifferte die entstandenen Mehrkosten ein Jahr nach dem Vorfall auf mindestens 2,8 Millionen Euro.
Der Fall zeigt exemplarisch, warum Backup-Existenz nicht mit Wiederherstellungsfähigkeit gleichzusetzen ist: Ohne einen zuvor getesteten, priorisierten und automatisierten End-to-End-Wiederherstellungsprozess wird aus einer technisch erfolgreichen Sicherung ein monatelanges manuelles Wiederaufbauprojekt.
Der Selbst-Check: 6 Fragen, die Ihre echte Wiederherstellungsfähigkeit zeigen
Beantworten Sie die folgenden Fragen ehrlich – nicht danach, wie es geplant war, sondern danach, wann es zuletzt tatsächlich passiert ist:
1. Wann wurde zuletzt ein vollständiges System aus einem Backup wiederhergestellt – nicht simuliert, sondern real? Liegt die Antwort länger als ein Quartal zurück oder lässt sie sich nicht klar beantworten, ist die Wiederherstellbarkeit unbewiesen.
2. Wurde beim letzten Test die komplette Anwendungskette geprüft – inklusive Active Directory, DNS, Zertifikatsdienste und externer Systemverbindungen? Der Fall Südwestfalen-IT zeigt, dass gerade externe Abhängigkeiten – dort mehrere hundert Verbindungen zu Fachportalen – oft die größte, am wenigsten getestete Fehlerquelle sind.
3. Wurden wiederhergestellte Daten vor der Rückführung in den Produktivbetrieb auf aktive Schadsoftware geprüft? Ohne diesen Schritt kann ein Restore einen bereits kompromittierten Zustand unbemerkt reaktivieren.
4. Sind RTO und RPO gemessene Werte aus echten Tests – oder geschätzte Zielgrößen aus der Konzeptphase? Laut Arcserve-Report erreichen nur 35,4 Prozent der Unternehmen ihre eigenen RPO- und RTO-Ziele in echten Wiederherstellungstests – ungetestete Zielwerte sind häufig zu optimistisch angesetzt.
5. Ist dokumentiert, wer im Ernstfall welche Entscheidung trifft und welchen Zugriff hat? Auch bei der SIT war ein wesentlicher Teil des elfmonatigen Aufwands organisatorischer Natur – Priorisierung, Abstimmung mit Krisenstäben, Freigabeprozesse.
6. Existiert eine schriftliche Dokumentation von Testdatum, Testumfang und Ergebnis? Ohne Dokumentation ist ein erfolgreicher Test im Zweifel nicht existent – weder intern noch gegenüber einer Aufsichtsbehörde.
Wer mehr als zwei dieser Fragen nicht klar mit Ja beantworten kann, verlässt sich im Ernstfall auf eine Annahme statt auf einen Nachweis – ähnlich wie die knapp 30 Prozentpunkte Differenz zwischen Zuversicht (65,1 Prozent) und tatsächlich erreichten RPO/RTO-Zielen (35,4 Prozent), die der Arcserve-Report für den Durchschnitt der befragten Organisationen dokumentiert.
4 Testmethoden, die aus Theorie einen Nachweis machen
Isolierter Einzelsystem-Restore: Ein einzelner Server oder eine Applikation wird in einer abgeschotteten Testumgebung wiederhergestellt. Zeigt, ob die Sicherung grundsätzlich lesbar und nutzbar ist – der Basistest, aber allein nicht ausreichend, wie der Fall Südwestfalen-IT zeigt.
End-to-End-Recovery-Test: Der komplette Anwendungsverbund wird inklusive aller Abhängigkeiten wiederhergestellt. Erst hier zeigen sich Probleme, die bei Einzeltests unsichtbar bleiben – etwa eine falsche Wiederherstellungsreihenfolge zwischen Identitäts- und Applikationsschicht oder ungeprüfte externe Schnittstellen.
Malware-Scan der wiederhergestellten Daten: Vor der Rückführung in die Produktivumgebung werden die wiederhergestellten Systeme aktiv auf Schadsoftware geprüft, um eine erneute Kompromittierung durch den Restore selbst auszuschließen. Laut Sophos-Report begann eine wachsende Mehrheit der Angriffe – 79 Prozent im Jahr 2026 – über kompromittierte Zugangsdaten, mit teils wochenlanger unbemerkter Vorbereitungszeit vor der eigentlichen Verschlüsselung.
Tabletop-Übung: Ein Ausfallszenario wird auf organisatorischer Ebene durchgespielt – wer entscheidet, wer hat Zugriff, wie wird kommuniziert. Genau dieser organisatorische Aufwand band bei der SIT einen erheblichen Teil der rund 170 beteiligten Personen.
RTO und RPO richtig ermitteln: Warum Planzahlen ohne Test wertlos sind
Die Recovery Time Objective (RTO) beschreibt, wie lange eine Wiederherstellung maximal dauern darf. Der Recovery Point Objective (RPO) beschreibt, wie viel Datenverlust – gemessen als Zeitfenster zwischen letzter Sicherung und Ausfall – akzeptabel ist. Beide Werte werden in Konzeptpapieren oft geschätzt, aber laut Arcserve-Report erreichen nur 35,4 Prozent der Unternehmen diese Zielwerte tatsächlich in echten Wiederherstellungstests. Ein Unternehmen, das eine RTO von vier Stunden plant, aber – wie im Fall SIT – noch nie gemessen hat, wie lange ein realer End-to-End-Restore mit allen externen Abhängigkeiten dauert, kennt seine echte Ausfallzeit schlicht nicht.
Was NIS2 und DSGVO konkret fordern, wenn der Restore-Test fehlt
Seit dem 6. Dezember 2025 gilt NIS2 für einen erheblich erweiterten Kreis betroffener Unternehmen und verlangt ausdrücklich ein dokumentiertes Backup-Konzept mit definierten RTO- und RPO-Werten sowie regelmäßige, nachweisbare Wiederherstellungstests. Diese Nachweise können bei einer BSI-Prüfung über einen Zeitraum von bis zu drei Jahren angefordert werden. Bußgelder bei nachgewiesenen Verstößen reichen bis zu 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes.
Zusätzlich verpflichtet Artikel 33 der DSGVO Unternehmen dazu, Aufsichtsbehörden innerhalb von 72 Stunden zu informieren, wenn der wiederhergestellte Zustand betroffener personenbezogener Daten nicht nachgewiesen werden kann – unabhängig davon, ob die Daten durch Verschlüsselung oder durch einen fehlgeschlagenen Restore verloren gingen. Ein nicht bestandener Recovery-Test ist damit kein internes IT-Detail, sondern ein potenziell meldepflichtiges Ereignis.
Der Leitfaden: In 5 Schritten zu einem belastbaren Recovery-Testplan
Schritt 1 – Kritikalität priorisieren.
Systeme mit geschäftskritischer Funktion identifizieren und für diese die höchste Testfrequenz ansetzen; nicht alle Systeme benötigen dieselbe Prüftiefe.
Schritt 2 – End-to-End statt Einzeltest planen.
Testszenarien so gestalten, dass Abhängigkeiten zwischen Systemen und externe Schnittstellen realistisch abgebildet werden – genau der Punkt, an dem der Fall Südwestfalen-IT die meiste Zeit kostete.
Schritt 3 – Malware-Prüfung fest einbauen.
Jeden Restore-Test um einen Scan auf aktive Schadsoftware ergänzen, bevor Daten zurück in den Produktivbetrieb gehen.
Schritt 4 – Automatisieren, um Frequenz zu erhöhen.
Manuelle Tests werden aus Kapazitätsgründen häufig verschoben. Automatisierte, wiederkehrende Testläufe in isolierten Umgebungen liefern kontinuierliche Nachweise ohne dauerhafte Bindung operativer Teams – genau in diesem Bereich sieht der Arcserve-Report die größte Lücke zwischen Risikobewusstsein und tatsächlicher Umsetzung.
Schritt 5 – Ergebnisse NIS2-tauglich dokumentieren.
Testdatum, Testumfang, Ergebnis sowie gemessene RTO- und RPO-Werte strukturiert festhalten, um im Prüfungsfall sofort nachweisfähig zu sein.
Expertensicht: Die drei häufigsten Irrtümer beim Recovery Testing
Aus Sicht erfahrener Backup- und Resilience-Spezialisten liegt das zentrale Risiko selten in der eingesetzten Technologie, sondern in der stillschweigenden Gleichsetzung von Backup-Erfolg und Wiederherstellbarkeit – ein Muster, das sich sowohl in den aktuellen Studiendaten als auch im Fall Südwestfalen-IT zeigt. Ein weiteres wiederkehrendes Risiko: Einzelsysteme gelten isoliert als getestet, während die Gesamtwiederherstellung an unberücksichtigten externen Abhängigkeiten scheitert. Und selbst technisch einwandfrei getestete Prozesse laufen ins Leere, wenn im Ernstfall unklar ist, wer sie auslöst – Wiederherstellungsfähigkeit ist damit ebenso eine organisatorische wie eine technische Kennzahl.
Fazit: Erst der bestandene Recovery-Test beweist echte Wiederherstellbarkeit
Ein Backup ist eine Behauptung. Ein bestandener, dokumentierter Recovery-Test ist ein Beweis. Der Fall Südwestfalen-IT zeigt, dass selbst technisch intakte Backups einen elfmonatigen Krisenmodus nicht verhindern, wenn der Wiederherstellungsprozess ungeübt ist – und aktuelle Studien von Sophos und Arcserve belegen, dass diese Lücke kein Einzelfall, sondern ein branchenweites Muster ist. Wer die sechs Fragen aus dem Selbst-Check nicht klar beantworten kann, sollte Recovery Testing nicht als nächstes Projekt, sondern als nächsten Termin behandeln.
FAQ: Die wichtigsten Fragen zu Recovery Testing und Restore-Tests
Was ist der Unterschied zwischen Backup-Monitoring und Recovery Testing?
Backup-Monitoring prüft, ob ein Sicherungsjob technisch erfolgreich abgeschlossen wurde. Recovery Testing prüft, ob sich daraus tatsächlich ein funktionsfähiges System innerhalb der geforderten Zeit wiederherstellen lässt.
Wie viele Unternehmen schaffen nach einem Ransomware-Angriff eine vollständige Wiederherstellung?
Laut dem Arcserve 2026 State of Data Resilience Report erreichen nur 35,4 Prozent der Organisationen ihre RPO- und RTO-Ziele in echten Wiederherstellungstests, obwohl 65,1 Prozent zuvor von einer Wiederherstellung innerhalb von 48 Stunden ausgingen.
Wie oft sollten Restore-Tests durchgeführt werden?
Die Frequenz richtet sich nach der Kritikalität des Systems. Für geschäftskritische Anwendungen empfiehlt sich mindestens ein vollständiger Wiederherstellungstest pro Quartal, ergänzt durch automatisierte, häufigere Teilprüfungen.
Was bedeuten RTO und RPO konkret?
RTO beschreibt die maximal tolerierbare Zeitspanne bis zur vollständigen Wiederherstellung. RPO beschreibt den maximal akzeptierten Datenverlust, gemessen als Zeitfenster zwischen letzter Sicherung und Ausfall.
Welche Rolle spielt NIS2 bei Recovery Testing?
NIS2 verpflichtet betroffene Unternehmen zu einem dokumentierten Backup-Konzept mit definierten RTO- und RPO-Werten sowie zu regelmäßigen, nachweisbaren Wiederherstellungstests, die bei BSI-Prüfungen vorgelegt werden müssen.
Kann ein intaktes Backup trotzdem zu einer monatelangen Wiederherstellung führen?
Ja. Der dokumentierte Fall der Südwestfalen-IT zeigt, dass über 700 technisch unbeschädigte Backups und zahlreiche externe Systemverbindungen einzeln geprüft und eingespielt werden mussten, was einen elf Monate dauernden Krisenmodus zur Folge hatte.
Reicht ein isolierter Einzelsystem-Test aus?
Nein. Er zeigt nur, ob eine einzelne Sicherung lesbar ist, nicht ob die Gesamtumgebung inklusive externer Abhängigkeiten innerhalb der geforderten Zeit wiederhergestellt werden kann.
Wie belastbar ist Ihre Wiederherstellungsfähigkeit tatsächlich?
Die sechs Fragen aus dem Selbst-Check beantwortet nur, wer regelmäßig testet. Automatisierte Wiederherstellungstests schaffen dafür einen wiederholbaren, dokumentierten Nachweis – auch für NIS2. Die Expertinnen und Experten von Cristie Data helfen, den passenden Ansatz für die eigene Infrastruktur zu finden.
