Freigeben über

Planen der fortlaufenden lokalen Replikation

  • Artikel

 

Gilt für: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Letztes Änderungsdatum des Themas: 2008-01-04

Die Planung der fortlaufenden lokalen Replikation (Local Continuous Replication, LCR) umfasst den Entwurf einer Speichergruppe und Datenbanktopologie sowie die Sicherstellung einer angemessenen Unterstützung der Speicherlösung und Überwachung der LCR.

Speicheranforderungen und -empfehlungen für LCR

Für die fortlaufende lokale Replikation gelten bestimmte Speicherungsanforderungen und -empfehlungen. Wenn Sie die Speicherlösung für LCR entwerfen, sehen Sie eine zusätzliche E/A-Verwendung (Eingabe/Ausgabe) für LCR vor, weil die LCR-Umgebung die Protokollaktualisierungen durch die aktive Kopie und ähnliche Protokolllesevorgänge für die passive Kopie beinhaltet. Es wird empfohlen, den Speicher so zu planen, dass die passive Kopie über ähnliche Kapazität und Leistungsfunktionen wie die aktive Kopie verfügt. Bei Verwenden der fortlaufenden lokalen Replikation wird empfohlen, die folgenden bewährten Methoden zu befolgen:

  • Verwenden Sie pro Speichergruppe je eine Datenbank.   Bei Aktivierung einer Speichergruppe für die fortlaufende lokale Replikation darf diese nur eine Datenbank enthalten. Falls darüber hinaus eine vorhandene Speichergruppe mehrere Datenbanken aufweist, können Sie die fortlaufende lokale Replikation erst für diese Speichergruppe aktivieren, nachdem alle Datenbanken bis auf eine entfernt wurden. Auf diese Weise kann die Microsoft Exchange-Speichertopologie leichter verwaltet und die Wiederherstellbarkeit verbessert werden.

  • Verwenden von Volumebereitstellungspunkten   Sie können Laufwerkbuchstaben oder Volumebereitstellungspunkte für Ihre LUNs (Logical Unit Numbers) der Exchange-Daten verwenden oder Datenträger zum Bestimmen, wo Datenbankdateien und Transaktionsprotokolldateien gespeichert werden. Es wird empfohlen, die Volumebereitstellungspunkte-Funktion für das NTFS-Dateisystem zu verwenden, um die Beschränkung von 26 Laufwerkbuchstaben pro Exchange Server zu umgehen. Indem Sie Volumebereitstellungspunkte verwenden, können Sie eine Zielpartition in einem Ordner auf einem anderen physikalischen Datenträger bereitstellen. Volumebereitstellungspunkte sind für Programme transparent, z. B. auch für Exchange Server. Wenn Fehler in den Transaktionsprotokollen oder Datenbankdateien der Produktionsumgebung entdeckt werden, vereinfacht das Verwenden eines Volumebereitstellungspunkts den Wiederherstellungsprozess dadurch, dass Zuweisungen von Laufwerkbuchstaben und Pfade schnell geändert werden können. Weitere Informationen zur Wiederherstellung bei Fehlern in Produktionstransaktionsprotokoll- und -datenbankdateien finden Sie unter Verwalten der fortlaufenden lokalen Replikation.

  • Partitionieren von Daten zur Optimierung von Leistung und Wiederherstellung   Wenn Daten auf mehrere Festplatten partitioniert werden, verbessert sich im Allgemeinen die Leistung und verringert sich die wiederherzustellende Datenmenge. Je nach Typ des Ausfalls kann das Speichern von Datenbanken und Transaktionsprotokolldateien auf verschiedenen Datenträgern den Datenverlust deutlich minimieren. Wenn Sie beispielsweise Ihre Exchange-Datenbanken und Transaktionsprotokolldateien auf derselben physikalischen Festplatte speichern und diese Festplatte ausfällt, können nur die Daten wiederhergestellt werden, die bei der letzten Sicherung vorhanden waren. Stellen Sie sich im Gegensatz dazu vor, dass Sie die Protokolldateien und die Datenbankdateien auf separaten Datenträgern gespeichert haben. Wenn ein Fehler des Datenträgers auftritt, der die Datenbankdateien enthält, können Sie Ihre Daten aus den Protokolldateien wiederherstellen, die auf dem separaten Datenträger vorhanden sind. Um die Leistung zu optimieren, die Fehlertoleranz zu steigern und die Fehlerbehandlung zu vereinfachen, sollten die Daten so partitioniert werden, dass sich die folgenden Dateien auf unterschiedlichen Datenträgern befinden:

    • Microsoft Windows-Betriebssystemdateien

    • Exchange Server-Anwendungsdateien

    • Exchange-Datenbankdateien auf der aktiven Kopie

    • Exchange-Transaktionsprotokolldateien auf der aktiven Kopie

    • Exchange-Datenbankdateien auf der passiven Kopie

    • Exchange-Transaktionsprotokolldateien auf der passiven Kopie

    Darüber hinaus sollten Sie die passiven Kopien Ihrer für LCR aktivierten Speichergruppen auf Datenträgern ablegen, die von den aktiven Kopien Ihrer für LCR aktivierten Speichergruppen isoliert sind. Darüber hinaus müssen Sie sicherstellen, dass die Datenträger mit den LCR-Dateien die gleichen Leistungsmerkmale aufweisen wie die Datenträger, auf denen sich die Produktionsspeichergruppe befindet. Durch diese Übereinstimmung kann die LCR-Kopie die Last im Fall eines Failovers unterstützen.

  • Genügend Festplattenspeicher muss vorhanden sein   Die Größe der Festplatten mit den LCR-Dateien sollte in etwa der Größe der Produktionsvolumes entsprechen. Die Größe des von den passiven Kopien belegten Speicherplatzes muss dem der aktiven Kopien entsprechen. Darüber hinaus müssen beide Speicherlösungen ausreichend Speicherplatz bieten, um die Größe der vorhandenen Datenbank sowie das erwartete Anwachsen der Datenbank zu unterstützen.

  • Stellen Sie ausreichende Bandbreite und geringe Wartezeiten sicher, wenn Sie iSCSI-Speicher mit LCR verwenden   Es wird zwar nicht empfohlen, doch es ist möglich, LCR mithilfe von Internet SCSI-Speicher (iSCSI) zu konfigurieren, der mit dem Postfachserver über eine LAN- (Local Area Network) oder eine WAN-Verbindung (Wide Area Network) verbunden ist. In dieser Konfiguration würden sowohl die Protokollversand- als auch die Protokollwiedergabeaktivitäten über dasselbe Speichernetzwerk erfolgen. Diese Konfiguration ist hauptsächlich wegen des durch den Protokollversand generierten Netzwerkverkehrs nicht zu empfehlen. Damit LCR das erwartete Sicherheitsniveau bietet, muss der Protokollversand auf der einen Seite stets auf dem aktuellen Stand sein, auf der anderen Seite darf der mit dem Protokollversand verbundene Netzwerkverkehr aber nicht so viel Bandbreite beanspruchen, dass dies den Netzwerkverkehr der Protokollwiedergabeaktivität beeinträchtigt. Es gibt keine Methode, dem Replikationsverkehr Priorität zuzuweisen. Außerdem müssen bestimmte Speicheranforderungen berücksichtigt werden:

    • In der RTM-Version (Release to Manufacturing) von Microsoft Exchange Server 2007 muss der Speicher für die passiven Kopien der Datenbanken einen zwei- bis dreifach höheren IOPS-Wert (E/A-Vorgänge pro Sekunde) als der für die aktiven Kopien der Datenbank verwendete Speicher aufweisen.

    • In Microsoft Exchange Server 2007 Service Pack 1 (SP1) können der Speicher für die passiven Kopien und der Speicher für die aktiven Kopien gleich groß sein.

