34% aller Unternehmen testen ihre Disaster-Recovery-Backups nicht. 71% führen keine Failover-Tests durch. Und nur 12% erreichen bei einem tatsächlichen Test die angestrebte Wiederherstellungszeit. Diese Zahlen stammen nicht aus einer Einzelstudie, sondern ziehen sich durch die gesamte Branchenforschung von Secureframe und Inveni IT. Sie zeichnen ein Bild, das unbequem, aber ehrlich ist.
Denn die Frage ist nicht, ob Ihr Unternehmen einen Disaster-Recovery-Plan hat. Die meisten haben einen. Die Frage ist, ob dieser Plan funktioniert, wenn es darauf ankommt.
Ein Disaster-Recovery-Plan auf Papier gibt ein gutes Gefühl. Er definiert Zuständigkeiten, beschreibt Abläufe, legt Wiederherstellungszeiten fest. Das Problem: Zwischen einem dokumentierten Ablauf und einem funktionierenden Prozess liegen Welten.
Stellen Sie sich vor, Ihre Produktivumgebung fällt am Montagmorgen komplett aus. Server nicht erreichbar, Datenbank korrupt, Applikationen offline. Jetzt muss es schnell gehen. Der DR-Plan sagt: Restore aus dem Cloud-Backup, RTO vier Stunden. Nur hat niemand geprüft, ob das Backup der letzten Nacht vollständig war. Niemand weiss, ob der Restore-Prozess mit der aktuellen Systemkonfiguration überhaupt kompatibel ist. Und die Person, die als Verantwortliche eingetragen ist, hat das Unternehmen vor sechs Monaten verlassen.
Das klingt überspitzt. Ist es aber nicht. Laut aktuellen Erhebungen sind unvollständige Dokumentation und veraltete Zuständigkeiten die häufigsten Gründe, warum DR-Tests scheitern.
Die Gründe sind immer die gleichen. Laut einer Erhebung von WifiTalents nennen 61% der befragten Unternehmen Zeitmangel als Hauptgrund. 51% verweisen auf fehlende Ressourcen. Und 34% geben an, dass Disaster Recovery schlicht keine Priorität hat.
Das ist nachvollziehbar. Im Tagesgeschäft gibt es immer Dringenderes: ein neues Projekt, ein Sicherheitsupdate, ein Kundenproblem. Ein DR-Test produziert keinen sichtbaren Output. Er generiert keinen Umsatz. Und wenn er gut läuft, passiert nichts. Genau das macht ihn so schwer priorisierbar.
Gleichzeitig ist es ein Trugschluss, der teuer werden kann. Unternehmen ohne getesteten DR-Plan zahlen im Ernstfall durchschnittlich 2,3-mal höhere Wiederherstellungskosten als Unternehmen, die regelmässig testen. Und 40% der KMU, die einen grösseren Datenvorfall ohne funktionierenden Notfallplan erleben, erholen sich davon nicht mehr.
Ein DR-Plan kann auf verschiedene Arten scheitern. Manche davon sind technischer Natur, die meisten aber organisatorisch.
Backups, die nie geprüft werden. Ein Backup-Job läuft jede Nacht durch und meldet «erfolgreich». Aber was genau wurde gesichert? Sind alle relevanten Systeme enthalten? Sind die Daten konsistent? Laut CrashPlan sind 60% aller Datensicherungen unvollständig. Eine Zahl, die erst auffällt, wenn ein Restore nötig wird.
Wiederherstellungszeiten, die niemand kennt. Viele Unternehmen definieren eine RTO von vier oder acht Stunden. Ob der Restore tatsächlich in dieser Zeit gelingt, wurde aber nie gemessen. Im Test zeigt sich dann: Der Restore dauert 18 Stunden. Oder scheitert ganz, weil ein Treiber fehlt, eine Lizenz abgelaufen ist oder eine Abhängigkeit übersehen wurde. Nur 12% der Unternehmen erreichen ihre definierte RTO tatsächlich.
Veränderte Infrastruktur. IT-Umgebungen verändern sich laufend. Neue Server, neue Applikationen, migrierte Datenbanken, veränderte Netzwerkarchitekturen. Ein DR-Plan, der vor 18 Monaten erstellt wurde, bildet eine Infrastruktur ab, die es nicht mehr gibt. Ohne regelmässige Aktualisierung wird der Plan zur Momentaufnahme, präzise für einen Zustand, der nicht mehr existiert.
Menschliche Faktoren. Wer ist zuständig? Wer hat die Zugangsdaten zum Backup-System? Wer kennt den Ablauf? Wer entscheidet, welche Systeme priorisiert wiederhergestellt werden? Wenn diese Fragen erst im Ernstfall geklärt werden, gehen wertvolle Stunden verloren.
Ein DR-Test muss nicht die gesamte Infrastruktur lahmlegen. Aber er muss realistisch genug sein, um echte Schwachstellen aufzudecken.
Restore-Tests einzelner Systeme. Beginnen Sie mit dem Wichtigsten: Können Sie Ihre geschäftskritischen Systeme aus dem Backup wiederherstellen? Nicht theoretisch, sondern praktisch. In einer Testumgebung, mit den tatsächlichen Backup-Daten von letzter Nacht. Messen Sie die Zeit. Prüfen Sie die Datenintegrität. Dokumentieren Sie jeden Schritt, der hakt.
Failover-Szenarien. Wenn Sie eine Disaster-Recovery-Lösung mit Failover nutzen: Testen Sie den Schwenk. Wie lange dauert es, bis das Ersatzsystem produktiv ist? Funktionieren alle Abhängigkeiten? Erreichen die Nutzer die Applikationen?
Kommunikationstest. Wer wird im Ernstfall informiert? Über welchen Kanal? Funktioniert die Eskalationskette? Ein DR-Szenario ist kein reines IT-Problem. Es betrifft Geschäftsleitung, Kunden, Partner, unter Umständen Behörden. Seit April 2025 gilt in der Schweiz die Meldepflicht für Cyberangriffe auf kritische Infrastrukturen, mit einer Frist von 24 Stunden.
Dokumentation der Ergebnisse. Jeder Test sollte ein Protokoll liefern: Was hat funktioniert? Was nicht? Wo liegt die tatsächliche RTO? Welche Systeme wurden übersehen? Dieses Protokoll ist die Grundlage für die nächste Iteration des DR-Plans.
Die Antwort hängt von der Komplexität Ihrer Umgebung ab. Als Minimum empfehlen die meisten Standards, darunter ISO 22301, mindestens einen vollständigen DR-Test pro Jahr. Für geschäftskritische Systeme sind halbjährliche oder quartalsweise Tests sinnvoll.
Mindestens genauso wichtig wie der grosse Jahrestest sind regelmässige Restore-Checks einzelner Systeme. Ein monatlicher Stichproben-Restore, ein einzelner Server, eine Datenbank, ein Postfach, dauert wenig Zeit und liefert kontinuierlich Erkenntnisse über den Zustand der Datensicherung.
Entscheidend ist: Nach jeder grösseren Änderung an der IT-Infrastruktur sollte der DR-Plan überprüft und bei Bedarf angepasst werden. Ein neuer Server, eine Cloud-Migration, ein Wechsel des Backup-Tools. All das kann bestehende Abläufe invalidieren.
Disaster Recovery ist für uns kein Produkt, das einmal eingerichtet und dann vergessen wird. Es ist ein Prozess, der regelmässig geprüft werden muss.
Deshalb bieten wir nicht nur die technische Infrastruktur mit georedundanter Speicherung in Zürich und Genf, verschlüsselten Backups mit Zero-Knowledge-Prinzip und Immutable Storage per S3 Object Lock. Wir unterstützen unsere Kunden aktiv dabei, ihre Wiederherstellung zu testen. Unsere Disaster-Recovery-Lösung als Managed Service ermöglicht es, gesicherte Systeme direkt aus der Backup ONE Swiss Cloud zu booten und in einer isolierten Umgebung zu prüfen, ob der Restore funktioniert. Ohne Risiko für die Produktivumgebung. Ohne stundenlangen Aufwand.
Dazu kommen unabhängige Zugangsdaten, die getrennt von Ihrer Active-Directory-Umgebung funktionieren. Das bedeutet: Selbst wenn ein Angreifer Ihre lokale IT kompromittiert, bleibt der Zugang zu Ihren Backup-Daten geschützt. Und Ihre DR-Tests bilden genau dieses Szenario ab. Nicht den Best Case, sondern den Ernstfall.
Ein Disaster-Recovery-Plan, der nie getestet wurde, ist eine Hypothese. Nicht mehr. Die Statistiken zeigen deutlich: Die meisten Pläne scheitern nicht an fehlender Technologie, sondern an mangelnder Praxis. An veralteten Dokumenten, ungeprüften Backups und Prozessen, die auf dem Papier funktionieren, aber nicht in der Realität.
Der beste Zeitpunkt für einen DR-Test ist nicht nach dem nächsten Vorfall. Er ist jetzt.
Möchten Sie wissen, wie ein realistischer DR-Test für Ihre Umgebung aussehen könnte? Kontaktieren Sie uns. Wir helfen Ihnen, Ihren Notfallplan vom Papier in die Praxis zu bringen.
Das sind weitere Beiträge, die Sie interessieren könnten.
Zur Blogübersicht