Hohe Verfügbarkeit und Ausfallsicherheit von Standorten

Gilt für: Exchange Server 2013

Sie können Ihre Exchange Server 2013-Postfachdatenbanken und die darin enthaltenen Daten schützen, indem Sie Ihre Postfachdatenbanken für hohe Verfügbarkeit und Ausfallsicherheit für Standorte konfigurieren. Exchange 2013 senkt die Kosten und Komplexität für die Bereitstellung einer hochverfügbaren und ausfallsicheren Messaginglösung auf ein Minimum und bietet gleichzeitig hohe Dienst- und Datenverfügbarkeit sowie Unterstützung für sehr große Postfächer.

Exchange 2010 baut auf den systemeigenen Replikationsfunktionen und der Architektur für hohe Verfügbarkeit auf, die von Exchange 2013 eingeführt werden, wodurch Kunden beliebiger Größe und aus allen Sparten die Möglichkeit erhalten, einen Dienst zur Aufrechterhaltung des Messagings im Unternehmen kostengünstig bereitzustellen. Eine Liste der Änderungen über Exchange 2010 und Exchange 2007 finden Sie unter Änderungen bei hoher Verfügbarkeit und Ausfallsicherheit im Vergleich zu früheren Versionen.

Wichtige Terminologie

Nachfolgend werden die wichtigsten Begriffe zum Verständnis von Hochverfügbarkeit und Ausfallsicherheit von Standorten erläutert:

• Active Manager: Eine interne Exchange-Komponente, die innerhalb des Microsoft Exchange-Replikationsdiensts ausgeführt wird und für die Fehlerüberwachung und Korrekturmaßnahmen durch Failover innerhalb einer Datenbankverfügbarkeitsgruppe (DAG) verantwortlich ist.

• AutoDatabaseMountDial: Eine Eigenschaftseinstellung eines Postfachservers, die bestimmt, ob eine passive Datenbankkopie automatisch als neue aktive Kopie eingebunden wird, basierend auf der Anzahl der Protokolldateien, die in der eingebundenen Kopie fehlen.

• Fortlaufende Replikation – Blockmodus: Wenn jedes Update im Blockmodus in den aktiven Protokollpuffer der aktiven Datenbankkopie geschrieben wird, wird es auch an einen Protokollpuffer für jede der passiven Postfachkopien im Blockmodus gesendet. Sobald der Protokollpuffer voll ist, führt jede Datenbankkopie eine Überprüfung durch und erstellt dann die nächste Protokolldatei in der Generierungssequenz.

• Fortlaufende Replikation – Dateimodus: Im Dateimodus werden geschlossene Transaktionsprotokolldateien aus der aktiven Datenbankkopie in eine oder mehrere passive Datenbankkopien gepusht.

• Datenbankverfügbarkeitsgruppe: Eine Gruppe von bis zu 16 Exchange 2013-Postfachservern, die eine Gruppe replizierter Datenbanken hosten.

• Datenbankmobilität: Die Möglichkeit einer Exchange 2013-Postfachdatenbank, auf anderen Exchange 2013-Postfachservern repliziert und auf diesen eingebunden zu werden.

• Rechenzentrum: In der Regel bezieht sich dies auf einen Active Directory-Standort. es kann sich jedoch auch auf einen physischen Standort beziehen. Im Rahmen dieser Dokumentation entspricht ein Datencenter einem Active Directory-Standort.

• Koordinationsmodus für die Rechenzentrumsaktivierung: Eine Eigenschaft der DAG-Einstellung, die bei Aktivierung erzwingt, dass der Microsoft Exchange-Replikationsdienst beim Start die Berechtigung zum Einbinden von Datenbanken erhält.

• Notfallwiederherstellung: Jeder Prozess, der zur manuellen Wiederherstellung nach einem Fehler verwendet wird. Dies kann ein Ausfall sein, der ein einzelnes Element betrifft, oder ein Ausfall, der sich auf einen gesamten physischen Standort auswirkt.

• Exchange-Drittanbieterreplikations-API: Eine von Exchange bereitgestellte API, die die Verwendung der synchronen Replikation eines Drittanbieters für eine DAG anstelle der kontinuierlichen Replikation ermöglicht.

