Sicherung, Wiederherstellung und Notfallwiederherstellung in Exchange Server

Die Planung des Schutzes von Daten ist ein komplexer Vorgang, der auf zahlreichen Entscheidungen beruht, die Sie in der Planungsphase Ihrer Bereitstellung treffen. Im Rahmen Ihrer Planung ist es wichtig, dass Sie wissen, wie Daten geschützt werden können, und um zu bestimmen, welche Methode den Anforderungen Ihrer Organisation am besten entspricht.

Bisher wurden Sicherungen für die folgenden Szenarien verwendet:

  • Notfallwiederherstellung: Bei einem Hardware- oder Softwarefehler ermöglichen mehrere Datenbankkopien in einer DAG eine hohe Verfügbarkeit mit schnellem Failover und geringem oder keinem Datenverlust. So werden Downtime und die entsprechenden Produktivitätsverluste vermieden, die wesentlich zu den Kosten einer Wiederherstellung einer Sicherung auf Festplatte oder Band beitragen, die zu einem vergangenen Zeitpunkt erstellt wurde. DAGs können auf mehrere Standorte erweitert werden und können Schutz vor dem Ausfall von Datenträgern, Servern, Netzwerken und Rechenzentren bieten.

  • Wiederherstellung versehentlich gelöschter Elemente: In der Vergangenheit musste in einer Situation, in der ein Benutzer Elemente gelöscht hat, die später wiederhergestellt werden mussten, das Sicherungsmedium gefunden werden, auf dem die wiederhergestellten Daten gespeichert wurden, und dann in irgendeiner Weise die gewünschten Elemente abrufen und dem Benutzer zur Verfügung stellen. Mit dem Ordner "Wiederherstellbare Elemente" in Exchange 2016 und Exchange 2019 und der Aufbewahrungsrichtlinie, die darauf angewendet werden kann, ist es möglich, alle gelöschten und geänderten Daten für einen bestimmten Zeitraum aufzubewahren, sodass die Wiederherstellung dieser Elemente einfacher und schneller ist. Dies entlastet Exchange-Administratoren und IT-Helpdesk, indem Endbenutzern ermöglicht wird, versehentlich gelöschte Elemente selbst wiederherzustellen und so die Komplexität und die Verwaltungskosten der Wiederherstellung einzelner Elemente zu senken. Weitere Informationen finden Sie unter Messaging-Richtlinie und Compliance in Exchange Server und Verhinderung von Datenverlust in Exchange Server.

  • Langfristige Datenspeicherung: Sicherungen wurden auch als Archiv verwendet, und normalerweise wird Einband verwendet, um Point-in-Time-Momentaufnahmen von Daten über einen längeren Zeitraum zu speichern, wie es den Complianceanforderungen entspricht. Die neuen Features für Archivierung, Suche mit mehreren Postfächern und Nachrichtenaufbewahrung in Exchange Server einen Mechanismus bereitstellen, um Daten über einen längeren Zeitraum effizient auf zugängliche Weise für Endbenutzer zu speichern. Dadurch werden teure Wiederherstellungen durch Band eliminiert und die Produktivität erhöht. Weitere Informationen finden Sie unter In-Situ-Archivierung in Exchange Server, In-Situ-eDiscovery in Exchange Serverund In-Situ-Aufbewahrung und Beweissicherung in Exchange Server.

  • Momentaufnahme einer Point-in-Time-Datenbank: Wenn eine frühere Point-in-Time-Kopie von Postfachdaten für Ihre Organisation erforderlich ist, bietet Exchange die Möglichkeit, eine verzögerte Datenbankkopie in einer DAG-Umgebung zu erstellen. Dies kann in dem seltenen Fall nützlich sein, dass eine logische Beschädigung des Speichers auf mehrere Datenbankkopien in der DAG repliziert wird, sodass die Rückkehr zu einem bestimmten Zeitpunkt in der Vergangenheit erforderlich ist. Es kann auch hilfreich sein, wenn ein Administrator versehentlich Postfächer oder Benutzerdaten löscht. Die Wiederherstellung von einer verzögerten Kopie kann schneller sein als die Wiederherstellung von einer Sicherung, weil für verzögerte Kopien kein zeitaufwändiger Kopiervorgang vom Sicherungsserver zum Exchange-Server erforderlich ist. Dies kann zu einer deutlichen Reduzierung der Gesamtbetriebskosten führen, indem die Downtime reduziert wird.

Da es systemeigene Exchange Server Features gibt, die jedes dieser Szenarien effizient und kosteneffektiv erfüllen, können Sie die Verwendung herkömmlicher Sicherungen in Ihrer Umgebung reduzieren oder ausschließen.

