Cloud Backup versus Disaster Recovery erklärt

Ein verschlüsselter Fileserver, eine ausgefallene Identity-Plattform oder eine nicht erreichbare Cloud-Region stellt Unternehmen vor dieselbe Kernfrage: Wie schnell können kritische Prozesse wieder arbeiten? Bei Cloud Backup versus Disaster Recovery wird häufig über Speicherorte und Sicherungsintervalle gesprochen. Entscheidend ist jedoch nicht, ob Daten in der Cloud liegen, sondern ob Geschäftsprozesse innerhalb ihrer tolerierbaren Ausfallzeit wieder handlungsfähig sind.

Cloud Backup und Disaster Recovery ergänzen sich, verfolgen aber unterschiedliche Ziele. Wer beide Begriffe gleichsetzt, riskiert eine gefährliche Lücke zwischen der Wiederherstellung einzelner Daten und dem kontrollierten Wiederanlauf eines geschäftskritischen IT-Service. Diese Lücke wird meist erst sichtbar, wenn Zeit, Ressourcen und Entscheidungsfähigkeit knapp sind.

Cloud Backup versus Disaster Recovery: zwei unterschiedliche Ziele

Ein Cloud Backup erstellt und verwahrt Kopien von Daten, Systemen oder Konfigurationen außerhalb der primären IT-Umgebung. Es schützt vor Datenverlust durch versehentliches Löschen, technische Defekte, Ransomware oder lokale Schadensereignisse. Je nach Lösung werden Dateien, Datenbanken, virtuelle Maschinen oder SaaS-Daten gesichert und für eine spätere Wiederherstellung vorgehalten.

Disaster Recovery geht weiter. Es beschreibt die organisatorischen und technischen Vorkehrungen, um definierte IT-Services nach einem schwerwiegenden Ausfall innerhalb vereinbarter Zeiten wieder bereitzustellen. Dazu gehören nicht nur Datenkopien, sondern auch funktionsfähige Infrastruktur, Netzverbindungen, Berechtigungen, Anwendungen, Schnittstellen, Betriebsdokumentation und klar zugewiesene Aufgaben.

Ein Backup beantwortet damit vor allem die Frage: „Welche Daten können wir zurückholen?“ Disaster Recovery beantwortet die weitergehende Frage: „Wie stellen wir einen kritischen Service unter realen Störungsbedingungen wieder her?“

RPO und RTO machen den Unterschied messbar

Für die fachliche Einordnung sind zwei Kennzahlen zentral. Der Recovery Point Objective, kurz RPO, beschreibt den maximal akzeptablen Datenverlust in Zeit. Ist ein RPO von vier Stunden definiert, dürfen im Ernstfall höchstens vier Stunden an Daten fehlen. Das Sicherungsintervall und die Replikationsstrategie müssen dazu passen.

Der Recovery Time Objective, kurz RTO, definiert dagegen, nach welcher Zeit ein Service wieder verfügbar sein muss. Ein Backup kann ein RPO von wenigen Minuten erfüllen und dennoch für ein RTO von zwei Stunden ungeeignet sein, wenn die Wiederherstellung großer Datenmengen, die Bereitstellung von Servern und die Prüfung von Abhängigkeiten einen ganzen Tag beanspruchen.

RPO und RTO sind keine rein technischen Zielwerte. Sie leiten sich aus der Business Impact Analyse im Business Continuity Management ab. Erst wenn klar ist, welche Prozesse, Kundenleistungen, regulatorischen Pflichten und Wertschöpfungsketten betroffen sind, lassen sich angemessene Wiederanlaufziele festlegen.

Warum eine Datenkopie allein keinen Notbetrieb ermöglicht

Die Annahme „Unsere Daten sind gesichert, also sind wir vorbereitet“ greift in vielen Szenarien zu kurz. Bei einem Ransomware-Angriff muss beispielsweise nicht nur ein sauberer Datenstand verfügbar sein. Unternehmen müssen auch klären, ob Administratorzugänge kompromittiert wurden, welche Systeme isoliert werden müssen, ob die Backup-Infrastruktur selbst betroffen ist und in welcher Reihenfolge Services sicher wieder zugeschaltet werden können.

Auch bei einem Ausfall einer Cloud-Region reicht eine replizierte Datenbank nicht automatisch aus. Die Anwendung benötigt möglicherweise spezifische Netzwerkregeln, Zertifikate, Secrets, Load-Balancer-Konfigurationen und Anbindungen an Drittanbieter. Fehlt nur eine dieser Voraussetzungen, ist die Datenbasis vorhanden, der Service jedoch weiterhin nicht nutzbar.

Besonders kritisch sind versteckte Abhängigkeiten. Ein ERP-System kann technisch starten, aber ohne Identity Provider, Druckservice, EDI-Schnittstelle oder Freigabeworkflow nicht produktiv eingesetzt werden. Disaster Recovery betrachtet daher Serviceketten statt isolierter Komponenten. ITSCM überführt diese Sicht in belastbare Wiederanlaufkonzepte, technische Verfahren und regelmäßig überprüfte Notfallhandbücher.

Die passende Vorsorge beginnt beim kritischen Geschäftsprozess

Ob ein einfaches Cloud Backup genügt oder eine umfassende Disaster-Recovery-Architektur erforderlich ist, hängt vom Schutzbedarf des jeweiligen Services ab. Nicht jedes System benötigt eine parallele Betriebsumgebung. Für ein Archivsystem kann eine Wiederherstellung am nächsten Werktag angemessen sein. Für Zahlungsverkehr, Produktionssteuerung, Leitstellenkommunikation oder zentrale Kundenportale wäre sie häufig nicht vertretbar.

