Disaster Recovery

Was umfasst Disaster Recovery?

Disaster Recovery bedeutet auf Deutsch Notfallwiederherstellung und setzt ein, wenn der normale IT-Betrieb durch einen Serverausfall, Cyberangriff, Bedienfehler, Defekt oder Ausfall eines Rechenzentrums erheblich gestört wurde. Ein Disaster-Recovery-Konzept legt fest, welche Systeme in welcher Reihenfolge wiederhergestellt werden, welche Datenquellen dafür genutzt werden und wer die einzelnen Maßnahmen ausführt.

Disaster Recovery beschränkt sich nicht auf das Kopieren von Dateien. Für eine Website müssen beispielsweise Webserver, Datenbanken, Domain-Konfiguration, Zertifikate, Weiterleitungen, Tracking und Schnittstellen wieder zusammenpassen. Ein vorhandenes Backup ist deshalb erst dann belastbar, wenn sich daraus eine funktionierende Umgebung mit korrekten Abhängigkeiten aufbauen lässt.

Disaster Recovery im Hosting

Beim Hosting betrifft Disaster Recovery die technische Infrastruktur, auf der eine Website oder Webanwendung betrieben wird. Der Wiederherstellungsplan muss berücksichtigen, ob die Systeme auf einem einzelnen Server, in einer Cloud-Umgebung, in mehreren Rechenzentren oder über ein Content Delivery Network verteilt sind. Je mehr externe Dienste beteiligt sind, desto wichtiger ist eine vollständige Dokumentation der Zugänge und Abhängigkeiten.

Ein Hosting-Konzept für Disaster Recovery enthält typischerweise folgende Bausteine:

• Automatisierte Sicherungen von Dateien, Datenbanken und Konfigurationen.
• Getrennte Speicherung der Sicherungen außerhalb des produktiven Systems.
• Redundante Server, Netzwerke oder Standorte für besonders wichtige Dienste.
• Dokumentierte Schritte für Failover, Wiederherstellung und Funktionsprüfung.
• Festgelegte Verantwortlichkeiten und erreichbare Ansprechpartner beim Hosting-Anbieter.
• Regelmäßige Wiederherstellungstests mit dokumentiertem Ergebnis.

Disaster Recovery muss auch Fehlerzustände auf Anwendungsebene berücksichtigen. Ein Server kann erreichbar sein, während der Shop keine Bestellungen verarbeitet oder das Content-Management-System nur leere Seiten ausliefert. Technische HTTP-Statuscodes helfen bei der Einordnung: Ein Statuscode 500 kennzeichnet einen internen Serverfehler, 503 eine vorübergehende Nichtverfügbarkeit und 504 eine Zeitüberschreitung zwischen beteiligten Servern.

RTO und RPO richtig festlegen

Disaster Recovery wird vor allem über zwei Zielwerte geplant. Das Recovery Time Objective, kurz RTO, bestimmt die maximal vorgesehene Zeit bis zur Wiederaufnahme eines Dienstes. Das Recovery Point Objective, kurz RPO, bestimmt, wie weit der wiederhergestellte Datenstand höchstens zurückliegen darf. Beide Werte werden pro System festgelegt, weil ein Onlineshop andere Anforderungen als ein internes Archiv hat.

Ein verbreiteter Planungsfehler besteht darin, RTO und RPO ausschließlich nach technischen Möglichkeiten auszuwählen. Die passenden Zielwerte ergeben sich aus den geschäftlichen Folgen. Prüfe für jedes System, wie viele Bestellungen, Leads oder Arbeitsvorgänge pro Stunde entstehen und welche Kosten eine Stunde Ausfall verursacht. Ein sehr niedriges RTO erfordert meist mehr Redundanz und automatisierte Umschaltung als ein System, das erst am folgenden Arbeitstag benötigt wird.

Ablauf einer Wiederherstellung

Ein Disaster-Recovery-Prozess beginnt mit der Bewertung des Vorfalls. Verantwortliche müssen unterscheiden, ob ein einzelner Dienst, ein Server, eine Datenbank oder die gesamte Hosting-Umgebung betroffen ist. Erst danach wird entschieden, ob eine Reparatur, ein Failover auf ein Ersatzsystem oder eine vollständige Wiederherstellung aus einer Sicherung zweckmäßig ist.

Der typische Ablauf besteht aus klar getrennten Phasen:

• Erkennen: Monitoring und Fehlermeldungen grenzen den Ausfall ein.
• Eindämmen: Betroffene Systeme werden isoliert, damit sich fehlerhafte Daten oder Schadsoftware nicht weiterverbreiten.
• Wiederherstellen: Anwendungen, Konfigurationen und Daten werden in der festgelegten Reihenfolge eingespielt.
• Prüfen: Funktionen, Datenstand, Weiterleitungen, Tracking und externe Schnittstellen werden getestet.
• Freigeben: Der produktive Betrieb wird kontrolliert wieder aufgenommen.
• Auswerten: Ursache, Reaktionszeit und Abweichungen vom Plan werden dokumentiert.

