Exchange NOTFALL - Serverdesaster 5.5

Dieser Abschnitt gilt für Exchange 5.5. Wenn Sie einen Exchange 2000 Server haben, sollten Sie die Seite Serverdesaster 2000 lesen. Lesen Sich auch die Einleitung auf der Exchange NOTFALL Seite. Diese Seite trifft zu, wenn ihr Exchange Server defekt ist und sie KEIN Backup haben. Mit einem Backup sollten Sie Restore mit Backup lesen.

Abhängig davon, was von ihrem Exchange Server noch übrig ist müssen sie ein paar Entscheidungen treffen:

Entsprechend finden Sie nun drei Abschnitte, die ihnen Hinweise für das Recovery gehen. und schreiben, was möglich ist und was nicht und einige Tricks.

Datenbanken wieder online nehmen.

Wenn sie noch die Datenbanken haben, sollte unter erstes Ziel sein, diese wieder ans Leben zu bringen oder zumindest die Inhalte zu exportieren. Dazu ist es notwendig, diese Dateien mit Exchange zu öffnen oder ein Recoverytool wie Ontrack PowerControls zu nutzen.

Für die folgenden Schritte sollten Sie etwas wissen, wie die Exchange Datenbank funktioniert und welche Dateien dazu gehören (-> Datenbankgrundlagen). Und dann ist wichtig, dass eine Exchange Datenbank nur dann von Exchange geöffnet werden kann, wenn folgende Voraussetzungen stimmen:

Wenn Sie diese Daten nicht kennen, dann installieren Sie Exchange mit neuen Werten und schauen beim ersten Start nach der Fehlermeldung im Eventlog. Exchange schreibt hier, wie die Organisation und Site heißen müsste und dann dürfen Sie noch mal anfangen.

Wenn den Namen der Organisation oder der Administrativen Gruppe nicht dokumentiert ist und Sie sich die zweimalige Installation ersparen wollen, könenn Sie versuchen aus bestehenden Daten diese Information auszulesen. Wer noch Zugriff auf die Registrierung oder das Active Directory des alten Servers hat, kann hier nach den Werten suchen. (HKLM\System\CurrentControlSet\Services\MSExchangeIS\Parameters). Aber auch in den Protokolldateien und der Datenbank selbst sind die Werte oft zu finden. Eine Volltextsuche nach "/o=" kann helfen, da bei Exchange die Daten in den Protokolldateien als /o=Organisation/OU=Standortname" hinterlegt sind.

Die sichern die Datenbank in ein anderen Verzeichnis und installieren Exchange 5.5 mit dem SETUP. Ob Sie hierbei nun ein normales SETUP machen oder ein "SETUP /R" hängt davon ab, ob Sie Konnectoren manuell wieder einrichten wollen. Das Datenbanken können sie bei beiden Setups wieder unterschieben. Beim normalen Setup bekommen Sie zumindest "leere" Datenbanken für DIR.EDB, PRIV.EDB und PUB.EDB, was speziell dann hilfreich ist, wenn ihre alten Datenbanken nicht komplett wieder da sind.

Nach der Installation von Exchange sind die Dienste zu stoppen, die bestehenden Datenbanken samt LOG und CHK-Datei zu verschieben  und die alten Datenbanken wieder einzustellen.

Es ist eine gute Idee, das Diagnoseprotokoll von Exchange (Eigenschaften des Servers) für den "Start/Beenden" und "Allgemein" des Informationsspeicher (IS) auf Maximum zu setzen und das Eventlog groß genug zu machen. Wenn der Dienst nicht startet, dann ist das Eventlog zugleich erste Anlaufstelle um die Ursache zu finden (z.B. falsch eingegebene Werte für Organisation oder Standort)

Nun können Sie mit "ESEUTIL /MH c:\exchsrvr\mdbdata\priv.edb" (und entsprechend DIR.EDB und PUB.EDB) nachsehen, ob die Datenbanken konsistent sind oder nicht. (Siehe ESEUTIL). Wenn die Datenbanken konsistent sind und alles andere passt, dann sollten Sie die Protokolldateien und CHK-Datei verschieben, so dass nur noch die Datenbanken übrig sind. Eventuell müssen Sie ein ISINTEG /PATCH ausführen, damit einige Zuordnungen in der Datenbank und der Registrierung des Servers neu gesetzt werden. Aber auch dies "lesen" Sie im Eventlog nach.