Die Tabelle verdeutlicht auch: Disaster Recovery ersetzt Backups nicht. Ein Wiederanlaufkonzept benötigt verlässliche, konsistente und gegen Manipulation geschützte Datenbestände. Umgekehrt wird ein hochwertiges Backup erst dann zu einem belastbaren Baustein der Resilienz, wenn Wiederherstellungswege, Zuständigkeiten und zeitliche Anforderungen definiert sind.

Cloud-Nutzung verändert Verantwortung, nicht die Wiederanlaufpflicht

Cloud-Provider stellen hochverfügbare Plattformen bereit. Das entbindet Kunden jedoch nicht davon, die Wiederherstellbarkeit ihrer eigenen Daten, Konfigurationen und Anwendungen zu planen. Das Shared-Responsibility-Modell muss für jeden Service konkret ausgelegt werden: Der Anbieter sichert bestimmte Bestandteile der Plattform, während das Unternehmen unter anderem für Identitäten, Datenklassifizierung, Mandantenkonfiguration, Berechtigungen und eigene Anwendungen verantwortlich bleibt.

Das gilt besonders für SaaS-Dienste. Eine hohe Verfügbarkeit der Plattform schützt nicht zwingend vor fehlerhaften Löschungen, falschen Berechtigungen, Synchronisationsfehlern oder böswilligen Änderungen im eigenen Mandanten. Deshalb sollte die Backup- und Wiederanlaufstrategie auch SaaS-Daten, Konfigurationsstände sowie administrative Zugänge berücksichtigen.

Eine zweite Cloud-Region oder ein zweiter Provider kann die Ausfallsicherheit erhöhen, führt aber zugleich zu zusätzlicher Komplexität. Datenkonsistenz, Kosten, Betriebsprozesse, Sicherheitskontrollen und Fachwissen müssen dauerhaft gepflegt werden. Multicloud ist keine automatische Disaster-Recovery-Strategie. Sie ist nur dann sinnvoll, wenn sie aus den Anforderungen kritischer Services abgeleitet und technisch wie organisatorisch beherrscht wird.

ITSCM verbindet Technik, Organisation und Krisenmanagement

Disaster Recovery ist ein Kernbestandteil des IT Service Continuity Managements. ITSCM sorgt dafür, dass Wiederanlaufziele aus dem BCM in technische Anforderungen übersetzt werden. Dazu werden kritische Services identifiziert, Abhängigkeiten analysiert, Wiederanlaufverfahren dokumentiert und Tests geplant.

Im Ernstfall braucht es zusätzlich Entscheidungsfähigkeit. Wer entscheidet über die Ausrufung des Notbetriebs? Welche Informationen erhält die Geschäftsführung? Wann werden Kunden, Aufsichtsstellen oder Dienstleister eingebunden? Krisenmanagement und IT-Notfallvorsorge müssen deshalb aufeinander abgestimmt sein. Ein technisch möglicher Failover hilft wenig, wenn Freigaben, Kommunikationswege und Prioritäten ungeklärt bleiben.

Für regulierte Unternehmen und Betreiber kritischer Infrastrukturen ist diese Nachweisbarkeit besonders relevant. Anforderungen aus NIS-2, DORA, KRITIS oder orientierende Vorgaben wie BSI 200-4 verlangen keine bloße Sammlung von Dokumenten. Gefordert sind angemessene Maßnahmen, klar geregelte Verantwortlichkeiten und eine überprüfbare Vorsorge für Störungen und Krisen.

So wird aus Backup eine belastbare Wiederanlauffähigkeit

Der Weg zu einer angemessenen Lösung beginnt nicht mit der Produktauswahl, sondern mit einer belastbaren Priorisierung. In der Praxis haben sich fünf Arbeitsschritte bewährt:

• Kritische Geschäftsprozesse und unterstützende IT-Services anhand einer Business Impact Analyse priorisieren.
• Für jeden priorisierten Service RTO, RPO, Mindestbetriebsumfang und akzeptable manuelle Ausweichverfahren festlegen.
• Technische und organisatorische Abhängigkeiten erfassen, einschließlich Identitäten, Netzwerken, Dienstleistern, Datenflüssen und Schlüsselpersonen.
• Wiederanlaufverfahren so dokumentieren, dass qualifizierte Teams sie auch unter Zeitdruck nachvollziehen und ausführen können.
• Backups, Wiederherstellungen und vollständige Wiederanlaufszenarien regelmäßig testen, bewerten und nachsteuern.

Tests verdienen besondere Aufmerksamkeit. Eine erfolgreich wiederhergestellte Datei ist ein sinnvoller Kontrollnachweis, aber kein Beleg für die Betriebsfähigkeit eines kritischen Services. Aussagekräftig wird ein Test erst, wenn Teams unter realistischen Bedingungen prüfen, ob Systeme in der vorgesehenen Reihenfolge starten, Daten konsistent sind, Schnittstellen funktionieren und die Fachbereiche ihre Mindestleistungen erbringen können.

Mit einer zentralen Plattform wie [alive-IT] lassen sich Abhängigkeiten, Maßnahmen, Notfallpläne und Testnachweise konsolidieren und kontinuierlich pflegen. Entscheidend bleibt jedoch die gelebte Zusammenarbeit von Fachbereichen, IT, Informationssicherheit, Risikomanagement und Krisenorganisation.

Die hilfreiche Frage für die nächste Risiko- oder Architekturentscheidung lautet daher nicht: „Haben wir ein Cloud Backup?“ Sie lautet: „Können wir unseren kritischen Service nach diesem Szenario nachweisbar, sicher und rechtzeitig wieder betreiben?“ Wer diese Frage regelmäßig mit einem Test beantwortet, schafft Resilienz, die im Ernstfall trägt.