• Hochverfügbarkeit: Eine Lösung, die Dienstverfügbarkeit, Datenverfügbarkeit und automatische Wiederherstellung nach Fehlern bietet, die sich auf den Dienst oder die Daten auswirken (z. B. netzwerk-, speicher- oder serverfehler).

• Inkrementelle Bereitstellung: Die Möglichkeit, Hochverfügbarkeit und Standortresilienz nach der Installation von Exchange 2013 bereitzustellen.

• Verzögerte Postfachdatenbankkopie: Eine passive Postfachdatenbankkopie, deren Protokollwiedergabeverzögerung größer als 0 (null) ist.

• Postfachdatenbankkopie: Eine Postfachdatenbank (EDB-Datei und Protokolle), die entweder aktiv oder passiv ist.

• Postfachresilienz: Der Name einer einheitlichen Lösung für Hochverfügbarkeit und Standortresilienz in Exchange 2013.

• Verwaltete Verfügbarkeit: Eine Reihe interner Prozesse, die aus Tests, Monitoren und Respondern bestehen, die Überwachung und Hochverfügbarkeit für alle Serverrollen und protokolle umfassen.

• *over (ausgesprochen "star over"): Kurzform für Switchover undFailover. Ein Switchover ist die manuelle Aktivierung einer oder mehrerer Datenbankkopien. Ein Failover ist die automatische Aktivierung einer oder mehrerer Datenbankkopien nach einem Ausfall.

• Safety Net: Früher als Transportspeicher bezeichnet, ist dies ein Feature des Transportdiensts, der eine Kopie aller Nachrichten für X Tage speichert. Die Standardeinstellung beträgt 2 Tage.

• Schattenredundanz: Ein Transportserverfeature, das Redundanz für Nachrichten während der gesamten Übertragung bereitstellt.

• Standortresilienz: Eine Konfiguration, die die Messaginginfrastruktur auf mehrere Active Directory-Standorte erweitert, um die Betriebskontinuität für das Messagingsystem im Falle eines Ausfalls zu gewährleisten, der sich auf einen der Standorte auswirkt.

Database Availability Groups (DAGs)

Eine DAG ist die Basiskomponente des Frameworks für Hochverfügbarkeit und Standortresilienz, das in Exchange 2013 integriert ist. Eine DAG besteht aus bis zu 16 Postfachservern, die eine Gruppe von Datenbanken hosten und eine automatische Wiederherstellung auf Datenbankebene nach Ausfällen bieten, die einzelne Datenbanken, Netzwerke oder Server betreffen. Jeder Server in einer DAG kann als Host für eine Kopie einer Postfachdatenbank eines beliebigen anderen Servers in der DAG fungieren. Wenn ein Server einer DAG hinzugefügt wird, wird dieser mit den anderen Servern in der DAG eingesetzt, um eine automatische Wiederherstellung nach Fehlern zu bieten, die Postfachdatenbanken betreffen, z. B. Datenträger- oder Serverfehler. Weitere Informationen zu Database Availability Groups finden Sie unter Database availability groups (DAGs).

Postfachdatenbankkopien

Die erstmals in Exchange 2010 eingeführten Funktionen zur Bereitstellung von Hochverfügbarkeit und Ausfallsicherheit für Standorte werden in Exchange 2013 dazu verwendet, Datenbankkopien zu erstellen und zu verwalten. Exchange 2013 nutzt außerdem das Konzept der Datenbankmobilität, die von Exchange verwaltete Failoverfunktion auf Datenbankebene.

Im Rahmen der Datenbankmobilität werden Datenbanken von Servern getrennt und Unterstützung für bis zu 16 Kopien einer einzelnen Datenbank hinzugefügt. Zudem wird eine systemeigene Umgebung für das Erstellen von Kopien einer Datenbank bereitgestellt.

Das Festlegen einer Datenbankkopie als aktive Postfachdatenbank wird als Switchover bezeichnet. Wenn ein Fehler auftritt, der eine Datenbank oder den Zugriff auf eine Datenbank beeinträchtigt, und eine neue Datenbank als aktive Kopie festgelegt wird, wird dieser Vorgang als Failover bezeichnet. Dieser Vorgang bezieht sich auch auf einen Serverausfall, bei dem ein oder mehrere Server die Datenbank online schalten, die sich zuvor auf dem ausgefallenen Server befunden hat. Wenn entweder ein Switchover oder Failover erfolgt, wird dieses Ereignis von den Exchange 2013-Servern sofort erkannt, und der Client- und Messagingdatenverkehr wird an die neue aktive Datenbank umgeleitet.