Ein Disaster-Recovery-Test sollte nicht beim erfolgreichen Import einer Datenbank enden. Für einen Onlineshop gehören mindestens Produktsuche, Warenkorb, Anmeldung, Zahlung und Bestellbestätigung zur Funktionsprüfung. Bei einer Unternehmenswebsite müssen Formulare, Tracking, Weiterleitungen und angebundene Systeme getestet werden. Das Ergebnis zählt erst, wenn der gesamte kritische Prozess wieder funktioniert.

Unterschied zu Backup und Business Continuity

Der Unterschied zwischen Disaster Recovery und einem Backup liegt im Umfang. Ein Backup ist eine gespeicherte Kopie von Daten. Disaster Recovery beschreibt den vollständigen organisatorischen und technischen Weg zurück zu einem funktionierenden Betrieb. Business Continuity geht noch weiter und regelt, wie ein Unternehmen seine wesentlichen Tätigkeiten während einer Störung fortsetzt.

Ein Hochverfügbarkeitskonzept ist ebenfalls kein Ersatz für Disaster Recovery. Hochverfügbarkeit reduziert Unterbrechungen durch redundante Komponenten und automatische Umschaltung. Überträgt eine Replikation jedoch beschädigte oder gelöschte Daten auf das Ersatzsystem, wird zusätzlich ein unabhängiger Wiederherstellungspunkt benötigt. Prüfe deshalb Redundanz, Replikation und Backups als getrennte Schutzebenen.

Folgen für SEO, SEA und GEO

Disaster Recovery schützt im Online-Marketing die technische Grundlage für SEO, SEA und GEO, also Generative Engine Optimization. Ist eine Website länger nicht erreichbar, können Nutzer, Suchmaschinen-Crawler und KI-Systeme keine Inhalte abrufen. Google Ads kann gleichzeitig weiterhin bezahlte Besucher auf nicht erreichbare Landingpages leiten. Ein Wiederherstellungsplan muss deshalb auch die Pausierung betroffener Kampagnen und die Prüfung zentraler Zielseiten vorsehen.

Nach einer Wiederherstellung dürfen URLs, Statuscodes und Indexierungssignale nicht unbeabsichtigt verändert sein. Fehlende Weiterleitungen, eine alte robots.txt, falsche Canonical Tags oder eine unvollständige XML-Sitemap können die SEO-Sichtbarkeit zusätzlich beeinträchtigen. Bei größeren Änderungen hilft die SEO-Checkliste für den Website-Relaunch, alle relevanten Signale kontrolliert zu prüfen.

Messbar ist Disaster Recovery zum Beispiel über die tatsächliche Wiederherstellungszeit, den Datenverlust seit dem letzten nutzbaren Sicherungspunkt und die Zahl fehlerhafter URLs nach der Freigabe. Der Technik-Crawler der Performance Suite kann nach dem Wiederanlauf HTTP-Fehler, nicht erreichbare Seiten und technische Abweichungen aufdecken. Ergänzend prüft ein kostenloser Ladezeiten-Check, ob das wiederhergestellte Hosting die Website stabil und schnell ausliefert.

Typische Fehler im Notfallplan

Disaster Recovery scheitert häufig an veralteten Zugangsdaten, unbekannten Abhängigkeiten oder einer falschen Wiederanlaufreihenfolge. Wenn beispielsweise die Anwendung vor der Datenbank gestartet wird oder DNS-Einträge auf eine alte Umgebung zeigen, bleibt die Website trotz intakter Sicherung gestört. Halte deshalb Hosting-Zugänge, Domain-Verwaltung, Zertifikate, Schnittstellen und verantwortliche Personen in einer zentralen Dokumentation aktuell.

Ein weiterer Fehler ist die Speicherung aller Sicherungen beim selben Hosting-System. Fällt der gesamte Zugang oder Standort aus, stehen möglicherweise auch die Backups nicht zur Verfügung. Mindestens eine Sicherung sollte technisch und organisatorisch vom Produktivsystem getrennt sein. Lege außerdem fest, wie lange verschiedene Sicherungsstände aufbewahrt werden, damit unbemerkte Fehler nicht alle verfügbaren Versionen überschreiben.

Häufige Fragen zu Disaster Recovery

Wenn du technische Risiken, Hosting und SEO-Sichtbarkeit gemeinsam bewerten möchtest, bietet ein Potenzialcheck eine strukturierte Ausgangsbasis.

Kostenloser Potenzialcheck