Die Notfallwiederherstellung war schon immer das Teuerste, wofür niemand die Kosten übernehmen will.
Es ist wie bei einer Versicherung, nur dass man statt einer monatlichen Prämie ein Investitionsprojekt, einen zweiten Standort und das Privileg erhält, festzustellen, dass in Ihrem „vollständig redundanten“ Konzept ein winziges Detail fehlt: nämlich dass es tatsächlich funktioniert, wenn man es braucht.
Während des größten Teils meiner beruflichen Laufbahn bedeutete „echte DR“ den Aufbau einer zweiten Umgebung: so ähnlich wie ein zweites Frühstück, nur VIEL teurer. Das bedeutete:
- Ein weiteres Rechenzentrum (oder Colocation-Rack)
- Ein weiterer Stapel Server
- Noch ein Stapel zum Verstauen
- Ein weiterer Satz Netzwerkgeräte
- Eine weitere Reihe von Lizenzen
- Ein weiterer Vertrag
- Eine weitere Rechnung
- Eine weitere Gruppe von Menschen, die sich vage daran erinnerten, wie es eingerichtet war
Und dann: Replikation. In der Regel erfolgt dies auf die „klassische“ Art und Weise: Hyper-V-Failover-Cluster, gestreckte Netzwerke, replizierter Speicher, Orchestrierungsskripte, benutzerdefinierte Runbooks und so viel Änderungskontrolle, dass man vergisst, wie sich Glück anfühlt. Ich habe solche Systeme aufgebaut. Ich habe den Traum von zwei Standorten gelebt. Und ich habe auch die Rechnungen gesehen – gleich zu Beginn und dann jeden Monat.
Einen sechsstelligen Betrag für den Aufbau einer einzelnen Website vergisst man nicht. Genauso wenig vergisst man den Moment, in dem die Geschäftsleitung fragt: „Und wie oft testen wir eigentlich das Failover?“, und plötzlich alle plötzlich großes Interesse an ihrem Kaffee zeigen und ihre Nachrichten auf dem Handy checken.
Die alte Methode: Geld ausgeben, um eine zweite Realität aufrechtzuerhalten
Herkömmliche DR ist nicht „etwas, das man kauft“. Es ist ein Ökosystem. Hier sind die Kosten, die immer anfallen, unabhängig davon, ob sie im Budget vorgesehen sind oder nicht:
- Die Standortgebühr: Colocation ist nicht nur ein Rack. Dazu gehören Strom, Kühlung, Cross-Connects, Bandbreite, Remote-Hands, Zugangskontrollen und monatliche Gebühren, die so hoch sind, als wollten sie sich für eine Managervergütung qualifizieren.
- Die Hardware-Steuer: Die DR-Infrastruktur entspricht selten genau den Produktionsanforderungen. Entweder ist sie überdimensioniert („Vielleicht brauchen wir das ja irgendwann mal!“) oder unterdimensioniert („Im Katastrophenfall reduzieren wir einfach den Umfang!“) – was eine nette Umschreibung dafür ist, dass wir einen Ausfall in Kauf nehmen, aber mit entsprechender Dokumentation.
- Die Netzwerk-Steuer: Redundante WAN-Verbindungen, Firewalls, VPN-Konzentratoren, komplexe Routing-Strukturen, DNS-Akrobatik und jede Menge „vorübergehende“ Regeln, die ewig bestehen bleiben.
- Die Lizenzgebühr: Sie zahlen dafür, dass Sie das, was Ihnen bereits gehört, an einem anderen Ort betreiben dürfen – für den Fall, dass heute der Tag ist.
- Der personelle Aufwand: Der teuerste Faktor ist das, was man nicht einfach stapeln und lagern kann: Fachwissen. Denn Disaster Recovery ist keine einmalige Angelegenheit, die man dann vergessen kann. Es ist eher so: Einmal einrichten, dann vergessen – und anschließend alles ändern und hoffen, dass das Runbook noch immer zutrifft.
Und nach all dem testen die meisten Unternehmen das Failover etwa so oft, wie sie die Batterien ihrer Notfalltaschenlampe austauschen: nämlich erst, wenn schon etwas schiefgelaufen ist.
Der neue Weg: Azure Site Recovery
Azure Site Recovery (ASR) ist eines der wenigen Tools in der IT, das genau das hält, was es verspricht. Es repliziert Ihre Workloads in Azure, sodass Sie bei Bedarf ein Failover durchführen können, ohne ein komplettes zweites Rechenzentrum unterhalten zu müssen, nur um zu beweisen, dass Sie es mit der Geschäftskontinuität ernst meinen.
Das ist die Marketing-Fassung. Und so sieht die Realität aus:
- Kontinuierliche Replikation der unterstützten Workloads und der Infrastruktur
- Vorhersehbare, konfigurierbare Failover-Pläne, einschließlich Reihenfolge und Abhängigkeiten
- Automatisierte Runbooks, denn „Was soll das heißen, das Rechenzentrum ist nicht vor den SQL-Servern hochgefahren?“ ist keine Strategie.
- Beeindruckend niedrige RTO im Vergleich zum alten Modell, bei dem man sich bei sechs Konsolen anmeldete und auf das Beste hoffte
- DR, das sich wie ein Dienst skalieren lässt und nicht wie ein Heimwerkerprojekt
Und das, was den Teilbesitzern tatsächlich wichtig ist: Die Kosten liegen oft im Bereich von einigen Hundert bis zu einigen Tausend pro Monat. Nicht „Hunderttausende pro Standort“. Nicht „sechs Monate Beschaffungszeit“. Nicht „wir brauchen eine Genehmigung für eine Budgetüberschreitung“. Sondern einfach: Replikation, Speicherung und Rechenleistung, wenn tatsächlich ein Failover erforderlich ist (plus das, was Sie in Bereitschaft halten möchten). Mit anderen Worten: Sie zahlen nicht mehr rund um die Uhr für eine Katastrophe, die nur gelegentlich eintritt.
Der versteckte Vorteil: Compliance und Prüfungsbereitschaft ohne großes Aufsehen
Ein Großteil der Ausgaben für Disaster Recovery ist in Wirklichkeit nur getarnte Ausgaben für Audits. Sie kaufen nicht nur Verfügbarkeit, sondern auch die Möglichkeit, Fragen wie die folgenden zu beantworten:
- „Wie lauten Ihre RPO/RTO?“
- „Wann hast du deinen letzten DR-Test gemacht?“
- „Zeig mir Beweise.“
- „Zeig mir, dass es reproduzierbar ist.“
- „Zeig mir, dass das dokumentiert ist.“
ASR ist auf wiederholbare Vorgehensweisen ausgelegt. Ausfallpläne lassen sich standardisieren, testen und dokumentieren. Die Automatisierung kann einheitlich gestaltet werden. Prozesse lassen sich validieren. Das ist der Unterschied zwischen „Wir haben einen Ordner“ und „Wir haben einen koordinierten Prozess, den wir ausführen und nachweisen können“.
Die meisten Unternehmen, die nicht zu den Fortune-100 gehören, scheitern bei der Notfallwiederherstellung nicht, weil es ihnen egal ist. Sie scheitern, weil die „alte Vorgehensweise“ ein luxuriöses Hobby ist. ASR macht daraus eine operative Fähigkeit.
Die „Executive Translation“: Was Sie tatsächlich erhalten
Falls Sie dies als Führungskraft lesen, hier ist der Nutzen in einfachen Worten:
- Sie ersetzen große Investitionsprojekte durch ein Betriebsmodell: Kein Aufbau eines „DR-Standorts 2.0“ mehr, um ihn dann die nächsten fünf Jahre lang wie eine zweite Produktionsumgebung zu warten, die niemand nutzt.
- Durch Automatisierung und Planbarkeit verringern Sie das Risiko von Ausfallzeiten: Festgelegte Failover-Pläne sorgen für weniger Chaos. Weniger Chaos bedeutet weniger Ausfallzeiten. Weniger Ausfallzeiten bedeuten weniger kostspielige Überraschungen.
- Sie standardisieren die Wiederherstellung anhand dokumentierter Vorgehensanleitungen: Die Wiederherstellung wird zu einem Prozess, den Sie testen, verbessern und wiederholen können – ganz ohne Heldentaten.
- Sie erhalten Funktionen auf Unternehmensniveau, ohne dass dafür eine Infrastruktur auf Unternehmensniveau erforderlich ist: Sie nutzen eine Infrastruktur, die darauf ausgelegt ist, Compliance-Anforderungen in großem Maßstab zu erfüllen, anstatt zu versuchen, dieses Maß an Ausfallsicherheit mit einem kleineren Team und einem geringeren Budget nachzubilden.
Was das nicht ist
ASR ist keine Zauberei. Es erfordert nach wie vor eine sorgfältige Konzeption. Sie müssen dennoch folgende Fragen beantworten:
- Welche Workloads fallen in den Geltungsbereich?
- Wie lauten die tatsächlichen RPO-/RTO-Ziele für die einzelnen Systeme?
- Welche Abhängigkeiten bestehen (AD, DNS, SQL, Anwendungsschichten, Integrationen von Drittanbietern)?
- Was bedeutet „Failover“ für den Benutzerzugriff und die Identitätsverwaltung?
- Wie überprüfen Sie die Wiederherstellung, und wie oft?
Der Unterschied besteht jedoch darin, dass diese Fragen nun zu Konfiguration und Orchestrierung führen und nicht zu einer zweiten Hypothek auf ein zweites Rechenzentrum.
Das Schlussplädoyer: Keine Finanzmittel mehr für Immobilien. Starten Sie die Finanzierung eines Plans.
Jahrelang war DR ein Architekturproblem, das man mit Infrastruktur, Hardware und viel Hoffnung löste. Azure Site Recovery macht daraus das, was es schon immer hätte sein sollen: einen Dienst, ein Playbook, vorhersehbare Betriebskosten und eine Funktion, die man tatsächlich testen kann, ohne dabei ins Schwitzen zu geraten.
Wenn Sie immer noch für Colocation zahlen, hauptsächlich um DR-/BC-Anforderungen zu erfüllen, sind Sie damit nicht allein. Aber Sie sitzen auch nicht in der Sackgasse. Die gute Nachricht ist: Ihr DR-Standort benötigt keinen eigenen Tresorraum mehr – weder physisch noch finanziell. Er braucht lediglich einen Plan und ein Replikationsziel, dessen Erfolg kein weiteres Bauprojekt erfordert.