Systemeigener Exchange-Datenschutz

Die bevorzugte Architektur von Microsoft für Exchange Server 2016 und Exchange Server 2019 nutzt ein Konzept, das als Exchange nativer Datenschutz bezeichnet wird. Exchange Nativer Datenschutz basiert auf integrierten Exchange Features, um Ihre Postfachdaten zu schützen, ohne Sicherungen zu verwenden (obwohl Sie diese Features weiterhin verwenden und Sicherungen erstellen können). Exchange 2016 und Exchange 2019 umfassen mehrere Features, die bei korrekter Bereitstellung und Konfiguration systemeigenen Datenschutz bieten können, sodass keine herkömmlichen Sicherungen Ihrer Daten erforderlich sind. Die Verwendung der in Exchange Server integrierten Features für hohe Verfügbarkeit zur Minimierung von Ausfallzeiten und Datenverlusten im Falle eines Notfalls kann auch die Gesamtbetriebskosten des Messagingsystems reduzieren. Durch die Kombination dieser Features mit anderen integrierten Features, z. B. gesetzliche Aufbewahrungspflicht, können Sie die Verwendung herkömmlicher Point-in-Time-Sicherungen reduzieren oder ausschließen und die damit verbundenen Kosten reduzieren.

Zusätzlich zur Bestimmung, ob Exchange Server es Ihnen ermöglicht, sich von herkömmlichen Point-in-Time-Sicherungen zu entfernen, wird empfohlen, die Kosten Ihrer aktuellen Sicherungsinfrastruktur zu bewerten. Beachten Sie die Kosten der Downtime für Endbenutzer und der Datenverluste bei dem Versuch der Wiederherstellung nach einem Notfall unter Verwendung der vorhandenen Sicherungsinfrastruktur. Berücksichtigen Sie auch die Kosten für Hardware, Installation und Lizenzen sowie die Verwaltungskosten, die mit der Wiederherstellung von Daten und der Pflege von Sicherungen einhergehen. Je nach den Anforderungen Ihrer Organisation ist es sehr wahrscheinlich, dass eine reine Exchange 2016- oder Exchange 2019-Umgebung mit mindestens drei Postfachdatenbankkopien niedrigere Gesamtbetriebskosten als eine mit Sicherungen bietet.

Es gibt mehrere Probleme, die Sie berücksichtigen sollten, bevor Sie die in Exchange Server integrierten Features als Ersatz für herkömmliche Sicherungen verwenden. Möglicherweise gibt es auch Aspekte, die für Ihre Organisation einzigartig sind. Berücksichtigen Sie die folgenden Probleme, und beachten Sie, dass es sich hierbei nicht um eine vollständige Liste handelt:

  • Sie sollten bestimmen, wie viele Kopien der Datenbank bereitgestellt werden müssen. Es wird dringend empfohlen, mindestens drei (nicht verzögerte) Kopien einer Postfachdatenbank bereitzustellen, bevor Sie herkömmliche Arten des Schutzes für die Datenbank aufgeben, z. B. RAID (Redundant Array of Independent Disks) oder herkömmliche VSS-basierte Sicherungen.

  • Sie sollten die angestrebte Wiederherstellungsdauer und den angestrebten Wiederherstellungszeitpunkt klar definieren, und Sie sollten sich vergewissern, dass eine Kombination integrierter Features statt herkömmlicher Sicherungen Ihnen das Erreichen dieser Ziele ermöglicht.

  • Sie sollten bestimmen, wie viele Kopien jeder Datenbank erforderlich sind, um die unterschiedlichen Ausfallszenarien abzudecken, gegen die Ihr System einen Schutz darstellen soll.

  • Sie sollten bestimmen, ob Sie durch den Verzicht auf eine DAG oder einiger ihrer Mitglieder ausreichend Kosten einsparen, um eine herkömmliche Sicherungslösung zu unterstützen. Falls dies der Fall ist, sollten Sie bestimmen, ob diese Lösung Ihre in den Vereinbarungen zum Servicelevel (Service Level Agreements, SLAs) angestrebte Wiederherstellungsdauer oder Ihren angestrebten Wiederherstellungszeitpunkt verbessert.

  • Sie sollten bestimmen, ob Sie es sich leisten können, eine zu einem bestimmten Zeitpunkt erstellte Kopie zu verlieren, wenn auf dem DAG-Mitglied, das als Host der Kopie dient, ein Fehler auftritt, der die Kopie oder die Integrität der Kopie beeinflusst.

  • mit Exchange Server können Sie viel größere Postfächer mit einer empfohlenen maximalen Postfachdatenbankgröße von 2 Terabyte bereitstellen (wenn zwei oder mehr hoch verfügbare Postfachdatenbankkopien verwendet werden). Basierend auf den größeren Postfächern, die die meisten Organisationen bereitstellen werden, sollten Sie den angestrebten Wiederherstellungszeitpunkt bestimmen, wenn Sie bei der Aktivierung einer Datenbankkopie oder einer verzögerten Datenbankkopie zahlreiche Protokolldateien wiedergeben müssen.

  • Sie sollten bestimmen, wie Sie erkennen und verhindern, dass eine logische Beschädigung einer aktiven Datenbankkopie in die passiven Kopien der Datenbank repliziert wird. Dazu gehört, einen Wiederherstellungsplan für diese Situation festzulegen und herauszufinden, wie häufig dieses Szenario in der Vergangenheit eingetreten ist. Wenn in Ihrer Organisation häufig logische Beschädigungen auftreten, sollten Sie dieses Szenario in Ihrem Entwurf berücksichtigen, indem Sie mindestens eine verzögerte Kopie verwenden und das Zeitfenster für die Wiedergabeverzögerung ausreichend groß wählen, um das Auftreten logischer Beschädigungen zu erkennen und zu handeln, bevor diese Beschädigungen an andere Datenbankkopien repliziert werden.

