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 verstehen, wie Daten geschützt werden können, und dass Sie bestimmen, welche Methode am besten zu den Anforderungen Ihrer Organisation passt.
Bisher wurden Sicherungen für die folgenden Szenarien verwendet:
Notfallwiederherstellung: Im Falle eines Hardware- oder Softwarefehlers ermöglichen mehrere Datenbankkopien in einer DAG Hochverfü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 war es in einer Situation, in der ein Benutzer Elemente gelöscht hat, die später wiederhergestellt werden mussten, das Sicherungsmedium zu finden, auf dem die Daten gespeichert wurden, die wiederhergestellt werden mussten, und dann irgendwie die gewünschten Elemente abzurufen und sie dem Benutzer zur Verfügung zu 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 beizubehalten, 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 Messagingrichtlinie und -compliance in Exchange Server und Verhinderung von Datenverlust in Exchange Server.
Langfristige Datenspeicherung: Sicherungen wurden auch als Archiv verwendet, und in der Regel wird Band verwendet, um Momentaufnahmen von Daten zu einem bestimmten Zeitpunkt über einen längeren Zeitraum hinweg gemäß den Complianceanforderungen beizubehalten. Die neuen Archivierungs-, Such- und Nachrichtenaufbewahrungsfunktionen in Exchange Server bieten einen Mechanismus zum effizienten Aufbewahren von Daten auf eine für Endbenutzer zugängliche Weise für längere Zeiträume. Dadurch werden teure Wiederherstellungen von Band vermieden und die Produktivität erhöht. Weitere Informationen finden Sie unter In-Place-Archivierung in Exchange Server, In-Place eDiscovery in Exchange Server und In-Place-Aufbewahrung und Beweissicherung in Exchange Server.
Momentaufnahme der Point-in-Time-Datenbank: Wenn eine Kopie der Postfachdaten in der Vergangenheit 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 native Exchange Server Features gibt, die jedes dieser Szenarien auf effiziente und kostengünstige Weise erfüllen, können Sie die Verwendung herkömmlicher Sicherungen in Ihrer Umgebung möglicherweise reduzieren oder ausschließen.
Systemeigener Exchange-Datenschutz
Die bevorzugte Architektur von Microsoft für Exchange Server 2016 und Exchange Server 2019 nutzt ein Konzept namens Exchange Native Data Protection. Der native Schutz von Exchange-Daten basiert auf integrierten Exchange-Funktionen, um Ihre Postfachdaten ohne die Verwendung von Sicherungen zu schützen (obwohl Sie diese Features weiterhin verwenden und Sicherungen erstellen können). Exchange 2016 und Exchange 2019 enthalten mehrere Features, die bei ordnungsgemäßer Bereitstellung und Konfiguration nativen Datenschutz bieten können, der die Notwendigkeit entfällt, herkömmliche Sicherungen Ihrer Daten durchzuführen. Die Verwendung der in Exchange Server integrierten Hochverfügbarkeitsfeatures zur Minimierung von Ausfallzeiten und Datenverlusten im Notfall kann auch die Gesamtkosten des Messagingsystems senken. Durch die Kombination dieser Features mit anderen integrierten Features, z. B. Gesetzliche Aufbewahrung, können Sie die Verwendung herkömmlicher Point-in-Time-Sicherungen reduzieren oder eliminieren und die damit verbundenen Kosten senken.
Zusätzlich zur Bestimmung, ob Exchange Server es Ihnen ermöglicht, sich von herkömmlichen Point-in-Time-Sicherungen zu entfernen, empfiehlt es sich, 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. Abhängig von den Anforderungen Ihrer Organisation ist es sehr wahrscheinlich, dass eine reine Exchange 2016- oder Exchange 2019-Umgebung mit mindestens drei Postfachdatenbankkopien niedrigere Gesamtkosten 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. Es kann auch Überlegungen geben, die für Ihre Organisation eindeutig sind. Beachten Sie die folgenden Probleme, und beachten Sie, dass dies keine vollständige Liste ist:
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 hochverfü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 die Windows Server-Sicherung, mit dem Sie VSS-basierte Sicherungen von Exchange-Daten erstellen und wiederherstellen können. Zum Sichern und Wiederherstellen Exchange Server müssen Sie eine Exchange-fähige Anwendung verwenden, die den VSS Writer für Exchange Server unterstützt, z. B. Windows Server-Sicherung (mit dem VSS-Plug-In), Microsoft System Center 2012 – Data Protection Manager oder eine Exchange-fähige VSS-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-Writer: einen innerhalb des Microsoft Exchange-Informationsspeicherdiensts (store.exe) und einen im Microsoft Exchange-Replikationsdienst (msexchangerepl.exe). Zurück in Exchange 2013 wurde die zuvor im Microsoft Exchange-Informationsspeicherdienst gefundene VSS Writer-Funktionalität in den Microsoft Exchange-Replikationsdienst verschoben. Diese Architektur bleibt 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 Microsoft Exchange-Replikationsdienst ausgeführt wird, muss der Microsoft Exchange-Informationsspeicherdienst 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 zum Wiederherstellen 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. Beachten Sie jedoch, dass mehrere Einstellungen 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, dass Sie einen zuverlässigen Change Management-Prozess verwenden, um diese Änderungen nachzuverfolgen und neu zu erstellen.
Ausführliche Schritte zum Ausführen einer Serverwiederherstellung eines verlorenen 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 beliebigen anderen Exchange-Postfachserver in derselben Organisation verschoben und eingebunden 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 beliebigen 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.