Wenn beispielsweise eine aktive Datenbank in einer DAG aufgrund eines zugrunde liegenden Speicherfehlers fehlschlägt, wird Active Manager automatisch wiederhergestellt, indem ein Failover zu einer Datenbankkopie auf einem anderen Postfachserver in der DAG ausgeführt wird. In Exchange 2013 fügt die verwaltete Verfügbarkeit neue Verhaltensweisen hinzu, die nach dem Verlust des Protokollzugriffs auf eine Datenbank wiederhergestellt werden können. Dazu gehören das Recycling von Anwendungs-Workerpools, das Neustarten von Diensten und Servern und das Initiieren von Datenbankfailovern.

Weitere Informationen zu Postfachdatenbankkopien finden Sie unter Postfachdatenbankkopien.

Active Manager

Exchange 2013 nutzt die in Exchange 2010 eingeführte Active Manager-Komponente zum Verwalten der Integrität von Datenbanken und Datenbankkopien, für Status, fortlaufende Replikation und weitere Aspekte in Bezug auf die Hochverfügbarkeit von Postfachservern. Weitere Informationen zu Active Manager finden Sie in Active Manager.

Ausfallsicherheit von Standorten

Obwohl in Exchange 2013 weiterhin DAGs und das Windows-Failoverclustering für die Postfachserverrolle für die Bereitstellung von Hochverfügbarkeit und Ausfallsicherheit für Standorte eingesetzt wird, ist die Ausfallsicherheit für Standorte nicht dieselbe wie in Exchange 2013. Die Ausfallsicherheit für Standorte ist in Exchange 2013 deutlich besser, da sie vereinfacht wurde. Die zugrunde liegenden Architekturänderungen in Exchange 2013 haben erhebliche Auswirkungen auf die Wiederherstellungsaspekte einer Konfiguration zur Ausfallsicherheit von Standorten.

In Exchange 2010 war die Wiederherstellung von Postfach- (DAG) und Clientzugriff (Clientzugriffsserver-Array) eng verknüpft. Bei einem Ausfall von sämtlichen Clientzugriffsservern, der VIP für das Array oder einem Ausfall großer Teile Ihrer DAG war es erforderlich, ein Datencenterswitchover durchzuführen. Dies ist ein gut dokumentierter und im Allgemeinen leicht verständlicher Vorgang, wenngleich die Ausführung Zeit kostet und der Vorgang von einem Benutzer gestartet werden muss.

Wenn Sie in Exchange 2013 ihr Clientzugriffsserverarray aus irgendeinem Grund verlieren (z. B. wenn der Lastenausgleich fehlschlägt), müssen Sie keinen Wechsel des Rechenzentrums durchführen. Bei der richtigen Konfiguration erfolgt das Failover auf Clientebene, und Clients werden automatisch an ein zweites Rechenzentrum umgeleitet, in dem Clientzugriffsserver ausgeführt werden, und diejenigen, die Clientzugriffsserver verwenden, stellen die Kommunikation zurück an den Postfachserver des Benutzers, der vom Ausfall nicht betroffen ist (da Sie keine Umstellung durchführen). Anstatt an der Wiederherstellung des Diensts zu arbeiten, wird der Dienst von selbst wiederhergestellt, und Sie können sich auf die Behebung des Kernproblems konzentrieren (z. B. das Ersetzen des fehlerhaften Lastenausgleichs).

Darüber hinaus wird es durch Änderungen wie z. B. die Vereinfachung von Namespaces, die Konsolidierung von Serverrollen, die Entkopplung von Serverrollenanforderungen der Active Directory-Standorte, die Trennung von Clientzugriffsserver-Array- und DAG-Wiederherstellung sowie Änderungen am Lastenausgleich in Exchange 2013 ab sofort möglich, die Clientzugriffsserver- und DAG-Wiederherstellung zu trennen und automatisch über Standorte hinweg auszuführen. Auf diese Weise werden Szenarien für ein Datencenterfailover unterstützt, wenn Sie über drei Standorte verfügen.