Eine der Funktionen, die am Ende einer erfolgreichen vollständigen oder inkrementellen Sicherung ausgeführt werden, ist das Abschneiden der Transaktionsprotokolldateien, die nicht mehr für die Datenbankwiederherstellung benötigt werden. Wenn Sicherungen nicht ausgeführt werden, erfolgt kein Abschneiden von Protokollen. Wenn Sie verhindern möchten, dass die Protokolldateien immer umfangreicher werden, aktivieren Sie die Umlaufprotokollierung für die replizierten Datenbanken. Wenn Sie die Umlaufprotokollierung mit der fortlaufenden Replikation kombinieren, erhalten Sie eine neue Art der Umlaufprotokollierung mit der Bezeichnung CRCL (Continuous Replication Circular Logging, Umlaufprotokollierung bei fortlaufender Replikation), die sich von der ESE-Umlaufprotokollierung (Extensible Storage Engine) unterscheidet. Im Gegensatz zur ESE-Umlaufprotokollierung, die vom Microsoft Exchange-Informationsspeicherdienst ausgeführt und verwaltet wird, wird CRCL vom Microsoft Exchange-Replikationsdienst ausgeführt und verwaltet. Wenn aktiviert, generiert die ESE-Umlaufprotokollierung keine zusätzlichen Protokolldateien und überschreibt stattdessen im Bedarfsfall die aktuelle Protokolldatei. Allerdings werden in einer Umgebung mit fortlaufender Replikation Protokolldateien für den Protokollversand und die Protokollwiedergabe benötigt. Dementsprechend wird, wenn Sie CRCL aktivieren, die aktuelle Protokolldatei nicht überschrieben, und es werden geschlossene Protokolldateien für Protokollversand und -wiedergabe generiert.

Der Microsoft Exchange-Replikationsdienst verwaltet CRCL so, dass die Protokollkontinuität beibehalten wird, und Protokolle werden nicht gelöscht, wenn sie noch für die Replikation benötigt werden. Der Microsoft Exchange-Replikationsdienst und der Microsoft Exchange-Informationsspeicherdienst kommunizieren über Remoteprozeduraufrufe (Remote Procedure Calls, RPCs) darüber, welche Protokolldateien gelöscht werden können.

Damit das Abschneiden bei Postfachdatenbankkopien mit hoher Verfügbarkeit (nicht verzögert) erfolgt, muss Folgendes gelten:

  • Die Protokolldatei wurde gesichert, oder CRCL ist aktiviert.

  • Die Protokolldatei liegt unter dem Prüfpunkt.

  • Die anderen, nicht verzögerten Kopien der Datenbank stimmen dem Löschvorgang zu.

  • Die Protokolldatei wurde von allen verzögerten Kopien der Datenbank untersucht.

Damit das Abschneiden bei verzögerten Postfachdatenbankkopien erfolgt, muss Folgendes gelten:

  • Die Protokolldatei liegt unter dem Prüfpunkt.

  • Die Protokolldatei ist älter als "ReplayLagTime" + "TruncationLagTime".

  • Die Protokolldatei wurde in der aktiven Kopie der Datenbank gelöscht.

Unterstützte Sicherungstechnologien

