Contents
Eine Datenbankverfügbarkeitsgruppe (Database Availability Group, DAG) eignet sich hervorragend für Failover und Hochverfügbarkeit für Ihren Exchange Server und Ihre Dienste. Obwohl dies die beste Lösung für die Geschäftskontinuität und Datenrettung von Exchange Server ist, können Sie auf einige unvorhergesehene Probleme stoßen, die die Leistung, Qualität und Datenintegrität der Exchange Server-Infrastruktur beeinträchtigen könnten.
Eines der schlimmsten Szenarien, die einem Exchange-Administrator begegnen können, ist, wenn eine Postfachdatenbank ausgehängt wird. Wenn Sie versuchen, die Datenbank zu mounten, kann der folgende Fehler auftreten:
Die Datenbank “DB01” konnte nicht gemountet werden. Fehler: Ein Active Manager-Prozess ist fehlgeschlagen. Fehler: Während eines Active Manager-Vorgangs ist ein Fehler aufgetreten. Um diesen Vorgang durchzuführen, muss der Server Mitglied einer Datenbankverfügbarkeitsgruppe sein und die Datenbankverfügbarkeitsgruppe muss ein Quorum haben. Fehler: Es ist nicht möglich, aus der Cluster-Datenbank zu lesen.
Dies kann vorkommen, wenn der Server kürzlich aus der Datenbankverfügbarkeitsgruppe entfernt wurde.
[Server: EX2019.mail.lan]
+ CategoryInfo : InvalidOperation: (DB01:ADObjectId) [Mount-Database], InvalidOperationException
+ FullyQualifiedErrorId : [Server=EX2019,RequestId=c51a831c-33e3-4a75-867f-51433b925ee2,TimeStamp=1/1/2020
4:13:12 AM] [FailureCategory=Cmdlet-InvalidOperationException] 7E29F70A,Microsoft.Exchange.Management.SystemConfigurationTasks.MountDatabase
+ PSComputerName : EX2019.mail.lan
Der oben genannte Fehler kann aus verschiedenen Gründen auftreten. Einige der Gründe sind
- Ein schief gelaufenes Update
- Menschliches Versagen
- Hardware-Ausfall
- Leistungsverlust
- Malware und Ransomware-Angriffe
- Korruption oder Speicherprobleme
- Ausfall der Speichereinheit des Servers
Fehler “Datenbankverfügbarkeitsgruppe muss Quorum haben” beheben
Zuerst sollten Sie überprüfen, ob Sie die Mehrheit der Stimmen in Ihrem Cluster haben. Das bedeutet, dass die Hälfte Ihrer Server plus ein Server online sind und alle beteiligten Server gesund sind und laufen. Sie müssen auch überprüfen, ob der Speicher jedes Knotens sowie die Exchange- und Clusterdienste laufen und keine Fehler aufgetreten sind. Wenn ein Hardwareproblem aufgetreten ist, das den Server ausgeschaltet hat, könnte dies ein Problem darstellen, da die DAG mit nur einem von drei Servern nicht funktionieren kann. Wie bei anderen Clustern (z.B. SQL) wird der Cluster als Sicherheitsvorkehrung abgeschaltet, wenn die Mehrheit der Stimmen nicht erreicht wird.
Wenn alle Korrekturen durchgeführt wurden und Sie nichts tun können, um die Dienste wieder in den Normalzustand zu versetzen, besteht die einzige Möglichkeit darin, die Datenbankkopien zu entfernen, so dass sich der Server im Einzeldatenbankmodus befindet.
Führen Sie dazu den Befehl Remove-DatabaseAvailabiltyGroupServer in der Exchange Management Shell aus. Dieser Befehl löscht alle DAG-Einträge aus dem Active Directory.
Hinweis: Es ist nicht notwendig, vorher eine Sicherungskopie aller Daten zu erstellen, da nur die Konfiguration gelöscht wird.
Remove-DatabaseAvailabilityGroupServer -ConfigurationOnly -MailboxServer SRV-MBX-01 -Identity DAG001
Dieser Vorgang muss auf jedem Knoten durchgeführt werden. Wenn Ihre Datenbankverfügbarkeitsgruppe (DAG) also aus zwei Servern besteht, müssen Sie die oben genannten Schritte auf beiden Servern durchführen.
Sobald dieser Vorgang abgeschlossen ist, wird die Konfiguration der Datenbankverfügbarkeitsgruppe (DAG) aus dem Active Directory entfernt.
Der nächste Schritt besteht darin, die Knoten aus dem Windows-Cluster zu entfernen. Für diesen Vorgang können Sie jedoch nicht den Cluster Manager verwenden. Sie müssen dies mit der PowerShell tun. Der Vorgang ist recht einfach, da Sie nur Get-ClusterNode und Remove-ClusterNode mit dem Parameter force verwenden müssen (wie im Beispiel unten).
Get-ClusterNode <Servername> | Remove-ClusterNode -Force
Wenn die Exchange Server-Einrichtung für die Datenbankverfügbarkeitsgruppe (DAG) aus zwei oder mehr Servern besteht, müssen Sie dies für jeden Knoten in Ihrem Cluster tun.
Jede Konfiguration der Datenbankverfügbarkeitsgruppe wird dann aus dem Active Directory-Schema entfernt und das Setup sollte als eigenständiger Server konvertiert werden. Das bedeutet, dass nach dem Neustart des Servers die Datenbank gemountet werden sollte, da sie aus der Datenbankverfügbarkeitsgruppe (DAG) entfernt wurde.
Was soll ich tun, wenn die Datenbanken immer noch nicht gemountet sind?
Wenn wir jetzt sagen, dass die Datenbanken ohne Probleme gemountet werden sollten, bedeutet dies, dass die Datenbanken nicht beschädigt wurden. Wenn die Datenbanken immer noch nicht gemountet werden, sollten Sie die Datenbanken mit den systemeigenen Tools überprüfen, die mit Exchange Server geliefert werden, wie z.B. ESEUtil.
ESEUtil ist ein natives Tool, das Probleme identifiziert und versucht, beschädigte Datenbanken zu reparieren. Es muss über eine Befehlszeilenschnittstelle ausgeführt werden.
Um festzustellen, ob die Datenbank beschädigt ist, müssen Sie das ESEUtil mit dem Parameter /mh ausführen und den Status der Datenbank überprüfen. Eine gesunde Datenbank würde den Status Clean Shutdown haben, während eine beschädigte Datenbank Dirty Shutdown anzeigen würde.
EseUtil /mh <Exchange Datenbankdatei>
ESEUtil bietet zwei Optionen für die Datenrettung – Soft Recovery und Hard Recovery. Bei der sanften Datenrettung handelt es sich, wie der Name schon sagt, um eine sanfte/schnelle Wiederherstellung der Datenbank. Wenn der Schaden geringfügig ist, versucht die sanfte Datenrettung, das Problem zu beheben.
Wenn dies fehlschlägt und der Datenbankstatus im Zustand “Dirty Shutdown” verbleibt, bedeutet dies, dass der Schaden schwerwiegend ist. In einem solchen Fall besteht die einzige Lösung darin, die Datenbanken aus einem Backup wiederherzustellen. Dies führt jedoch zu einem Datenverlust, da Sie nur die Daten des letzten Backups wiederherstellen können. Die andere Möglichkeit besteht darin, eine Datenrettung auf dem Laufwerk durchzuführen. Auch dies führt zu Datenverlusten, da bei der Datenrettung alle Daten gelöscht werden, die als beschädigt gelten. Andererseits wird Microsoft Sie nicht unterstützen, wenn die Datenbank als hart wiederhergestellt eingestuft wird. Außerdem gibt es keine Garantie, dass die Datenbank anschließend gemountet werden kann.
Als gesunde Alternative können Sie eine Anwendung eines Drittanbieters wie Stellar Repair for Exchange verwenden, mit der Sie jede Exchange Server-Datenbank in jedem Zustand einfach öffnen und die EDB-Datei lesen und durchsuchen können. Sie können die Daten in PST und andere Formate exportieren. Die Software zur Datenrettung von Exchange Server verfügt auch über eine Funktion zum direkten Export in eine Live Exchange Server-Datenbank oder einen Office 365-Mieter.