TL;DR – Zusammenfassung
"E-Mail-Kontinuität" bedeutet für jeden etwas anderes. Früher war dies kein Thema, das den meisten Unternehmen schlaflose Nächte bereitete. Hätte man vor Jahren einen Exchange- oder Microsoft 365-Administrator gefragt, hätte dieser geantwortet, dass E-Mail-Störungen sich von selbst beheben – und damit hätte er nicht Unrecht gehabt. Die Infrastruktur von Microsoft ist wirklich gut, SMTP stellt E-Mails in die Warteschlange, und die meisten Ausfälle sind nur von kurzer Dauer.
Das ist nicht mehr das ganze Bild. Selbst wenn die Ausfälle nicht lange dauern, lautet die Frage nicht mehr nur:
“Wird die E-Mail irgendwann eintreffen?”
Stattdessen lautet es nun:
“Kann die Organisation ihren Betrieb aufrechterhalten, wenn es keine E-Mails gibt?”
Jeder Ausfall von Microsoft 365 führt zu Produktivitätsverlusten, Verzögerungen in der Kommunikation und verpassten Geschäftsmöglichkeiten, wobei diese Auswirkungen in großen Organisationen besonders deutlich zu spüren sind.
Zudem gibt es Compliance-Rahmenwerke wie NIS2, DORAund SOC 2 unterstützen diesen Wandel hin zur Geschäftskontinuität. Solche Rahmenwerke sind Teil eines umfassenderen regulatorischen Trends, der Unternehmen dazu veranlasst, über einfache Datensicherung und Wiederherstellung hinauszugehen und stattdessen die Betriebsfähigkeit bei Ausfällen, Cybervorfällen und Dienstunterbrechungen aufrechtzuerhalten.
Möchten Sie direkt erfahren, wie Google Workspace im parallelen Betrieb mit Microsoft 365 die Geschäftskontinuität gewährleisten kann?
Entdeckene Google Workspace for Business Continuity von Connecting Software, der Technologieebene, die den Betrieb der Google Business Continuity Plus-SKU ermöglicht.
Backups schützen Daten. E-Mail-Kontinuität sorgt für Betriebssicherheit.
Wenn man an eine Microsoft 365-Backup-Lösung denkt, geht es normalerweise um die Wiederherstellung von Daten danach ein Vorfall.
Lösungen zur E-Mail-Kontinuität hingegen sind darauf ausgelegt, die Kommunikation, Kalender und die Zusammenarbeit aufrechtzuerhalten während der Vorfall.
Diese Unterscheidung ist von Bedeutung bei:
- Ausfälle bei Microsoft 365,
- Aussperrungen von Mietern,
- Ransomware-Vorfälle,
- Identitätsstörungen,
- oder Cyberangriffe.
Die eigentliche Frage lautet:
Wie können Nutzer weiterarbeiten, wenn die primäre Umgebung nicht verfügbar ist?
An dieser Stelle kommen auch zwei Kennzahlen zum Tragen, auf die jede Diskussion über BCP/DR letztendlich hinausläuft: RTO und RPO.
In einer klassischen Diskussion zum Thema Datensicherung wird die RTO in der Regel als die Zeit gemessen, die zur Wiederherstellung des betroffenen Systems oder der betroffenen Daten benötigt wird, während die RPO das Alter des Wiederherstellungspunkts widerspiegelt (mit anderen Worten: wie viele aktuelle Daten möglicherweise fehlen).
In einer Diskussion zum Thema E-Mail-Kontinuität werden auf der Ebene der Geschäftsfunktionen häufig dieselben Kennzahlen herangezogen: Bei der RTO geht es darum, wie lange das Unternehmen eine Unterbrechung tolerieren kann, bevor die Nutzer wieder kommunizieren können, und bei der RPO darum, wie aktuell die Standby-Kommunikationsumgebung sein muss.
Diese Unterscheidung ist für NIS2, DORA, SOC 2 und ähnliche Diskussionen zu Resilienz und Compliance von Bedeutung, da es darum geht, ob die Geschäftsfunktion während der Störung weiterlaufen kann.
Vergleich der Ansätze zur E-Mail-Kontinuität bei Microsoft 365
Sobald sich die Anforderung ändert zu “die Kommunikation zwischen den Menschen während der Störung aufrechtzuerhalten”,” Die architektonischen Fragen im IT-Bereich werden dadurch viel interessanter.
Reicht ein einfacher Notfall-Mailbox-Dienst aus? Müssen wir unterschiedliche Regionen berücksichtigen? Sollten wir unsere eigene Infrastruktur vor Ort nutzen?
Es gibt verschiedene Ansätze und Abwägungen, die berücksichtigt werden müssen, um das Maß an Kontinuität zu erreichen, das das Unternehmen tatsächlich benötigt. In der folgenden Tabelle werden die wichtigsten Ansätze verglichen, auf die wir im Folgenden näher eingehen werden.
| Vorgehensweise | Kernaussage | Beispiele für Tools und Anbieter | Stärken | Typische Bedenken |
|---|---|---|---|---|
| Cloud-basierte Kontinuitätsdienste | Von einem Drittanbieter gehostete Plattform zur Aufrechterhaltung des Betriebs im Notfall | Mimecast, Retarus, Trend Micro | Schnelle Bereitstellung Geringere Betriebskosten |
Eingeschränkte Kontinuität über das Notfall-Webmail hinaus |
| Zweiter Microsoft 365-Mandant | Separate Microsoft 365-Umgebung, die für einen Ausfall vorbereitet ist | Microsoft 365 | Vertrautes Microsoft-Ökosystem Cloud-native Architektur |
Abhängigkeit vom Ökosystem eines einzigen Anbieters, Konzentrationsrisiko |
| Exchange-Server vor Ort | Unabhängige Exchange-Umgebung, synchronisiert mit Microsoft 365 | Microsoft, CB Exchange Server Sync | Operative Unabhängigkeit und Kontrolle Vertrautes Microsoft-Ökosystem für Endnutzer |
Zusätzliche Infrastruktur und Instandhaltung |
| Google Workspace als Hot-Standby | Unabhängige Google Workspace-Umgebung, synchronisiert mit Microsoft 365 | Google Workspace – Geschäftskontinuität, CB Exchange Server Sync für Google Workspace | Cloud-übergreifende Unabhängigkeit Kann auf SharePoint/Google Drive erweitert werden |
Unterschiedliche Benutzererfahrung, Identität und Zuordnung |
Welches Modell das richtige ist, hängt vom operativen Risikoprofil des Unternehmens, seinen Compliance-Verpflichtungen und seiner Toleranz gegenüber Ausfallzeiten ab. Sehen wir uns die einzelnen Optionen nun genauer an.
Option 1: Cloud-basierte Dienste zur Aufrechterhaltung des E-Mail-Betriebs
Dies ist einer der traditionellen Ansätze. Anbieter wie Mimecast, Retarus und Trend Micro stellen cloudbasierte Kontinuitätsplattformen bereit, die den Notfallzugriff auf Postfächer, E-Mail-Weiterleitung und vorübergehende Kommunikationsdienste ermöglichen.
Die Vorteile sind eine schnelle Bereitstellung und geringerer Betriebsaufwand.
Unternehmensteams fragen sich jedoch häufig, inwieweit diese Plattformen über den vorübergehenden Zugriff auf Webmail hinaus tatsächlich für Betriebskontinuität sorgen. Können Nutzer nach dem Vorfall weiterhin Kalender abstimmen, mit gemeinsam genutzten Postfächern arbeiten und reibungslos zu Microsoft 365 zurückkehren?
Option 2: Sekundärer Microsoft 365-Mandant
Einige Unternehmen nutzen einen sekundären Microsoft 365-Mandanten für das Failover, manchmal in einer anderen Region, um das Risiko regionaler Dienstunterbrechungen zu verringern.
Dies kann die Ausfallsicherheit verbessern, insbesondere wenn der sekundäre Tenant mit separater Verwaltung, separatem Routing, separaten Zugriffsrichtlinien und separaten Wiederherstellungsverfahren konzipiert ist. Die regionenübergreifende Auslegung beseitigt jedoch nicht die allgemeine Abhängigkeit vom Microsoft-Cloud-Ökosystem.
Es gibt noch einen weiteren, weniger offensichtlichen Aspekt: Wenn sich der sekundäre Mandant über denselben Identitätsanbieter wie die Produktionsumgebung authentifiziert (in der Regel derselbe Entra ID-Mandant), kann ein identitätsbezogener Vorfall oder eine Störung beide Umgebungen gleichzeitig beeinträchtigen.
Option 3: Exchange-Server vor Ort, synchronisiert mit Microsoft 365
Ein dritter Ansatz besteht darin, eine eigenständige Exchange-Serverumgebung zu betreiben, die mit Microsoft 365 synchronisiert ist.
Ein Beispiel hierfür ist der Einsatz eines Exchange-Servers vor Ort, der mit Microsoft 365 synchronisiert ist.
In diesem Modell:
- Microsoft 365 bleibt die wichtigste Betriebsplattform,
- Der Exchange-Server ist die eigenständige Ausfallsicherheitsumgebung,
- CB Exchange Server Sync für BCP durch Connecting Software gewährleistet die Synchronisation zwischen beiden.
Die Synchronisation kann Folgendes umfassen:
- Briefkästen,
- Kalender,
- Kontakte,
- öffentliche Ordner,
- Verteilungsgruppen,
- und die GAL-Synchronisierung.
Da diese Umgebung lokal mit einem eigenen Active Directory betrieben wird, muss sie keine Identitätsebene mit dem Microsoft 365-Mandanten teilen. Das ist ein wesentlicher Unterschied zu Option 2: Ein identitätsbasierter Angriff auf den Cloud-Mandanten erstreckt sich nicht automatisch auf die lokale Exchange-Umgebung, was für die oben aufgeführten Szenarien "Identitätsfehler" und "Mandantensperrung" von direkter Bedeutung ist.
Der Betrieb vor Ort bedeutet auch, dass dies die beste Lösung ist, wenn Ihr Unternehmen eine solche Lösung in einem Air-Gapped-Netzwerk benötigt. Die Vor-Ort-Version kann in Verbindung mit Datendioden eingesetzt werden, um dieses Szenario zu ermöglichen.
Warum manche Unternehmen diese Architektur bevorzugen
Für Organisationen mit höheren Anforderungen an die operative Widerstandsfähigkeit bietet dieser Ansatz folgende Vorteile:
- betriebliche Unabhängigkeit von Microsoft 365,
- das bekannte Outlook und die Kontinuität des Kalenders,
- mehr Kontrolle über die Infrastruktur und die Ausfallsicherung,
- Unterstützung für regulierte oder isolierte Umgebungen,
- Unabhängigkeit der Identität vom Produktionsmandanten,
- und ein geringeres Risiko durch hohe Wolkenkonzentrationen.
Unternehmen, die ebenfalls auf SharePoint und die Zusammenarbeit an Dokumenten angewiesen sind, können zusätzlich Strategien zur Dokumentensynchronisierung mithilfe von „Secure Sync for SharePoint by Connecting Software“ implementieren, um eine sichere SharePoint-Synchronisierung über unabhängige oder isolierte Umgebungen hinweg zu gewährleisten.
Option 4: Google Workspace als Hot-Standby
Ein vierter Ansatz folgt derselben Logik wie Option 3, tauscht jedoch die Standby-Plattform aus: Anstelle des Exchange-Servers vor Ort dient Google Workspace als unabhängige Umgebung, die über . kontinuierlich mit Microsoft 365 synchronisiert wird. .
Damit steht Unternehmen eine cloudübergreifende Failover-Option zur Verfügung, die keinerlei Abhängigkeit vom Microsoft-Ökosystem mit sich bringt. Dies kann im Hinblick auf Konzentrationsrisiken von Bedeutung sein und ist zudem bei Unternehmen beliebt, die bereits Teile ihres Betriebs über Google Workspace abwickeln. Selbst bei Unternehmen, bei denen dies nicht der Fall ist, sind die Nutzer oft aus privater Erfahrung mit Google Workspace vertraut, was bei einem Failover von Vorteil ist.
In einem Folgeartikel werden wir diese Architektur, ihr Identitätsmodell und die damit verbundenen Kompromisse näher beleuchten.
Erfahren Sie, wie Sie mit Google Workspace für die Geschäftskontinuität einen Hot-Standby einrichten können – von Connecting Software
Failover: Aufhebung des Wiederherstellungsfensters
Beim herkömmlichen Ansatz mit Sicherung und Wiederherstellung musste im Falle einer Störung immer noch jemand eine Wiederherstellung durchführen, bevor wieder gearbeitet werden konnte.
Das bringt zwei Probleme mit sich: den erforderlichen manuellen Eingriff und die Dauer der Wiederherstellung, die proportional zur Menge der wiederherzustellenden Daten ist. Bei großen Mandanten sind RTOs im mehrtägigen Bereich keine Seltenheit.
Cloud-basierte Dienste zur Aufrechterhaltung des E-Mail-Betriebs bieten zwar eine Übergangslösung für dieses Problem, verfügen jedoch nur über begrenzte Funktionen.
Eine synchronisierte Standby-Umgebung macht diesen Schritt überflüssig. Da Sie über eine kontinuierlich aktualisierte Kopie der Postfächer, Kalender und gegebenenfalls auch Dokumente verfügen, können die Benutzer einfach auf diese Umgebing verwiesen werden und ihre Arbeit fortsetzen. Es handelt sich um ein Failover ohne Wiederherstellungsfenster. Da die Daten vor Ort und aktuell sind, entfällt das Wiederherstellungsfenster bei der Berechnung der Wiederherstellungszeit (RTO).
Sie müssen diese Kosten gegen die Kosten abwägen, die entstehen, wenn Ihren Benutzern E-Mails, Kalender und andere Postfachinhalte nicht zur Verfügung stehen – und zwar in Form von Produktivitätsverlusten, nicht abgeschlossenen Geschäften und gegebenenfalls Compliance-Kosten.
Failback: Manuelle Abgleichvorgänge vermeiden
Das Failover ist nur die halbe Miete. Irgendwann ist die Primärumgebung wieder verfügbar, und die Benutzer müssen zurückwechseln. Dies ist die Failback-Phase, in der die eigentliche Frage lautet: Was geschieht mit den in der Standby-Umgebung gesendeten und empfangenen E-Mails, den Kalenderänderungen und den Dokumentbearbeitungen, ohne dass Daten verloren gehen oder Duplikate entstehen?.
Müssen neue E-Mails, Kalenderänderungen und bearbeitete Dokumente manuell wieder in die Produktionsumgebung übernommen werden? Das ist niemandes Lieblingsaufgabe, denn genau diese Art von manuellen Schritten führt zu Fehlern, Versionsverwirrung und Verzögerungen.
Bei der bidirektionalen Synchronisierung erfolgt dieser Abgleich automatisch: Änderungen, die während des Ausfalls vorgenommen wurden, werden nach Wiederherstellung der primären Umgebung ohne Eingreifen der IT-Abteilung an Microsoft 365 zurückgespielt. Die einzigen gefährdeten Daten sind diejenigen, die innerhalb des letzten Synchronisierungsintervalls – also der Zeitspanne zwischen zwei Synchronisierungsdurchläufen – geändert wurden. Beträgt das Intervall fünf Minuten, entspricht das praktische RPO in etwa den Änderungen der letzten fünf Minuten und nicht der gesamten Dauer des Ausfalls. Sie können den Failback entsprechend Ihrem Synchronisierungsintervall zeitlich abstimmen, um das RPO auf null zu reduzieren.
Es ist anzumerken, dass das Abfrageintervall mit einem Kompromiss verbunden ist: Eine Verkürzung senkt zwar den RPO, verlängert jedoch den potenziellen Datenverlustzeitraum; eine Verlängerung reduziert zwar den Overhead, vergrößert aber das potenzielle Datenverlustfenster.
Es gibt keine einheitliche “richtige” E-Mail-Architektur.
Die richtige Lösung hängt ab von:
- betriebliche Abhängigkeit von Microsoft 365,
- akzeptable Ausfallzeit,
- gesetzliche Vorschriften,
- interne IT-Kapazitäten,
- sowie Ziele im Bereich der operativen Widerstandsfähigkeit.
Unternehmen mit moderaten Anforderungen können mit cloudbasierten Kontinuitätsdiensten voll und ganz zufrieden sein.
Organisationen, die im Rahmen von NIS2 oder DORA tätig sind oder strenge Anforderungen an die Ausfallsicherheit erfüllen müssen, benötigen möglicherweise eine größere operative Unabhängigkeit und bessere Ausfallsicherungsfunktionen.
Abschließende Überlegungen
Microsoft 365 bietet eine hervorragende Verfügbarkeit.
Doch Verfügbarkeit allein garantiert noch keine Betriebsresilienz.
Unternehmen erkennen zunehmend, dass die Aufrechterhaltung des E-Mail-Betriebs, der Zugriff auf Kalender und die Aufrechterhaltung der Zusammenarbeit für die Aufrechterhaltung des Betriebs während Störungen unerlässlich sind.
Denn bei einem echten Ausfall lautet die wichtigste Frage nicht:
“Können wir das später nachholen?”
Es lautet:
"Können wir den Betrieb fortsetzen?"
Erfahren Sie, wie Sie mit Google Workspace für die Geschäftskontinuität einen Hot-Standby einrichten können – von Connecting Software
Mehr zum Thema Geschäftskontinuität und Notfallwiederherstellung
Über den Autor
Durch Ana Neto, Fachberaterin bei Connecting Software.
"Ich bin seit 1997 Software-Ingenieur, und seit kurzem schreibe ich gerne und halte öffentliche Vorträge. Haben Sie Fragen oder Kommentare zu diesem Artikel? Ich würde mich über Ihr Feedback freuen. Hinterlassen Sie unten einen Kommentar!"