Exchange Server unterstützt nur Exchange-fähige, VSS-basierte Sicherungen. Exchange Server enthält ein Plug-In für Windows Serversicherung, mit dem Sie VSS-basierte Sicherungen von Exchange Daten erstellen und wiederherstellen können. Um Exchange Server zu sichern und wiederherzustellen, müssen Sie eine Exchange-fähige Anwendung verwenden, die den VSS-Writer für Exchange Server unterstützt, z. B. Windows Serversicherung (mit dem VSS-Plug-In), Microsoft System Center 2012 – Data Protection Manager oder eine Exchange-fähige VSS-basierte Anwendung eines Drittanbieters.

Genaue Anweisungen zum Sichern und Wiederherstellen von Exchange-Daten mit der Windows Server-Sicherung finden Sie unter Sichern und Wiederherstellen von Exchange-Daten mithilfe der Windows Server-Sicherung.

Exchange Server VSS Writer

Frühere Versionen von Exchange enthielten zwei VSS-Autoren: einen innerhalb des Microsoft Exchange Information Store-Diensts (store.exe) und einen innerhalb des Microsoft Exchange-Replikationsdiensts (msexchangerepl.exe). Zurück in Exchange 2013 wurde die VSS Writer-Funktion, die zuvor im Microsoft Exchange Information Store-Dienst gefunden wurde, in den Replikationsdienst von Microsoft Exchange verschoben. Diese Architektur ist in Exchange 2016 und Exchange 2019 unverändert. Dieser Writer mit dem Namen Microsoft Exchange Writer wird von Exchange-fähigen VSS-basierten Anwendungen verwendet, um aktive und passive Datenbankkopien zu sichern und gesicherte Datenbankkopien wiederherzustellen. Obwohl der Writer im Replikationsdienst von Microsoft Exchange ausgeführt wird, muss der Dienst "Microsoft Exchange Information Store" ausgeführt werden, damit der Writer angekündigt wird. Es sind also beide Dienste erforderlich, um Exchange-Datenbanken zu sichern oder wiederherzustellen.

Exchange Server-Wiederherstellung

Fast alle Konfigurationseinstellungen für Postfachserver und Clientzugriffsdienste werden in Active Directory gespeichert. Wie bei früheren Versionen von Exchange enthalten Exchange 2016 und Exchange 2019 einen Setupparameter für die Wiederherstellung verlorener Server. Dieser Parameter , /m:RecoverServer, wird verwendet, um einen verloren gegangenen Server mithilfe der in Active Directory gespeicherten Einstellungen und Konfigurationsinformationen neu zu erstellen und neu zu erstellen. Beachten Sie jedoch, dass es mehrere Einstellungen gibt, die nicht wiederhergestellt werden, z. B. Änderungen an lokalen web.config und anderen Konfigurationsdateien. Darüber hinaus werden benutzerdefinierte Registrierungseinträge nicht wiederhergestellt. Es wird empfohlen, einen zuverlässigen Änderungsverwaltungsprozess zu verwenden, um diese Änderungen nachzuverfolgen und neu zu erstellen.

Ausführliche Schritte zum Ausführen einer Serverwiederherstellung eines verloren gegangenen Exchange Servers finden Sie unter Wiederherstellen eines Exchange Server. Genaue Anweisungen zum Wiederherstellen eines verlorenen Servers, der Mitglied einer Database Availability Group (DAG) ist, finden Sie unter Wiederherstellen von Mitgliedsservern einer Datenbankverfügbarkeitsgruppe.

Wiederherstellung des einheitlichen Kontaktspeichers

Wenn Microsoft Lync Server 2013 oder Skype for Business Server 2015 in einer Exchange 2016- oder Exchange 2019-Umgebung verwendet wird, werden die Lync/Skype for Business Kontaktinformationen des Benutzers in einem speziellen Kontaktordner im Postfach des Benutzers gespeichert. Dieser wird als einheitlicher Kontaktspeicher (Unified Contact Store, UCS) bezeichnet. Wenn Sie ein UCS-migriertes Postfach wiederherstellen, kann sich dies auf die Chatkontaktliste des Zielbenutzers auswirken. Wenn der Benutzer nach der letzten Sicherung migriert wurde, führt die Wiederherstellung des Postfachs zum vollständige Verlust der Benutzerkontaktliste. In weniger schweren Fällen gehen nur die Änderungen an der Kontaktliste verloren, die der Benutzer seit der letzten Sicherung durchgeführt hat. Zur Vermeidung eines potenziellen Datenverlusts müssen Sie sicherstellen, dass der Benutzer auf den Chatserver zurückmigriert wird, bevor das Postfach wiederhergestellt wird.

Wiederherstellungsdatenbank