In Exchange 2010 konnten Sie eine DAG über zwei Datencenter hinweg bereitstellen, den Zeugenserver in einem dritten Datencenter hosten und ein Failover für die Postfachserverrolle für beide Datencenter aktivieren. Es gab jedoch kein Failover für die Lösung selbst, da der Namespace für die Nicht-Postfachserverrollen weiterhin manuell geändert werden musste.

In Exchange 2013 muss der Namespace nicht mit der DAG verschoben werden. Exchange nutzt die integrierte Fehlertoleranz des Namespace über mehrere IP-Adressen, Lastenausgleich (und, sofern erforderlich, die Fähigkeit zur Inbetriebnahme und Außerbetriebnahme von Servern). Moderne HTTP-Clients arbeiten automatisch mit dieser Redundanz. Der HTTP-Stack kann mehrere IP-Adressen für einen vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) akzeptieren, und wenn die erste IP-Adresse dauerhaft ausfällt (d. h. eine Verbindung nicht möglich ist), wird die nächste IP-Adresse in der Liste verwendet. Bei einem temporären Fehler (Verbindungsverlust nach dem Einrichten einer Sitzung, beispielsweise aufgrund eines zeitweiligen Fehlers im Dienst, bei dem ein Gerät Pakete verliert und außer Betrieb genommen werden muss), muss der Benutzer möglicherweise den Browser aktualisieren.

Dies bedeutet, dass der Namespace nicht länger eine einzelne Fehlerquelle ist, wie dies in Exchange 2010 der Fall war. In Exchange 2010 ist die womöglich größte einzelne Fehlerquelle im Messagingsystem der Benutzern zugewiesene FQDN, da er die Zieladresse angibt. Im Exchange 2010-Paradigma ist eine Änderung des FQDN-Ziels nicht einfach, da Sie die DNS-Einstellungen ändern und die DNS-Wartezeit berücksichtigen müssen, die in einigen Teilen der Erde sehr hoch liegt. Außerdem werden in Browsern Namencaches verwendet, die Daten typischerweise für 30 Minuten oder mehr zwischenspeichern, und dieser Tatsache muss Rechnung getragen werden.

Eine der Änderungen in Exchange 2013 besteht darin, Clients mehr als eine Anlaufstelle zu ermöglichen. Angenommen, der Client hat die Möglichkeit, mehr als einen Ort zu verwenden (fast alle Clientzugriffsprotokolle in Exchange 2013 sind HTTP-basiert (Beispiele sind Outlook, Outlook Anywhere, EAS, EWS, OWA und EAC), und alle unterstützten HTTP-Clients haben die Möglichkeit, mehrere IP-Adressen zu verwenden), wodurch ein Failover auf der Clientseite ermöglicht wird. Sie können DNS so konfigurieren, dass einem Client während der Namensauflösung mehrere IP-Adressen übergeben werden. Der Client fragt "mail.contoso.com" an und erhält beispielsweise zwei oder vier IP-Adressen. Viele der an den Client zurückgegebenen IP-Adressen können jedoch zuverlässig verwenden werden. Dies verbessert den Clientbetrieb, da der Client bei einem Ausfall einer der IP-Adressen weitere IP-Adressen zur Verbindungsherstellung zur Verfügung stehen. Wenn beim Versuch einer Verbindungsherstellung durch den Client ein Fehler auftritt, wartet der Client für etwa 20 Sekunden und versucht es dann mit der nächsten Adresse in der Liste. Wenn also die VIP für das Clientzugriffsserver-Array ausfällt, wird innerhalb von etwa 21 Sekunden eine automatische Clientwiederherstellung durchgeführt.

Hierdurch bieten sich folgende Vorteile:

• Wenn Sie in Exchange 2010 den Lastenausgleich in Ihrem primären Rechenzentrum verlieren und an diesem Standort keinen weiteren Haben, mussten Sie einen Wechsel des Rechenzentrums durchführen. Wenn Sie in Exchange 2013 den Lastenausgleich an Ihrem primären Standort verlieren, deaktivieren Sie ihn einfach (oder deaktivieren Sie die VIP), und reparieren oder ersetzen Sie ihn. Clients, die die VIP noch nicht im sekundären Datencenter verwenden, führen automatisch ein Failover auf die sekundäre VIP ohne Änderung des Namespaces und ohne Änderung des DNS aus. Dies bedeutet nicht nur, dass Sie keine Umstellung mehr durchführen müssen, sondern auch, dass die gesamte Zeit, die normalerweise mit einer Rechenzentrums-Switchoverwiederherstellung verbunden ist, nicht aufgewendet wird. In Exchange 2010 mussten Sie die DNS-Latenz verarbeiten (daher die Empfehlung, die Gültigkeitsdauer auf 5 Minuten festzulegen, und die Einführung der Failback-URL). In Exchange 2013 ist dies nicht erforderlich, da Sie ein schnelles Failover (20 Sekunden) des Namespace zwischen VIPs (Rechenzentren) erhalten.