Hinweis

Mit dem Microsoft Exchange Server Jetstress-Tool können Sie Ihre Speicherlösung überprüfen, bevor sie in die Produktionsumgebung implementiert wird. Es empfiehlt sich, zuerst den für die aktiven Kopien der Datenbanken verwendeten Speicher zu überprüfen und dann den Speicher für die passiven Kopien der Datenbank. Weitere Informationen über Jetstress finden Sie unter "Speicherbezogene Tools" in Speicherüberprüfung.

Prozessor- und Arbeitsspeicherempfehlungen für LCR

Für einen Postfachserver, der für die fortlaufende lokale Replikation (Local Continuous Replication, LCR) aktiviert ist und auf dem alle Dienste der Microsoft Exchange Server 2007-Serverfunktion Mailbox sowie der Microsoft Exchange-Replikationsdienst auf demselben Server ausgeführt werden, müssen zum Verarbeiten dieser zusätzlichen Last weitere Hardwareressourcen zur Verfügung stehen. Der Großteil der zusätzlichen Ressourcenbelegung ergibt sich aus der Protokolldateiüberprüfung und -wiedergabe auf dem für LCR aktivierten Postfachserver. Diese zusätzlichen Verarbeitungskosten belaufen sich auf ungefähr 20 Prozent (über die in Planen von Prozessorkonfigurationen aufgeführten Prozessorempfehlungen hinaus), und sollten beim Planen der Größe von Postfachservern berücksichtigt werden. Außerdem funktioniert der Microsoft Exchange-Replikationsdienst auf einem LCR-Server mit den angegebenen Arbeitsspeicherressourcen gut. Um jedoch die optimale Effizienz des ESE-Datenbankcaches (Extensible Storage Engine) bei der fortlaufenden lokalen Replikation sicherzustellen, empfiehlt es sich, für Exchange-Postfachserver und Server mit mehreren Funktionen 1 GB physikalischen RAM zusätzlich (über die in Planen von Speicherkonfigurationen aufgeführten Arbeitsspeicherempfehlungen hinaus) bereitzustellen.