Eine Wiederherstellungsdatenbank ist eine spezielle Art von Postfachdatenbank, mit der Sie eine wiederhergestellte Postfachdatenbank einbinden und im Rahmen einer Wiederherstellung Daten aus der wiederhergestellten Datenbank extrahieren können. Verwenden Sie das Cmdlet New-MailboxRestoreRequest, um Daten aus einer Wiederherstellungsdatenbank zu extrahieren. Anschließend können die Daten in einen Ordner exportiert oder mit einem vorhandenen Postfach zusammengeführt werden. Mithilfe von Wiederherstellungsdatenbanken können Sie Daten aus einer Sicherung oder Kopie der Datenbank wiederherstellen, ohne den Benutzerzugriff auf aktuelle Daten zu stören.

Die Verwendung einer Wiederherstellungsdatenbank für eine Postfachdatenbank einer früheren Version von Exchange wird nicht unterstützt. Außerdem muss sich das Zielpostfach, das zur Datenzusammenführung und -extraktion verwendet wird, in derselben Active Directory-Gesamtstruktur befinden wie die in der Wiederherstellungsdatenbank eingebundene Datenbank.

Weitere Informationen finden Sie unter Wiederherstellungsdatenbanken. Genaue Anweisungen zum Erstellen einer Wiederherstellungsdatenbank finden Sie unter Erstellen einer Wiederherstellungsdatenbank. Genaue Anweisungen zum Verwenden einer Wiederherstellungsdatenbank finden Sie unter Wiederherstellen von Daten mithilfe einer Wiederherstellungsdatenbank.

Datenbankportabilität

Die Datenbankportabilität ist ein Feature, mit dem eine Exchange Postfachdatenbank auf einen anderen Exchange Postfachserver in derselben Organisation verschoben und dort bereitgestellt werden kann. Mithilfe der Datenbankportabilität wird die Zuverlässigkeit verbessert, indem auf verschiedene fehleranfällige manuelle Schritte bei den Wiederherstellungsprozessen verzichtet werden kann. Darüber hinaus verringert die Datenbankportabilität die Gesamtwiederherstellungsdauer für verschiedene Fehlerszenarien.

Genaue Anweisungen zur Verwendung der Datenbankportabilität finden Sie unter Verschieben einer Postfachdatenbank mithilfe der Datenbankportabilität.

Dial Tone-Portabilität

Die Funktion für die Dial Tone-Portabilität bietet eine eingeschränkte Geschäftskontinuitätslösung für Ausfälle, die sich auf eine Postfachdatenbank, einen Server oder einen ganzen Standort auswirken. Durch die Dial Tone-Portabilität erhalten Benutzer die Möglichkeit, ein temporäres Postfach zum Senden und Empfangen von E-Mails zu nutzen, während ihr ursprüngliches Postfach wiederhergestellt oder repariert wird. Das temporäre Postfach kann sich auf demselben Exchange Postfachserver oder auf einem anderen Exchange Postfachserver in Ihrer Organisation befinden. Somit kann ein alternativer Server die Postfächer von Benutzern hosten, die sich zuvor auf einem anderen Server befunden haben, der jetzt nicht mehr verfügbar ist. Clients mit Unterstützung der AutoErmittlung, z. B. Microsoft Outlook, werden automatisch auf den neuen Server umgeleitet, ohne dass das Desktopprofil des Benutzers manuell aktualisiert werden muss. Nach der Wiederherstellung der eigentlichen Postfachdaten des Benutzers kann ein Administrator das wiederhergestellte Postfach und das Dial Tone-Postfach des Benutzers in ein einziges, aktuelles Postfach zusammenführen.

Das Verfahren zur Verwendung der Dial Tone-Portabilität wird als Dial Tone-Wiederherstellung bezeichnet. Eine Dial Tone-Wiederherstellung umfasst das Erstellen einer leeren Datenbank auf einem Postfachserver, um eine fehlerhafte Datenbank zu ersetzen. Mithilfe dieser leeren Datenbank, die auch als Dial Tone-Datenbank bezeichnet wird, können Benutzer E-Mails senden und empfangen, während die fehlerhafte Datenbank wiederhergestellt wird. Nach der Wiederherstellung der fehlerhaften Datenbank werden die Dial Tone-Datenbank und die wiederhergestellte Datenbank ausgetauscht, und die Daten aus der Dial Tone-Datenbank werden dann mit denen in der wiederhergestellten Datenbank zusammengeführt.

Weitere Informationen finden Sie unter Dial Tone-Portabilität. Genaue Anweisungen zum Durchführen einer Dial Tone-Wiederherstellung finden Sie unter Durchführen einer "Dial Tone"-Wiederherstellung.