• Da Sie ein Failover für den Namespace zwischen Rechenzentren ausführen können, ist alles, was für ein Rechenzentrumsfailover erforderlich ist, ein Mechanismus für das Failover der Postfachserverrolle über mehrere Rechenzentren hinweg. Um ein automatisches Failover für die DAG zu erhalten, erstellen Sie einfach eine Lösung, bei der die DAG gleichmäßig auf zwei Rechenzentren aufgeteilt wird, und platzieren den Zeugenserver dann an einem dritten Speicherort, sodass er von DAG-Mitgliedern in einem der beiden Rechenzentren unabhängig vom Zustand des Netzwerks zwischen den Rechenzentren, die die DAG-Mitglieder enthalten, vermittelt werden kann. Wenn Sie nur über zwei Rechenzentren verfügen und ein dritter physischer Standort nicht verfügbar ist, können Sie den Zeugenserver auf einem virtuellen Microsoft Azure-Computer platzieren. Weitere Informationen finden Sie unter Verwenden einer Microsoft Azure-VM als DAG-Zeugenserver .

• In diesem Szenario beschränken sich die Aufgaben des Administrators darauf, das vorliegende Problem zu lösen, eine Dienstwiederherstellung ist nicht erforderlich. Sie korrigieren lediglich die fehlerhafte Komponente, während der Dienst weiter ausgeführt und die Datenintegrität aufrechterhalten wird. Der Termindruck und der Stress bei der Reparatur eines beschädigten Geräts sind nicht zu vergleichen mit dem Termindruck und dem Stress, der mit der Wiederherstellung eines Diensts einhergeht. Das bedeutet Vorteile für den Endbenutzer und weniger Stress für den Administrator.

Sie können ein Failover durchführen, ohne Switchbacks auszuführen (gelegentlich fälschlich als Failbacks bezeichnet). Wenn Sie den Clientzugriffsserver im primären Datencenter verlieren und dies zu einer 20 Sekunden dauernden Dienstunterbrechung für die Clients führt, müssen Sie sich möglicherweise noch nicht einmal Gedanken über ein Failback machen. Zu diesem Zeitpunkt besteht Ihre Hauptsorge darin, das Kernproblem zu lösen (z. B. das ausgefallene Lastenausgleichsmodul zu ersetzen). Nachdem die Komponente wieder online und betriebsbereit ist, beginnen einige Clients damit, die Komponente erneut zu nutzen, und andere Clients nehmen Dienste über das zweite Datencenter in Anspruch.

Exchange 2013 bietet außerdem eine Funktionalität, die Administratoren die Handhabung von zeitweise auftretenden Fehlern ermöglicht. Ein zeitweiliger Fehler ist beispielsweise eine Situation, in der die anfängliche TCP-Verbindung hergestellt werden kann, dann jedoch ein Stillstand eintritt. Ein zeitweise auftretender Fehler erfordert einigen zusätzlichen Verwaltungsaufwand, da er das Ergebnis der Inbetriebnahme eines Ersatzgeräts sein kann. Während der Reparatur wird das Gerät möglicherweise eingeschaltet und akzeptiert einige Anforderungen, kann jedoch nicht wirklich für die Verarbeitung von Dienstanforderungen durch Clients verwendet werden, bis die erforderlichen Konfigurationsschritte ausgeführt wurden. In diesem Szenario kann der Administrator einen Namespaceswitchover durchführen, indem einfach die VIP für das im Austausch befindliche Gerät aus der DNS-Konfiguration entfernt wird. Dies führt dazu, dass Clients während der Wartungsphase nicht versuchen, eine Verbindung mit dem Gerät herzustellen. Nachdem der Austausch abgeschlossen wurde, kann der Administrator die VIP wieder in die DNS-Konfiguration einfügen, und Clients können das Gerät wieder verwenden.