Empfehlungen hinsichtlich der Datenbankgröße für LCR

LCR bietet eine wesentlich größere Flexibilität für die Wiederherstellung nach schweren Datenverlusten. Die erste Schutzmaßnahme gegen schwerwiegende Speicherausfälle oder eine physische Beschädigung der Datenbank mit LCR besteht darin, die passive Kopie der Daten zu aktivieren und keine Wiederherstellung aus einer Datensicherung durchzuführen. Denken Sie daran, dass LCR schnelle Datenwiederherstellung bietet, jedoch keine Sicherungslösung ist. Durch LCR ist es weitaus weniger entscheidend, kurze Wiederherstellungszeitziele zu erreichen, die auf der Wiederherstellung aus dem Archiv oder von Band basieren. Anstatt von Band wiederherzustellen, aktivieren Sie die passive Kopie, woraufhin die Daten den Clients nach Minuten und nicht erst Stunden wieder zur Verfügung stehen. In diesem Sinne kann LCR als schneller Wiederherstellungsmechanismus betrachtet und in dieselbe Kategorie eingeordnet werden, wie hardwarebasierte Klone, die mithilfe des Volumeschattenkopie-Diensts in Exchange Server 2003 erstellt wurden.

Es ist nicht ungewöhnlich, dass Administratoren aufgrund schlechter Sicherungen Offlinedatenbankvorgänge ausführen müssen (z. B. Reparaturen). (Beispiel: ein fehlerhaftes Band oder ein Wiederherstellungsfehler.) Obwohl sich der Prozentsatz der Situationen, in denen eine Reparatur erforderlich ist, drastisch verringern sollte, wird es sicherlich weiterhin Situationen geben, in denen diese erforderlich ist. Vergewissern Sie sich, dass Sie Ihre Toleranz für die im schlimmsten Fall mögliche Ausfallzeit berücksichtigen, wenn Sie die Datenbankgröße festlegen.

