Dialtone Recovery
Die von Exchange verwendete EDB-Datenbank ist in der Regel sehr robust und benötigt außer einem regelmäßigem Backup und der Kontrolle des Wachstums keine weitere Pflege. Jede Datenbank ist bei Exchange 2007 eine große Datei (*.EDB) mit zusätzlichen Transaktionsprotokollen (EDB*.LOG). Einige zusätzliche Dateien (*.JRS,*.CHK) liefern zusätzliche Informationen. Allerdings gibt es äußere Faktoren, die auch eine Exchange Datenbank unbrauchbar werden lassen. Meist sind es Fehler im müssenspeicher, Dateisystemprobleme, SAN-Probleme etc., die eine Datenbank korrupt werden lassen. Um die verschiedenen Szenarien von Exchange 2007 und Datenbankwerkzeuge aufzuzeigen, kann folgender Durchlauf exerziert werden:
Zeit |
Phase |
Beschreibung |
---|---|---|
t1 |
Betrieb |
Eine Exchange Server empfängt und sendet Mails. Die neuen Objekte landen in den Transaktionsprotokollen Die Datenbank speichert die neuen Elemente |
t1 |
Backup |
Die Datenbank wird regulär gesichert. Auf dem Band landen auch die Transaktionsprotokolle während der Sicherung. ältere Transaktionsprotokolle werden auf dem Server gelöscht. |
t1-t2 |
Betrieb |
Während und nach dem Backup geht der Betrieb natürlich weiter. Weitere Transaktionsprotokolle werden geschrieben |
t2 |
Fehler |
Durch ein „KILL“ auf den Prozess „Store“ kann z.B. ein Fehler von Exchange simuliert werden. Die Datenbank ist im Status „Dirty Shutdown, was per ESEUTIL auch gezeigt werden kann. Diese Datenbank sollten sie aber nicht löschen, denn seit dem letzten Backup sind ja ein paar Stunden vergangen und wenn beim Desaster auch die Logfiles verloren sin, könnten Sie diese DB ja nutzen, um vielleicht nach einer harten Reparatur einen Teil der zwischenzeitlich empfangenen Mails wieder zu erlangen Um in einer ÜbungsUmgebung einen schweren Fehler zu simulieren, können Sie die Logfiles entfernen, die ESEUTIL als „required“ anzeigt. Dann kann diese Datenbank nicht mehr sauber online gehen und die DB doch noch als Quelle für ein späteres Extrahieren zu verwenden muss diese mit ESEUTIL repariert werden. |
t3 |
Dialtone |
Der Fehler ist erkannt und eine Reparatur der Datenbank dauert zu lange und wird samt Protokolldateien auf einen temporären Platz verschoben. Immerhin sind dort noch ungesicherte Elemente von 22:00 bis 14:00 enthalten, die später vielleicht doch noch extrahiert werden könnten. |
t3-t4 |
Notbetrieb |
Als Interimslösung wird die Datenbank nun „leer“ gestartet. Als Notbetrieb können die Anwender nun zumindest neue Mails weiter empfangen und darauf antworten. In der Zwischenzeit wird das letzte gute Backup in eine Wiederherstellungsspeichergruppe restauriert, was angenommene 50Min dauert. |
t4 |
Recovery |
Die Datenbank ist zurück gesichert wird zum Test einmal „online“ genommen. Wer hat, kann vorher noch die Protokolldateien der fehlerhaften Datenbank hinzufügen, um den Datenverlust zu minimieren. |
t4 |
Swap |
Nachdem die wiederhergestellte Datenbank als „OK“ bewertet wurde, werden nun die Interimsdatenbank und die Recoverydatenbank getauscht. Nun haben die Anwender alle alten Nachrichten bis 22:00. Wurden Protokolldateien eingespielt, sind die Daten noch aktueller. Wenn Sie nicht "SWAP"-pen wollen, dann beachten Sie die Hinweise am Ende der Seite |
t5 |
Betrieb |
Die zwischenzeitlich in der Interimsdatenbank aufgelaufenen Elemente werden nun über den normalen „Merge“-Prozess wieder in die aktuelle produktive Datenbank eingebunden. Damit ist die produktive Datenbank fast wieder auf dem aktuellen Stand. Nun sollten Sie aber den Exchange 2007 Volltextindex neu generieren lassen, damit die Ergebnisse auch den tatsächlichen Inhalt wiedergeben. |
t6 |
ESEUTIL |
Eventuell durch den Fehler verlorene Mails, deren zugehörige Protokolldateien z.B. korrupt oder verloren waren, können eventuell noch in der defekten Datenbank vorliegen. Diese Datenbank kann über „ESEUTIL /P“ nun zwangsweise wieder in den Status „Clean Shutdown“ versetzt werden, was aber durchaus Stunden dauern kann. Danach kann die Datenbank ebenfalls als Recovery Storage Group eingebunden werden. Sofern möglich können noch fehlende Elemente in die aktive Datenbank überführt werden. |
Hier habe ich den ganzen Ablauf noch mal als zeitliches Ablaufdiagramm aufgezeichnet, wie sie in einer TestUmgebung dies einfach nachstellen können.
Anhand dieser Simulation können alle Aspekte einer Wiederherstellung geübt werden.
- ESEUTIL zum prüfen der Datenbank
- Dialtone Recovery
- Wiederherstellung in Recovery Storage Group mit Nachschieben von Transaktionsprotokollen und betrachten des Roll Forward
- Datenbank Swap mit nachfolgendem Merge der Dialtone-Datenbank
- ESEUTIL /P-Reparatur der defekten Datenbanken
- Einbinden reparierter Datenbanken als Recovery storage group mit nachfolgendem Zusammenführen der Datenbanken.
Wer darüber hinaus weniger Daten verlieren möchte für den sind Replikationstechniken (CCR, SCR, LCR) und Journalarchivierung auf andere Systeme mögliche Optionen, eine Kopie bestimmter Mails auf einem zweiten unabhängigen System vorzuhalten.
Swap mit Dialtone oder Merge aus RecoverDB
Wenn die Wiederherstellung etwas länger dauert, dann wird natürlich auch die vormals leere temporäre Datenbank nach und nach mit Daten gefüllt. Es gibt Administratoren, die kommen dann auf die Idee, einfach die temporäre Datenbank "live" zu lassen und später die Daten der wiederhergestellten Datenbank per Ontrack Powercontrols oder Recovery Storage Group einfach wieder in die Datenbank zu importieren. Das sollten Sie sich aber ganz genau überlegen. Es ist in der Regel einfacher, doch die Datenbanken zu tauschen und die Inhalte der sicher kleineren temporären Datenbank wieder in die restaurierte DB zu importieren. Es gibt aber auch ein paar handfeste Gründe, z.B.:
- Verlust von Regeln
Diese sind eine versteckte Nachricht im Postfach und fehlen in der temporären Datenbank. Ein Merge aus der alten produktiven DB bringt diese Informationen nicht mit - Verlust von OOF
Hier gilt das gleiche wie bei Regeln - Verlust von Stellvertretern und Folder Permissions
Stellvertreter sind nicht nur ein Feld im AD (Delegate), sondern auch ACLs im Postfach drin. Rechte werden generell bei einem Merge nicht mit übernommen. Damit verlieren Sie faktisch alle vergebenen Berechtigungen. - Probleme mit Terminserien
Wäre nicht das erste mal, aber es ist eine "neue" Datenbank, in der Sie per Import neue Termine anlegen. Die Verbindungen zu anderen Personen und auch beim Abgleich mit einem PDA sind nicht mehr kompatibel - Verlust des Single instance storage (bis Ex2007, Ab
Ex2010 gibt es den so nicht mehr)
Das ist verständlich, da ein Merge aus dem alten Original ja jede Mail einzeln extrahiert und wieder importiert. Nebenbei vergrößert sich also auch die Datenbank. - Transactionlogs
Wer gigabyteweise neue Elemente aus einer alten Quelle in die noch fast leere DB importiert, generiert jede menge Transaktionsprotokolle, die natürlich auch wieder per Backup oder mit temporär aktivierter Umlaufprotokollierung reduziert werden müssen. In Verbindung mit CCR oder DAG kommt die Replikationslast noch mal oben drauf. - Outlook Profile und OST
Es ist sicher verständlich, dass Outlook das neue Postfach erst dann als richtiges Postfach ansieht, wenn das Profil einmal runderneuert wurde. Dann allerdings wird Outlook natürlich auch die OST-Datei neu aufbauen, - Es dauert einfach länger
Mit einer durchschnittlichen MAPI-Migration von 2-4 GB/h kann es schon Tage dauern, bis alle alten Mails wieder da sind
Um es Kurz zu machen: Bitte nicht eine Dialtone-Datenbank produktiv machen und die alten Daten über Umwege dort wieder importieren. Das wäre nur dann ein Weg, wenn die alte Datenbank unter keinen umständen mehr online zu bekommen wäre-. Dann müssten Sie sich aber schon fragen lassen, wie sie denn in der Vergangenheit gesichert haben.