Sollten die Datenbanken allerdings nicht "Clean Shutdown" sein, dann sind offene Transaktionen in den Protokolldateien, welche beim Start des Store gesucht und eingespielt werden. Hier hängt es nun davon ab, ob Sie die Dateien noch alle haben (welche das sind siehe ESEUTIL) und an der richtigen Stelle liegen (Siehe Eventlog). Legen Sie die Dateien an die richtige Stelle (Eventlog) und starten Sie den Dienst.

Wenn all das nichts hilft, dann liegt der Verdacht nahe, dass der Schaden größer ist und die Datenbanken nicht mehr auf dem normalen Weg "konsistent" gemacht werden können. Ursache können fehlende oder korrupte Protokolldateien (EDB*.LOG) sein oder eine wirklich defekte Datenbank.

Dann bleibt nur noch die Chance, mit ESEUTIL so lange zu reparieren, bis die Datenbank wieder gestartet werden kann (Siehe ESEUTIL). Sie sollten aber auf jeden Fall immer eine "gute" Kopie der defekten Datenbank vorhalten, so dass mehrere Versuche oder spätere externe Hilfe möglich sind. Leider kann ich hierzu keine "Schritt für Schritt" Anleitung liefern, da hier mehr Praxis und Erfahrung zählen als Kommandozeilen. Wenn Sie nach der Reparatur die Datenbank wieder am Laufen haben, dann sollten Sie schnellstens dafür sorgen, die Inhalte zu exportieren (Siehe Exmerge). Nur so wissen Sie, welche Inhalte zuverlässig lesbar sind und den Store nicht wieder zum Absturz bringen. Ob sie die reparierte Datenbank später produktiv nutzen möchten oder nicht müssen Sie sich überlegen. Empfehlungen gibt es kaum. Versteckte Probleme können Sie später zum Wahnsinn bei der Fehlersuche treiben aber ein Neuaufbau mit EXMERGE lässt die Datenbank stark wachsen (-> Wegfall des Single Instance Store). Wer Zeit und Ressourcen hat, kann einen zweiten Server installieren und die Ordner replizieren und Postfächer verschieben

Keine Datenbanken mehr

Schade. Mehr kann man dazu nicht sagen, denn ohne Datenbanken keine Daten zum Restaurieren. Aber trotzdem muss nicht alles verloren sein. Es gibt mehrere Stellen, an denen Sie "suchen" können um, den Informationsverlust zu minimieren:

Sie erkennen aber schon, dass der Verlust der Datenbanken ohne Backup immer einen schweren Datenverlust gleich kommt und alle Ansätze den Schaden nur verringern können. Aber als wenn der Datenverlust nicht schon schlimm genug wiegt, können auch Zivil- und Strafrechtliche Folgen folgen. Gerade Finanzämter und Strafverfolgungsbehörden sind sehr ungehalten, wenn wichtige Daten nicht mehr verfügbar sind. Das kann bis zum Vernichten von Beweisen gedeutet werden. Vielleicht reicht solche in Hinweis an den Geschäftsführer, dass die Mittel für eine ordentliche Datensicherung  bereitgestellt werden.

Domäne ist verloren

Der Verlust der Domäne ist für Exchange 5.5 besonders kritisch, da Exchange ein so genanntes "Dienstkonto" nutzt, um zu arbeiten. Das Konto zeichnet sich durch die interne Nummer (SID) aus. Eine neue gleichnamige Domäne oder ein neu angelegter Benutzer mit gleichem Namen hat trotzdem eine unterschiedliche SID und ist damit nicht geeignet.

Wenn Sie keine Möglichkeit mehr haben, die Original Domäne wieder herzustellen, dann können Sie auch nicht mehr Exchange restaurieren aber wenn ihr Exchange noch läuft, dann kann ein Trick helfen

Sie sehen, dass der Verlust einer Domäne mit Exchange 5.5 nicht zu unterschätzen ist, da die SID Problematik nicht einfach gelöst werden kann. Daher gehört zu einem sicheren Exchange Betrieb immer auch eine Sicherung der Domäne und ab einer bestimmten Firmengröße mehrere Domain Controller. Mit Exchange 2000 wird diese Abhängigkeit noch kritischer.

Weitere Links

Keywords: Notfall Exchange Desaster Recovery