LCR Ihnen es ermöglich, eine Sicherung aus der passiven Kopie einer Speichergruppe zu erstellen. Auf diese Weise können Sie Ihr Onlinewartungsfenster auf der aktiven Kopie ausdehnen. In vielen Fällen können Sie das Onlinewartungsfenster verdoppeln, wodurch Ihnen wiederum ermöglicht wird, größere Postfächer und Datenbanken vorzuhalten.

An diesem Punkt mag es erscheinen, als ob es Ihnen LCR ermöglicht, Ihre Datenbanken ohne Risiko zu einer beliebigen Größe anwachsen zu lassen. Dies ist jedoch nicht der Fall. Eine Onlinewartung, die in einem vertretbaren Zeitraum pro Datenbank abgeschlossen werden kann, ist weiterhin eine Einschränkung für die Datenbankgröße. Bei LCR ist die Möglichkeit, ein erneutes Seeding für Datenbanken durchführen zu müssen, ebenfalls eine Einschränkung. LCR bietet eine Datenbankredundanz, daher kann die Wiederherstellung schnell durch manuelles Aktivieren der passiven Kopie einer Datenbank erreicht werden, wenn die aktive Kopie einer Datenbank verschwunden oder beschädigt ist.

Nach dem Auftreten der Aktivierung ist nur noch eine Kopie der Datenbank vorhanden, die die neue aktive Kopie darstellt. Da die passive Kopie nicht mehr vorhanden ist, kann die Ausfallsicherung der Datenbank beeinträchtigt werden. Sie sollten jedoch weiterhin über Ihre Datensicherung verfügen. Damit die Ausfallsicherung wieder aktiviert wird, muss die verlorene oder beschädigte Datenbank entfernt und eine neue passive Kopie der Datenbank erstellt werden, für die das erneute Seeding von der aktiven Kopie erfolgen muss. In Abhängigkeit von der Größe der Datenbank können diese Aufgaben sehr lange dauern. Der schlimmste Fall ist der Verlust bzw. die Beschädigung aller aktiven Kopien; hierbei muss für alle passiven Kopien das erneute Seeding erfolgen.

Eine höhere maximale Datenbankgröße ist möglich, wenn die fortlaufende Replikation verwendet wird. Für Exchange 2007 werden die folgenden maximalen Datenbankgrößen empfohlen:

  • Auf einem Postfachserver ohne LCR gehostete Datenbanken: 100 GB

  • Auf einem Postfachserver mit LCR gehostete Datenbanken: 200 GB

    Wichtig

    Die wahre maximale Größe für Ihre Datenbank sollte durch die Vereinbarung zum Servicelevel (Service Level Agreement, SLA) festgelegt sein, die in Ihrer Organisation besteht. Durch die Ermittlung der größtmöglichen Datenbank, die innerhalb des in der Vereinbarung zum Servicelevel Ihrer Organisation angegebenen Zeitraums gesichert und wiederhergestellt werden kann, bestimmen Sie die maximale Größe für Ihre Datenbanken.

LCR und Öffentliche Ordner-Datenbanken

LCR und die Replikation Öffentlicher Ordner sind zwei sehr verschiedene Formen der Replikation, die in Exchange integriert sind. Aufgrund der Interoperabilitätsbeschränkungen zwischen der fortlaufenden Replikation und der Replikation Öffentlicher Ordner ist die Replikation Öffentlicher Ordner aktiviert, wenn mehrere Postfachserver in der Exchange-Organisation über eine Öffentliche Ordner-Datenbank verfügen, und Öffentliche Ordner-Datenbanken sollten nicht in einer Speichergruppen gehostet werden, die für fortlaufende Replikation aktiviert ist.

