Wer sich mit Datensicherung beschäftigt, hat oft ein gutes Gefühl: Backups sind vorhanden, Daten werden regelmässig gesichert, alles scheint unter Kontrolle. Doch im Ernstfall zeigt sich häufig ein anderes Bild. Systeme fallen aus, Anwendungen sind nicht erreichbar – und obwohl Backups existieren, dauert es deutlich länger als erwartet, bis der Betrieb wiederhergestellt ist. Der Grund liegt in einem grundlegenden Missverständnis: Backup und Wiederherstellung sind nicht dasselbe.
Ein Backup stellt sicher, dass Daten zu einem bestimmten Zeitpunkt gesichert sind. Das ist eine unverzichtbare Grundlage, aber noch keine Garantie dafür, dass ein System schnell wieder produktiv genutzt werden kann. Denn zur Wiederherstellung gehört weit mehr als das Zurückspielen von Dateien: Welche Systeme müssen zuerst starten? Welche Abhängigkeiten bestehen zwischen Services? Wie werden Netzwerke und Verbindungen wieder aufgebaut, und welche Konfigurationen sind notwendig, damit am Ende alles zusammenspielt?
Ohne klare Antworten auf diese Fragen bleibt ein Backup genau das: eine Datensicherung. Aber kein funktionierendes Gesamtsystem.
Disaster Recovery geht einen entscheidenden Schritt weiter. Statt nur Daten zu sichern, wird definiert, wie komplette Systeme im Notfall wieder verfügbar gemacht werden. Dazu gehören die vollständige Wiederherstellung von Servern und Anwendungen, klar definierte Abläufe für den Ernstfall in Form von Runbooks, automatisierte Startreihenfolgen, vorbereitete Netzwerkverbindungen sowie durchdachte Failover- und Failback-Szenarien.
Das Ziel ist nicht nur, Daten zu retten, sondern den Betrieb so schnell wie möglich wieder aufzunehmen. Und genau dieser Unterschied – zwischen «Daten sind da» und «der Betrieb läuft wieder» – wird in der Praxis häufig unterschätzt.
In vielen IT-Umgebungen, die wir bei Backup ONE sehen, existieren solide Backups – aber keine klar definierten Wiederherstellungsprozesse. Das zeigt sich häufig erst im Ernstfall: Backups werden zwar erstellt, aber nie unter realistischen Bedingungen getestet. Die effektive Wiederherstellungszeit ist unbekannt. Abhängigkeiten zwischen Systemen sind nicht dokumentiert, und kritische Systeme sind nicht von weniger kritischen priorisiert.
Das Resultat kennen wir aus zahlreichen Gesprächen mit Kunden: Unsicherheit, manuelle Eingriffe und unnötig lange Ausfallzeiten – obwohl die Daten eigentlich vorhanden gewesen wären.
Recovery Time Objective (RTO) und Recovery Point Objective (RPO) helfen, Anforderungen an Ausfallzeiten und akzeptablen Datenverlust zu definieren. In der Praxis werden diese Werte jedoch oft überschätzt, weil sie isoliert vom tatsächlichen Wiederherstellungsprozess betrachtet werden.
Ein Beispiel: Ein Unternehmen definiert ein RTO von 60 Minuten und hat Backups vorhanden. Soweit die Theorie. In der Realität zeigt sich dann aber, dass es keine automatisierte Wiederherstellung gibt, keine vorbereitete Infrastruktur und keine getesteten Abläufe existieren. Das definierte RTO ist schlicht nicht erreichbar. RTO und RPO lassen sich nur dann realistisch einhalten, wenn Backup und Recovery konsequent zusammen gedacht und technisch umgesetzt werden.
Wie sich das konkret auswirkt, zeigt ein typisches Szenario. Eine Anwendung besteht aus mehreren Komponenten: einem API- oder Web-Frontend, einer Datenbank und Object Storage für Dateien. Ein Backup sichert zwar Datenbank und Dateien, aber nicht die Infrastruktur, auf der die Anwendung läuft, nicht die Startreihenfolge der Komponenten und nicht die vollständige Konfiguration der Umgebung.
Im Ernstfall bedeutet das: Alle Teile müssen manuell wieder zusammengesetzt werden – ein zeitaufwändiger und fehleranfälliger Prozess, bei dem unter Druck Fehler passieren. Mit einem durchdachten Disaster-Recovery-Ansatz hingegen werden Systeme automatisiert in der richtigen Reihenfolge gestartet, Abhängigkeiten berücksichtigt und die Anwendung ist innerhalb der definierten Zeit wieder verfügbar.
Genau für dieses Problem haben wir Disaster Recovery as a Service entwickelt. Der Kern des Ansatzes: Ihre Systeme werden nicht nur gesichert, sondern eine zweite, jederzeit verfügbare Umgebung in unserer Swiss Cloud steht bereit, um im Notfall den Betrieb zu übernehmen.
Konkret heisst das: Runbooks definieren exakt, welche Systeme in welcher Reihenfolge und mit welchen Abhängigkeiten hochfahren. Vordefinierte VPN-Verbindungen stellen sicher, dass alle Services sofort miteinander kommunizieren können. Per Failover wird die gesamte Umgebung innerhalb weniger Minuten in der Cloud verfügbar, und sobald die Primärumgebung wieder bereit ist, ermöglicht ein kontrolliertes Failback die Rückführung. Damit wird aus einem klassischen Backup ein vollständig orchestrierter Wiederanlaufprozess – einer, der im Ernstfall nicht improvisiert werden muss, sondern zuverlässig funktioniert.
Ein funktionierendes Setup besteht immer aus zwei Teilen: Backup stellt sicher, dass Daten vorhanden sind. Recovery stellt sicher, dass Systeme wieder laufen. Erst das Zusammenspiel beider Komponenten ermöglicht eine verlässliche Wiederherstellung im Ernstfall.
Die entscheidende Frage ist nicht, ob Ihre Daten gesichert sind – sondern ob Ihr Betrieb im Ernstfall tatsächlich wiederhergestellt werden kann. Reproduzierbar, innerhalb definierter Zeit und ohne improvisierte Eingriffe. Wer sich nur auf Backups verlässt, sichert Daten. Wer Recovery mitdenkt, sichert den Betrieb. Und genau dieser Unterschied entscheidet darüber, ob ein Ausfall zur Krise wird oder zu einem kontrollierbaren Zwischenfall.
Das sind weitere Beiträge, die Sie interessieren könnten.
Zur Blogübersicht