Wiederherstellung verlorener E-Mails nach einem Exchange-Server-Absturz

Dem Artikel zu Folge erforderten die nächsten Schritte an den korrupten Exchange-Datenbanken einen „harten oder gewaltsamen Befehl zur Zustandswiederherstellung“, der nur als letzte Möglichkeit eingesetzt werden sollte. Dieser Vorgang beinhaltet zwei nacheinander auf jeder der zwei wichtigsten Exchange-Datenbanken auszuführende Befehle: Pub.edb und Priv.edb.

Peter führte auf jeder Datenbank zuerst den ersten und dann den zweiten Befehl aus. Der erste Befehl erzwingt die Recovery. Der zweite erzwingt die Durchführung einer Reihe von 23 Tests auf jeder Datenbank. Sollten die Test nicht bestanden werden, werden die beiden Befehle nacheinander wiederholt.

Bei den beiden ersten Ausführungen der Befehle, brach die Testreihe nach etwa dem neunten Test ab. Peter erhielt eine JET-Fehlermeldung, die, einem anderen Q-Artikel zu Folge, auf eine Inkonsistenz der Datenbank hinwies.

Beim dritten Versuch absolvierten die Datenbanken alle 23 Tests, allerdings wurden am Ende viele Fehlermeldungen angezeigt.

Der Recovery-Prozess erfordert, dass der Netzwerkadministrator beim Auftreten von Fehlermeldungen jeden Prozess dreimal durchführt. Erst wenn die Liste der Fehler bei allen drei Versuchen die gleiche ist, kann er oder sie zum nächsten Schritt übergehen. Die Microsoft Dokumentation besagt, dass die Fehler auf ein korruptes Attachment hinweisen könnten, allerdings würde dies den Informationsspeicher nicht beim Starten behindern. Und genau das ist Peter auch passiert.

Da er beim Einrichten des neuen Servers den Verzeichnisspeicher (Dir.edb) nicht vom alten Exchange-Server kopiert hatte, musste er nun die Exchange-Server Konsistenzanpassung (Consistency Adjuster) ausführen. Die Konsistenzanpassung aktualisiert den neuen Verzeichnisspeicher mit allen Dateien, die sie aus den gerade getesteten Datenbanken wiederherstellen kann. Zu diesem Zeitpunkt hatte Peter alles wiederhergestellt, was nur wiederherzustellen war.