Die folgenden Konfigurationen für die Verwendung Öffentlicher Ordner-Datenbanken und LCR in Ihrer Exchange-Organisation werden empfohlen:

  • Wenn Sie einen einzelnen Postfachserver in Ihrer Exchange-Organisation verwenden, und dieser Postfachserver ist ein eigenständiger Server, kann der Postfachserver eine Öffentliche Ordner-Datenbank in einer für LCR aktivierten Speichergruppe hosten. Bei dieser Konfiguration gibt es nur eine Öffentliche Ordner-Datenbank in der Exchange-Organisation. Deshalb ist die Replikation Öffentlicher Ordner deaktiviert.

  • Wenn Sie mehrere Postfachserver verwenden, und nur einer der Postfachserver enthält eine Öffentliche Ordner-Datenbank, kann der Postfachserver eine Öffentliche Ordner-Datenbank einer für LCR aktivierten Speichergruppe hosten. Bei dieser Konfiguration gibt es nur eine Öffentliche Ordner-Datenbank in der Exchange-Organisation. Deshalb ist die Replikation Öffentlicher Ordner deaktiviert.

  • Wenn Sie Daten Öffentlicher Ordner in eine für LCR aktivierte Speichergruppe migrieren, können Sie die Replikation Öffentlicher Ordner zum Verschieben der Inhalte einer Öffentlichen Ordner-Datenbank in eine Öffentliche Ordner-Datenbank in einer für LCR aktivierten Speichergruppe verwenden. Nachdem Sie die Öffentliche Ordner-Datenbank in einer für LCR aktivierten Speichergruppe erstellt haben, sollten die zusätzlichen Öffentlichen Ordner-Datenbanken nur so lange vorhanden sein, bis die Daten der Öffentlichen Ordner vollständig in die Öffentliche Ordner-Datenbank in der für LCR aktivierten Speichergruppe repliziert wurden. Nachdem die Replikation erfolgreich abgeschlossen wurde, sollten alle Öffentlichen Ordner-Datenbanken außerhalb der für LCR aktivierten Speichergruppe entfernt werden, und Sie sollten keine anderen Öffentlichen Ordner-Datenbanken in der Exchange-Organisation hosten.

  • Wenn Sie Daten Öffentlicher Ordner aus einer für LCR aktivierte Speichergruppe migrieren, können Sie die Replikation Öffentlicher Ordner zum Verschieben der Inhalte einer Öffentlichen Ordner-Datenbank aus der Öffentlichen Ordner-Datenbank in einer für LCR aktivierten Speichergruppe verwenden. Nachdem Sie die zusätzliche Öffentliche Ordner-Datenbank außerhalb der für LCR aktivierten Speichergruppe erstellt haben, sollte die Öffentliche Ordner-Datenbank in der für LCR aktivierten Speichergruppe nur so lange vorhanden sein, bis die Daten des Öffentlichen Ordners vollständig in die zusätzliche Öffentliche Ordner-Datenbank repliziert wurden. Nachdem die Replikation erfolgreich abgeschlossen wurde, sollten alle Öffentlichen Ordner-Datenbanken innerhalb aller für LCR aktivierten Speichergruppen entfernt werden. Alle nachfolgenden Öffentlichen Ordner-Datenbanken sollten nicht in Speichergruppen gehostet werden, die für fortlaufende Replikation aktiviert sind.