Weitere Informationen zum Planen und Bereitstellen von Ausfallsicherheit für Standorte finden Sie unter Planen einer hohen Verfügbarkeit und Ausfallsicherheit von Standorten und Bereitstellen der hohen Verfügbarkeit und Ausfallsicherheit von Standorten.

API für die Drittanbieterreplikation

Exchange 2013 enthält eine API für die Drittanbieterreplikation, mit der Unternehmen anstelle der integrierten Funktion für die fortlaufende Replikation Lösungen anderer Anbieter für die synchrone Replikation verwenden können. Microsoft unterstützt Drittanbieterlösungen, die diese API verwenden, sofern die Lösung die benötigte Funktionalität bereitstellt, um sämtliche systemeigene Funktionalität für die fortlaufende Replikation zu ersetzen, die als Ergebnis der Verwendung der API deaktiviert ist. Lösungen werden nur unterstützt, wenn die API in einer DAG zum Verwalten und Aktivieren von Postfachdatenbankkopien verwendet wird. Die Verwendung der API darüber hinaus wird nicht unterstützt. Außerdem muss die Lösung die geltenden Supportanforderungen für Windows-Hardware erfüllen. (Für Support ist keine Testvalidierung erforderlich.)

Beachten Sie beim Bereitstellen einer Lösung, die die integrierte Replikations-API von Drittanbietern verwendet, dass der Lösungsanbieter für die primäre Unterstützung der Lösung verantwortlich ist. Microsoft unterstützt Exchange-Daten sowohl für replizierte als auch für nicht replizierte Lösungen. Lösungen, die die Datenreplikation verwenden, müssen der Microsoft-Supportrichtlinie für die Datenreplikation entsprechen. Darüber hinaus müssen Lösungen, die das Windows-Failoverclusterressourcenmodell verwenden, die Anforderungen an die Unterstützung von Windows-Clustern erfüllen, wie im Microsoft Knowledge Base-Artikel 943984, Die Microsoft-Support-Richtlinie für Windows Server 2008- oder Windows Server 2008 R2-Failovercluster oder die Microsoft-Support-Richtlinie für Windows Server 2012 Failovercluster.

Die Supportrichtlinie für Sicherung und Wiederherstellung von Microsoft für Bereitstellungen mit Replikations-API-basierten Drittanbieterlösungen entspricht der Richtlinie für systemeigene Bereitstellungen der fortlaufenden Replikation.

Wenn Sie ein Partner sind, der nach Informationen zur Drittanbieter-API sucht, wenden Sie sich an Ihren Ansprechpartner bei Microsoft.

Dokumentation zu Hochverfügbarkeit und Ausfallsicherheit für Standorte

In der folgenden Tabelle sind Links zu Themen aufgeführt, in denen Sie weitere Informationen zu DAGs, Postfachdatenbankkopien und Sicherung und Wiederherstellung für Exchange 2013 sowie zur Verwaltung dieser Funktionen finden.

Thema	Beschreibung
Database Availability Groups (DAGs)	Hier erhalten Sie Informationen zu DAGs, Active Manager, DAC-Modus (Datacenter Activation Coordination) und Postfachdatenbankkopien.
Planen einer hohen Verfügbarkeit und Ausfallsicherheit von Standorten	Hier erhalten Sie Informationen zu den allgemeinen Anforderungen und den Anforderungen für Hardware, Netzwerk, Zeugenserver und zu den bewährten Methoden für DAGs.
Bereitstellen der hohen Verfügbarkeit und Ausfallsicherheit von Standorten	Hier können Sie ein Beispielszenario für die Bereitstellung und Konfiguration von DAGs untersuchen.
Verwalten von hoher Verfügbarkeit und Ausfallsicherheit für Standorte	Hier erhalten Sie Informationen zu Verwaltungsaufgaben in Bezug auf DAGs, zu Switchover- und Failovervorgängen sowie zum Wartungsmodus.
Überwachen von Datenbankverfügbarkeitsgruppen	Hier erhalten Sie Informationen zu den integrierten Cmdlets und Skripts für die Überwachung von DAGs und Datenbankkopien.
Sicherung, Wiederherstellung und Notfallwiederherstellung	Hier erhalten Sie Informationen zur Sicherung und Wiederherstellung von Exchange-Datenbanken und Wiederherstellungsdatenbanken sowie zur Serverwiederherstellung.