Für alle Zeiträume, in denen mehrere Öffentliche Ordner-Datenbanken in der Exchange-Organisation vorhanden sind und mindestens eine Öffentliche Ordner-Datenbank in einer für LCR aktivierten Speichergruppe gehostet wird, gilt Folgendes: Wenn ein Fehler der für LCR aktivierten Speichergruppe auftritt, und die passive Kopie der Speichergruppe mit einer Öffentlichen Ordner-Datenbank aktiviert werden muss, kann diese nur bereitgestellt werden, wenn alle Protokolle für die Speichergruppe, die die Öffentliche Ordner-Datenbank hostet, verfügbar sind. Wenn Protokolle fehlen oder aufgrund des Fehlers der aktiven Kopie nicht verfügbar sind, sind Sie nicht in der Lage, die passive Kopie der Öffentlichen Ordner-Datenbank zu aktivieren. In diesem Fall muss die aktive Kopie online geschaltet werden, um sicherzustellen, dass keine Datenverluste auftreten, oder die Öffentliche Ordner-Datenbank muss in der aktiven Kopie der Speichergruppe erneut erstellt und ihr Inhalt mithilfe der Replikation Öffentlicher Ordner aus einer anderen Öffentlichen Ordner-Datenbank als der passiven Kopie wiederhergestellt werden.

Überwachungsempfehlungen für LCR

LCR ist eine Datenverfügbarkeitslösung. Sie muss proaktiv überwacht werden. Exchange 2007 veröffentlicht eine Vielzahl von Statusinformationen für LCR-Kopien. Nachdem die LCR für eine Speichergruppe aktiviert wurde, können mithilfe der Exchange-Verwaltungskonsole oder der Exchange-Verwaltungsshell der Status und die Konfigurationseinstellungen von LCR-Kopien angezeigt werden. Ausführliche Anleitungen zum Anzeigen von Status- und Konfigurationsinformationen finden Sie unter Anzeigen des Status einer fortlaufenden lokalen Replikationskopie.

Für eine proaktive und automatisierte Überwachung wird der Einsatz von Microsoft Operations Manager (MOM) und des Exchange 2007 Management Pack für MOM empfohlen. Weitere Informationen zum Überwachen von LCR finden Sie unter Überwachung und Betriebsverwaltung.

In Exchange 2007 SP1 können Sie außerdem ein neues Cmdlet mit dem Namen Test-ReplicationHealth verwenden, um den Zustand und Status der für LCR aktivierten Speichergruppen zu überprüfen. Weitere Informationen zum Cmdlet Test-ReplicationHealth finden Sie unter Test-ReplicationHealth.

Sicherung und Wiederherstellung und LCR

LCR bietet den Protokollversand, die Protokollwiedergabe und einen schnellen manuellen Wechsel zu einer sekundären Kopie der Daten. Diese Features verkürzen die Wiederherstellungsdauer, die bei Ausfällen auf Datenebene erforderlich ist. Darüber hinaus verringert LCR die Anzahl der Sicherungen, die für ausreichenden Datenschutz benötigt werden. Zwar befreit LCR die Benutzer nicht davon, Sicherungskopien erstellen zu müssen, doch vollständige Sicherungen sind nun nicht mehr täglich erforderlich. LCR ermöglicht es auch, Volumeschattenkopie-Dienstsicherungen (Volume Shadow Copy Service, VSS) aus der aktiven Speichergruppe in die passive Speichergruppe zu verschieben. Alle vier Sicherungstypen (Vollständig, Kopie, Inkrementell und Differenziell) können von den Speicherorten der passiven Kopie abgerufen werden. Auf diese Weise bleibt wertvolle Datenträger-E/A-Kapazität für die LUNs der aktiven Kopie zum Verarbeiten von Clients erhalten.

Über die Verringerung der Gesamtbetriebskosten (Total Cost of Ownership, TCO) hinaus bietet LCR weitere Vorzüge im Vergleich mit den vorhergehenden Sicherungslösungen. Mithilfe von LCR können zusätzliche Kopien der Exchange-Datenbanken erstellt werden, die folgende Vorteile ermöglichen:

  • Verringerung der Sicherungshäufigkeit der Datenbanken   Die LCR-Kopie ist die erste Verteidigungsmaßnahme beim Ausfall der Produktionsdatenbank. Es müssten sowohl die Produktionsspeichergruppe als auch die Speichergruppenkopie ausfallen, bevor Sicherungskopien erforderlich wären. Folglich wird für diesen Fall eine längere Vereinbarung zum Servicelevel (Service Level Agreement, SLA) empfohlen. Bei einer längeren SLA empfehlen sich wöchentliche vollständige Sicherungen und tägliche inkrementelle Sicherungen.

  • Schnelle Wiederherstellung im Notfall   In der Regel erfolgt die Wiederherstellung innerhalb von maximal 10 Minuten mit geringem oder keinem Datenverlust.

  • Unterstützung für große Postfachkontingente   Diese Unterstützung ist ein Ergebnis der schnellen Wiederherstellung, die von der Datenbankgröße unabhängig ist.

Weitere Einzelheiten und Anleitungen zu Sicherung und Wiederherstellung finden Sie unter Wiederherstellung nach Datenverlust.

Exchange-Sicherungen und fortlaufende lokale Replikation

Exchange-abhängige Sicherungen werden von aktiven Speichergruppen und Datenbanken sowie von passiven Datenbankkopien unterstützt.

Hinweis

Eine häufig auszuführende Aufgabe bei Exchange-abhängigen Sicherungen ist das Abschneiden der Transaktionsprotokolldateien nach dem erfolgreichen Abschluss der Sicherung. Das Replikationsfeature in LCR stellt sicher, dass nicht replizierte Protokolle nicht gelöscht werden. Hierauf folgt, dass das Ausführen von Sicherungen in einem Modus, in dem Protokolle gelöscht werden, nicht tatsächlich Speicherplatz freigibt, wenn die Replikation mit dem Protokollkopiervorgang genügend im Rückstand ist.

Exchange-abhängige Sicherungen in dieser Konfiguration können mithilfe von Streamingsicherungslösungen oder Sicherungslösungen des Volumeschattenkopie-Diensts ausgeführt werden. Zwar können Streamingsicherungen nur für von der aktiven Kopie vorgenommen werden, VSS-Sicherungen können jedoch von der aktiven oder der passiven Kopie erstellt werden.

Exchange-Wiederherstellungen und fortlaufende lokale Replikation

Exchange-abhängige Wiederherstellungen können mithilfe von Streamingsicherungslösungen oder Sicherungslösungen des Volumeschattenkopie-Diensts ausgeführt werden. Die Wiederherstellungen können als Ziel die Speicherorte der aktiven Datenbank und der Protokolldateien verwenden. Exchange-abhängige Wiederherstellungen von Datenbanksicherungen direkt an den Speicherort der passiven Kopie werden vom System nicht unterstützt. Wiederherstellungen an den Speicherorten der passiven Kopie können manuell mithilfe einer Wiederherstellung auf Dateiebene durchgeführt werden.

Bevor Sie eine Datenbank aus einer Speichergruppe wiederherstellen, die für fortlaufende lokale Replikation konfiguriert war, sollten Sie die fortlaufende lokale Replikation für die Speichergruppe anhalten. Nach dem Abschluss der Wiederherstellung kann die fortlaufende lokale Replikation fortgesetzt werden. Sie fortlaufende lokale Replikation sollte für Datenbanken angehalten werden, die wiederhergestellt werden.

Nach der Wiederherstellung einer Datenbank aus einer Sicherung in einer für LCR aktivierten Speichergruppe müssen Sie die fortlaufende Replikation für die Speichergruppe mithilfe der Cmdlets Suspend-StorageGroupCopy bzw. Resume-StorageGroupCopy anhalten und wieder fortsetzen. Dieser Prozess ist erforderlich, um den Microsoft Exchange-Replikationsdienst mit den richtigen Protokollgenerierungsinformationen zu aktualisieren. Wenn die fortlaufende Replikation nicht angehalten und wieder fortgesetzt wird, verfügt der Microsoft Exchange-Replikationsdienst über veraltete Protokollgenerierungsinformationen und beendet die Replikation von Protokolldateien.