Offlinesicherungs- und Wiederherstellungsverfahren für Exchange Server

SPRACHE AUSWÄHLEN SPRACHE AUSWÄHLEN
Artikel-ID: 296788 - Produkte anzeigen, auf die sich dieser Artikel bezieht
Dieser Artikel wurde zuvor veröffentlicht unter D296788
Dieser Artikel ist eine Übersetzung des folgenden englischsprachigen Artikels der Microsoft Knowledge Base:
296788 Offline Backup and Restoration Procedures for Exchange
Bitte beachten Sie: Bei diesem Artikel handelt es sich um eine Übersetzung aus dem Englischen. Es ist möglich, dass nachträgliche Änderungen bzw. Ergänzungen im englischen Originalartikel in dieser Übersetzung nicht berücksichtigt sind. Die in diesem Artikel enthaltenen Informationen basieren auf der/den englischsprachigen Produktversion(en). Die Richtigkeit dieser Informationen in Zusammenhang mit anderssprachigen Produktversionen wurde im Rahmen dieser Übersetzung nicht getestet. Microsoft stellt diese Informationen ohne Gewähr für Richtigkeit bzw. Funktionalität zur Verfügung und übernimmt auch keine Gewährleistung bezüglich der Vollständigkeit oder Richtigkeit der Übersetzung.
Alles erweitern | Alles schließen

Auf dieser Seite

Zusammenfassung

Dieser Artikel beschreibt die Verfahren, mit deren Hilfe Sie die Online-Sicherungs-APIs (API = Application Programming Interface) umgehen und die Exchange-Informationsspeicher-Datenbanken manuell sichern und wiederherstellen können. Wenn mehrere Speichergruppen auf einem Exchange-Server vorhanden sind, muss jede Speichergruppe zu Zwecken der Offlinesicherung und -wiederherstellung als unabhängige, selbstständige Einheit betrachtet werden.Weitere Informationen zu Offline- und Snapshot-Sicherungen finden Sie in folgendem Artikel der Microsoft Knowledge Base:
296787 XADM: Offline Backup and Restoration Procedures for Exchange Server 4.0, 5.0, and 5.5

Weitere Informationen

Dieser Artikel ist in folgende Abschnitte untergliedert:

Voraussetzungen

Bevor Sie eine Offlinesicherung ausführen, müssen Sie über die folgenden Informationen verfügen:
  • Stellen Sie fest, ob die zirkuläre Protokollierung für die Speichergruppe aktiviert ist. (Die zirkuläre Protokollierung ist in Exchange standardmäßig deaktiviert.) Öffnen Sie die Eigenschaften des Objekts Speichergruppe im Exchange System-Manager, und zeigen Sie die Seite Allgemein an, um festzustellen, ob die zirkuläre Protokollierung aktiviert ist. Deaktivieren Sie das Kontrollkästchen Zirkuläre Protokollierung, indem Sie darauf klicken. Änderungen an der zirkulären Protokollierung werden erst wirksam, wenn Sie die einzelnen Datenbanken in der Speichergruppe anhalten.

    Es ist nicht erforderlich, die zirkuläre Protokollierung zu deaktivieren, um Offlinesicherungen auszuführen. Sie müssen die zirkuläre Protokollierung jedoch deaktivieren, wenn Sie Transaktionsprotokolle in wiederhergestellte Offlinesicherungen zurückspielen möchten.
  • Ermitteln Sie den Pfad Ihrer Exchange-Datenbank-, -Streaming-, -Transaktionsprotokoll- und -Prüfpunktdateien sowie das Protokolldatei-Präfix für die Speichergruppe.

    Öffnen Sie die Eigenschaften des Objekts Speichergruppe im Exchange System-Manager, und zeigen Sie die Seite Allgemein an, um diese Informationen anzuzeigen. Notieren Sie die Werte für die drei folgenden Felder:
    • Präfix für Protokolldatei (E0n, wobei E0n auch E00, E01, E02 oder E03 sein kann)
    • Pfad des Transaktionsprotokolls ("E0n*.log")
    • Systempfad ("E0n.chk")
    Die Datenbankpfade werden in den Datenbankeigenschaften der einzelnen Datenbankname-Objekte aufgelistet. Notieren Sie die Werte für die beiden folgenden Felder für jede Datenbank in der Speichergruppe:
    • Exchange-Datenbank (.edb)
    • Exchange-Streamingdatenbank (.stm)
Wenn der Exchange System-Manager nicht verfügbar ist, können Sie die vorgenannten Informationen ermitteln, indem Sie die Attribute mithilfe eines Tools wie ADSIEDIT oder LDIFDE direkt aus dem Active Directory lesen. Sie können den folgenden LDIFDE-Befehl zum Ausgeben von Informationen für alle Exchange-Server in einer Active Directory-Struktur verwenden.

Hinweis: Der Text dieses Befehls wurde aus Gründen der besseren Lesbarkeit umgebrochen.
LDIFDE -F EXPATHS.TXT -D "CN=CONFIGURATION,DC=Konfigurationscontainer_Domäne,DC=Übergeordnete_Domäne" -L MSEXCHESEPARAMLOGFILEPATH,MSEXCHESEPARAMSYSTEMPATH,
MSEXCHESEPARAMBASENAME,MSEXCHESEPARAMCIRCULARLOG,MSEXCHSLVFILE,
MSEXCHEDBFILE -R"(|(MSEXCHESEPARAMLOGFILEPATH=*)(MSEXCHESEPARAMSYSTEMPATH=*)(MSEXCHESEPARAMBASENAME=*)(MSEXCHESEPARAMCIRCULARLOG=*)(MSEXCHEDBFILE=*)(MSEXCHSLVFILE=*))"
Der folgende Text ist ein Beispiel für die Ausgabe des voranstehenden Befehls:
D:\exchsrvr\mdbdata>ldifde -f con -d "cn=configuration,dc=test,dc=com" -l msexch eseparamlogfilepath,msexcheseparamsystempath,msexcheseparambasename,msexchesepar amcircularlog,msexchslvfile,msexchedbfile -r "(|(msexcheseparamlogfilepath=*)(ms excheseparamsystempath=*)(msexcheseparambasename=*)(msexchslvfile=*)(msexchedbfi le=*)(msexcheseparamcircularlog=*))"
Verbindung zu "dc1.child.test.com" wird hergestellt
Anmelden als aktueller Benutzer unter Verwendung von SSPI
Das Verzeichnis wird in die Datei "con" exportiert
Es wird nach Einträgen gesucht...

<Verkürzte Ausgabe>

.dn: CN=Erste Speichergruppe,CN=Informationsspeicher,CN=Exchange1,CN=Server,CN=Erste administrative Gruppe,CN=Administrative Gruppen,CN=Firma,CN=Microsoft Exchange,CN=Dienste,CN=Configuration,DC=Test,DC=com
changetype: add
msExchESEParamCircularLog: 0
msExchESEParamLogFilePath: D:\exchsrvr\MDBDATA
msExchESEParamSystemPath: D:\exchsrvr\MDBDATA
msExchESEParamBaseName: E00

.dn: CN=Öffentlicher Informationsspeicher (EXCHANGE1),CN=Erste Speichergruppe,CN=Informationsspeicher,CN=Exchange1,CN=Server,CN=Erste administrative Gruppe,CN=Administrative Gruppen,CN=Firma,CN=Microsoft Exchange,CN=Dienste,CN=Configuration,DC=Tes t,DC=com
changetype: add
msExchEDBFile: D:\exchsrvr\MDBDATA\PUB.EDB
msExchSLVFile: D:\exchsrvr\MDBDATA\PUB.stm

.dn: CN=Privater Informationsspeicher (Exchange1),CN=Erste Speichergruppe,CN=Informationsspeicher,CN=Exchange1,CN=Server,CN=Erste administrative Gruppe,CN=Administrative Gruppen,CN=Firma,CN=Microsoft Exchange,CN=Dienste,CN=Configuration,DC=Test,DC=com
changetype: add
msExchEDBFile: D:\exchsrvr\MDBDATA\PRIV.EDB
msExchSLVFile: D:\exchsrvr\MDBDATA\PRIV.stm
Um die Transaktionsprotokolle erfolgreich zurückspielen zu können, müssen Sie die Datenbankdateien (EDB- und STM-Dateien) in dem gleichen Pfad wiederherstellen, in dem diese gesichert wurden. Wenn Sie beispielsweise die Datenbankdatei im Ordner "E:\Mdbdata" und die Streamingdatenbankdatei im Ordner "F:\Mdbdata" sichern, müssen Sie die Dateien auch wieder im Ordner "E:\Mdbdata" bzw. im Ordner "F:\Mdbdata" wiederherstellen. Diese Beschränkung trifft auch dann zu, wenn Sie die Datenbank auf einem vollkommen anderen Server wiederherstellen möchten (beispielsweise bei der Wiederherstellung eines Postfachs).

Wenn Sie den Datenbankpfad nach der letzten Sicherung ändern, können Sie die Transaktionsprotokolle nur teilweise zurückspielen. Ein teilweises Zurückspielen ist außerdem nur möglich, wenn Sie den Pfad wieder in den ursprünglichen Pfad ändern. Wenn Sie wieder den ursprünglichen Pfad angeben, können Sie die Protokolle bis zu dem Zeitpunkt zurückspielen, zu dem der Pfad geändert wurde.

Sie können die Transaktionsprotokolldateien ("E0n*.log") in einem anderen Pfad als dem usprünglichen Sicherungsordner wiederherstellen. Dies ist möglich, weil die Transaktionsprotokolle zwar die Standorte der Datenbanken, mit denen sie verknüpft sind, jedoch nicht den Standort der Transaktionsprotokolle aufzeichnen. Beim Zurückspielen "finden" die Protokolle die Datenbanken anhand von Pfadinformationen, die im Header der Transaktionsprotokolle gespeichert sind. (Die API für die Online-Sicherung kompensiert Datenbankpfadänderungen intern. Daher trifft diese Beschränkung nicht zu.)

Die Prüfpunktdatei ("E0n.chk") muss nicht gesichert oder wiederhergestellt werden. Sie müssen jedoch den aktuellen Standort der Prüfpunktdatei kennen, weil Sie diese Datei bei der Wiederherstellung überprüfen oder löschen müssen.

Zurück zum Überblick

Beziehungen zwischen Exchange-Datenbankdateien

Die EDB- und STM-Dateien sind endgültige Repositories für alle Datenbankinformationen. In den meisten Fällen sind diese beiden Dateien so zu behandeln, als wenn es sich um eine Datei handelt. Diese Dateien müssen gemeinsam gesichert und wiederhergestellt werden. Außerdem müssen diese beiden Dateien stets synchronisiert sein. Eine EDB-Datei, die an einem Tag gesichert wurde, kann nicht gemeinsam mit einer Streamingdatei verwendet werden, die an einem anderen Tag gesichert wurde.

Ein Exchange 2000- oder Exchange 2003-Server kann bis zu vier Speichergruppen und jede Speichergruppe wiederum bis zu fünf Datenbanken unterstützen. Eine Speichergruppe besteht aus einer Reihe von Datenbanken, die gemeinsame Transaktionsprotokolldateien verwenden. Microsoft Exchange Server 5.5 kann maximal eine Speichergruppe unterstützen, die wiederum maximal zwei Datenbanken unterstützt (den privaten und den öffentlichen Informationsspeicher).

Werden Änderungen an der Datenbank vorgenommen, so werden die Änderungen zunächst in die aktuelle Transaktionsprotokolldatei und anschließend in einen In-Memory-Cache geschrieben. Sobald die Änderungen im Cache gespeichert sind, werden sie für die Benutzer sichtbar. Die Seiten im Cache werden zu einem geeigneten Zeitpunkt in die Datenbankdatei übertragen. Der Prüfpunkt markiert den Zeitpunkt in der Protokolldateisequenz, bis zu dem alle Transaktionen physisch in die Datenbankdatei übertragen wurden. Es ist normal, dass der Prüfpunkt drei oder mehr Protokolldateien hinter der aktuellen Protokolldatei liegt.

Um Verwirrungen darüber zu vermeiden, welche Protokolldateien zu den einzelnen Speichergruppen gehören, werden Exchange-Protokolle, die zu einer bestimmten Speichergruppe gehören, mit einem eindeutigen Protokollpräfix benannt. Das Präfix besteht aus den ersten drei Zeichen des Dateinamens. Gültige Protokollpräfixe für die vier Speichergruppen, die auf einem Exchange 2000- oder Exchange 2003-Server unterstützt werden, sind E00, E01, E02 und E03. In diesem Artikel wird das Protokollpräfix für eine Speichergruppe immer mit "E0n" angegeben. Die aktuelle Protokolldatei für eine Speichergruppe ist immer "E0n.log".

Transaktionsprotokolle besitzen eine einheitliche Größe von 5 MB. Wenn die aktuelle Protokolldatei voll ist, wird sie in eine hexadezimale Sequenznummer, die sogenannte Protokollerzeugungsnummer, umbenannt, und es wird eine neue aktuelle Protokolldatei generiert. Die Protokolldateien werden mit "E0n00001.log", "E0n00002.log" usw. nummeriert. In diesem Artikel werden nummerierte Protokolldateien im Allgemeinen mit "E0n xxxxx.log" bezeichnet.

Wenn eine Datenbank nicht normal angehalten wird, zeichnet die Prüfpunktdatei ("E0n.chk") das Transaktionsprotokoll auf, aus dem der Wiederherstellungsprozess beginnen muss, damit die Datenbank konsistent wiederhergestellt werden kann. Dieser Prozess wird als "Soft Recovery" bezeichnet. Das Gegenstück zu diesem Prozess ist der "Hard Recovery"-Vorgang, bei dem die Protokolldateien nach der Wiederherstellung einer Onlinesicherung zurückgespielt werden. Der wichtigste Unterschied zwischen diesen beiden Prozessen besteht darin, dass die Patchdatei-Daten bei der Hard Recovery für das Zurückspielen in die Protokolldatei interpoliert werden.

Eine inkonsistente Exchange-Datenbankdatei ist eine Datei, in die noch nicht alle ausstehenden Transaktionen geschrieben wurden. Während des normalen Betriebs sind die Exchange-Datenbankdateien inkonsistent, weil Informationen im Cache vorhanden sind, die noch nicht physisch in die Dateien geschrieben wurden. Im Allgemeinen kann eine Exchange-Datenbankdatei nur als konsistent betrachtet werden, wenn der Datenbankdienst normal heruntergefahren wurde. Die Datenbank als Ganzes (betrachtet als die Summe der Informationen in den Transaktionsprotokollen und Datenbankdateien) ist jedoch immer konsistent, sofern erforderliche Protokolldateien nicht vorzeitig gelöscht werden.

Zurück zum Überblick

Offlinesicherung einer Exchange-Datenbank

Gehen Sie folgendermaßen vor, um eine Exchange-Datenbank offline zu sichern:
  1. Heben Sie die Bereitstellung der zu sichernden Datenbank auf. Es ist nicht erforderlich, dies für alle Datenbanken in der Speichergruppe zu tun. Sie müssen nur die Bereitstellung der Datenbank bzw. Datenbanken aufheben, die Sie tatsächlich sichern möchten.
  2. Stellen Sie sicher, dass die Datenbankdateien (die EDB- und .STM-Datei) konsistent und miteinander synchronisiert sind. Führen Sie dazu jeweils den folgenden Befehl für die beiden Dateien aus:
    eseutil /mh database file | find /i "DB Signature"
    Hinweis: Exchange 2000 Service Pack 2 und höher meldet den Datenbankstatus nicht als "Konsistent" (Consistent) oder "Inkonsistent" (Inconsistent), sondern als "Ordnungsgemäß heruntergefahren" (Clean Shutdown) oder als "Nicht ordnungsgemäß heruntergefahren" (Dirty Shutdown). Die Bedeutung der Meldung "Ordnungsgemäßes Herunterfahren" entspricht der Angabe "Konsistent" und die Meldung "Nicht ordnungsgemäßes Herunterfahren" entspricht der Angabe "Inkonsistent". Führen Sie für Exchange 2000 Service Pack 2 oder höher diesen zusätzlichen Befehl aus, um den Status der einzelnen Datenbanken zu ermitteln:
    eseutil /mh database_name | find /i "Shutdown"
    Der folgende Text ist ein Beispiel für die Ausgabe des voranstehenden Befehls:
    D:\mdbdata>eseutil /mh priv.edb | find /i "DB Signature"     DB Signature: Create time:04/02/2001 16:59:32 Rand:2746771 Computer:
    
    
    D:\mdbdata>eseutil /mh priv.stm | find /i "DB Signature"
         DB Signature: Create time:04/02/2001 16:59:32 Rand:2746771 Computer:
    							
    Im voranstehenden Beispiel sind die Datenbanksignaturen identisch. Dies beweist, dass die EDB- und STM-Datei zum gleichen Datenbanksatz gehören. (Beide Signaturzeilen müssen vollständig, d.h. Zeichen für Zeichen, identisch sein, damit eine Signaturübereinstimmung vorliegt.)

    Es muss jedoch nicht nur eine Übereinstimmung der Datenbanksignaturen vorliegen, sondern die Dateien müssen auch miteinander synchronisiert und konsistent sein. Führen Sie folgenden Befehl für die einzelnen Dateien aus:
    eseutil /mh database file | find /i "consistent"
    Der folgende Text ist ein Beispiel für die Ausgabe des voranstehenden Befehls:
    D:\mdbdata>eseutil /mh priv.edb | find /i "consistent"             State: Consistent
    
       Last Consistent: (0x2CC7,1F14,1F7)  04/04/2001 18:07:14
    
    D:\mdbdata>eseutil /mh priv.stm | find /i "consistent"
                 State: Consistent
       Last Consistent: (0x2CC7,1F14,1F7)  00/00/1900 00:00:00
    							
    Im voranstehenden Beispiel wird für beide Dateien "State: Consistent" (Status: Konsistent) gemeldet. Die in Klammern stehenden Hexadezimalzahlen für die einzelnen Dateien (0x2CC7,1F14,1F7) müssen ebenfalls übereinstimmen. Der Zeitstempel "Last Consistent" (Zuletzt konsistent) muss nicht übereinstimmen. Diese Dateien sind nicht nur konsistent, sondern stimmen auch miteinander überein.

    Wenn für eine der Dateien "State: Inconsistent" (Status: Inkonsistent) gemeldet wird oder die Protokollpositionen für "Last Consistent" (Zuletzt konsistent) nicht synchronisiert sind, wurde die Bereitstellung der Datenbank nicht ordnungsgemäß aufgehoben. Stellen Sie die Datenbank bereit und heben Sie die Bereitstellung anschließend wieder auf. Wenn die Dateien weiterhin nicht ordnungsgemäß übereinstimmen oder inkonsistent sind, wenden Sie sich an Microsoft Product Support Services, um weitere Unterstützung zu erhalten.
  3. Kopieren Sie die EDB-Datenbankdateien und die entsprechenden STM-Streamingdatenbankdateien in ein Sicherungsverzeichnis.
  4. Stellen Sie die gesicherten Datenbanken bereit.
  5. Überspringen Sie diesen Schritt, falls die zirkuläre Protokollierung aktiviert ist. Wenn die zirkuläre Protokollierung deaktiviert ist und später ein Rollforward vorgenommen werden soll, müssen Sie eine Sicherungskopie von sämtlichen nummerierten Transaktionsprotokolldateien (E0nxxxxx.log-Dateien) erstellen. Sie müssen keine Sicherungskopie der Dateien "E0n.log", "Res1.log" und "Res2.log" erstellen.

    Sie können die nummerierten Protokolldateien jederzeit sichern, sogar unmittelbar nach der Erstellung, da Exchange keine Änderungen mehr vornimmt, nachdem eine Protokolldatei von "E0n.log" in "E0nxxxxx.log" umbenannt wurde. Löschen Sie gesicherte Protokolldateien jedoch nur gemäß den Anweisungen in Schritt 6.

    Die Sicherungskopien Ihrer Protokolldateien besitzen keine 1:1-Übereinstimmung mit Ihren Datenbanksicherungsdateien. Jede Protokolldateisicherung stellt eine Verknüpfung in einer Reihe von Protokolldateien dar, die in eine von mehreren Datenbanksicherungen zurückgespielt werden kann. Sie können ein Rollforward von einer bestimmten Datenbanksicherung durchführen, solange Sie über einen ununterbrochenen Protokollstream verfügen, der mit dem Protokoll beginnt, das in der Zeile "Last Consistent" des Datenbank-Headers aufgelistet ist. In diesem Artikel wird das letzte konsistente Protokoll auch als "Low Anchor-Protokoll" bezeichnet.

    Im voranstehenden Beispiel ist (0x2CC7,1F14,1F7) der letzte konsistente Eintrag. Die drei Zahlen stehen für eine Protokolldatei, eine Seite in dieser Datei und ein Byte-Offset in dieser Seite. Jede Protokolldatei enthält ungefähr 10.000 Seiten mit jeweils 512 Byte. Das Seiten-Offset vermittelt einen guten Eindruck davon, zu wieviel Prozent die Protokolldatei bereits belegt ist (die Protokolldatei im voranstehenden Beispiel ist etwa zu 80 Prozent voll, weil 0x1F14 der Dezimalzahl 7956 entspricht). Es ist jedoch für die Wiederherstellung irrelevant. Die Wiederherstellung beginnt stets am Anfang einer Protokolldatei.

    In diesem Beispiel ist "E0n02cc7.log" die Low Anchor-Protokolldatei.

    Möglicherweise wird nicht immer das letzte konsistente Protokoll auf der Festplatte als nummeriertes Protokoll angezeigt, weil das letzte konsistente Protokoll weiterhin mit "E0n.log" benannt ist. Sie werden feststellen, dass die Sequenznummer "E0n.log" schließlich erteilt wird, wenn Sie den Header der Protokolldatei überprüfen, während die Datenbank angehalten ist (der Zugriff auf den Header von "E0n.log" wird verweigert, während die Datenbank ausgeführt wird).

    Führen Sie den folgenden Befehl aus, um die interne Protokollerzeugungsnummer anzuzeigen:
    eseutil /ml [log file] | find /i "lGeneration"
    Der folgende Text ist ein Beispiel für die Ausgabe des voranstehenden Befehls:
    E:\mdbdata>eseutil /ml E00.log | find /i "lgeneration"
          lGeneration: 11463 (0x2CC7)
    							
    In vielen Fällen ist es wichtiger, dass die Protokolldateisicherungen ordnungsgemäß erfolgt sind, und weniger wichtig, dass die einzelnen Datenbanksicherungen ordnungsgemäß erfolgt sind. Dies ist darauf zurückzuführen, dass jede Datenbanksicherung Redundanz für die anderen Datenbanksicherungen gewährleistet, eine vollständige Wiederherstellung aus einer Datenbanksicherung jedoch vom ordnungsgemäßen Zustand der einzelnen Protokolldateien nach dieser Sicherung abhängt.
  6. Überspringen Sie diesen Schritt, falls die zirkuläre Protokollierung aktiviert ist. Überprüfen Sie den Header der Prüfpunktdatei, um die Protokolldatei mit der höchsten Nummerierung zu ermitteln, die sicher entfernt werden kann. Die Prüfpunktdatei zeichnet die Protokolldatei mit der niedrigsten Nummerierung auf, die für die automatische Wiederherstellung erforderlich ist, wenn die Datenbank nicht normal angehalten wird. Führen Sie den folgenden Befehl aus, um die Prüfpunktdatei anzuzeigen:
    eseutil /mk E0n.chk
    Der folgende Text ist ein Beispiel für die Ausgabe des voranstehenden Befehls:
    D:\exchsrvr\mdbdata>eseutil /mk e00.chk | find /i "checkpoint"
          Checkpoint file: e00.chk
          LastFullBackupCheckpoint: (0x0,0,0)
          Checkpoint: (0x2CC7,9607,256)
    							
    Die dritte Zeile, die Prüfpunktzeile, enthält die relevanten Informationen. (Der Eintrag "LastFullBackupCheckpoint" wird von der Onlinesicherung verwendet. Wenn noch keine Onlinesicherung für die Datenbank durchgeführt wurde, erscheinen für den Eintrag weiterhin Nullen.) Die Protokollposition des Prüfpunktes ist wie der letzte konsistente Eintrag im Datenbank-Header formatiert. In diesem Beispiel befindet sich der Prüfpunkt in der Protokolldatei "E0002cc7.log".

    Wenn die zirkuläre Protokollierung deaktiviert ist, sammeln sich die Protokolldateien an, bis sie entweder manuell gelöscht oder automatisch vom Onlinesicherungsprozess entfernt werden. Ist die zirkuläre Protokollierung aktiviert, ist keine geesonderte Verwaltung der älteren Protokolldateien erforderlich, weil der Datenbankdienst ältere Protokolldateien automatisch löscht, nachdem der Prüfpunkt sie durchlaufen hat.

    Wenn Sie alle nummerierten Protokolldateien gesichert haben, können Sie wieder Festplattenspeicherplatz freigeben, indem Sie alle nummerierten Protokolldateien bis zum Prüfpunktprotokoll, jedoch ausschließlich dieser Datei, entfernen.

    Wichtig: Entfernen Sie keinesfalls das Prüfpunktprotokoll.

    In diesem Beispiel können Sie alle Protokolle bis zur Protokolldatei "E0002cc6.log" entfernen.
  7. Dieser Schritt ist optional. Sie können mithilfe des Dienstprogramms "Esefile" die Integrität der kopierten Datenbank auf Seitenebene überprüfen.

    Die Datei "Esefile.exe" steht im Ordner "Support" auf der Exchange Server 5.5 Service Pack 3-CD, der Exchange Server 2000-Installations-CD oder der Exchange Server 2003-Installations-CD zur Verfügung. Sie erhalten die Datei "Esefile.exe" auch bei Microsoft Product Support Services. Das Dienstprogramm "Esefile" kann für EDB-Dateien von Exchange Server 5.0 und 5.5 sowie Exchange 2000 und Exchange 2003 verwendet werden.

    Es existiert derzeit kein anderes Verfahren als die Onlinesicherung, um die Prüfsummen für jede Seite einer STM-Datei zu überprüfen. Die STM-Datei enthält unaufbereitete Daten. Alle Indizes und Zeiger, die diese Daten strukturieren, befinden sich in der EDB-Datei. Ein Problem in der STM-Datei verursacht einen geringen Client-Datenverlust, betrifft jedoch nicht die strukturelle oder logische Integrität der Datenbank als Ganzes.

    Führen Sie folgenden Befehl des Dienstprogramms "Esefile" aus, um die Seitenprüfsummen für eine Exchange-Datenbank zu überprüfen:
    esefile /s Datenbankname
    Der folgende Text ist ein Beispiel für die Ausgabe des voranstehenden Befehls:
    E:\mdbdata>esefile /s priv.edb
    
    Checksumming
    0    10   20   30   40   50   60   70   80   90  100
    |----|----|----|----|----|----|----|----|----|----|
    ...................................................
    
    23042 pages seen
    0 bad checksums
    241 uninitialized pages
    0 wrong page numbers
    
    esefile completes successfully after 10 seconds
    							
    Nicht initialisierte Seiten sind akzeptabel. In einer Datenbank ohne Probleme gibt es 0 fehlerhafte Prüfsummen und 0 falsche Seitennummern.

    Wenn eine Datenbank die Integritätsprüfung des Dienstprogramms "Esefile" nicht besteht, ist es am günstigsten, eine frühere, fehlerfreie Sicherung wiederherzustellen und ein Rollforward auszuführen. Falls eine solche Sicherung nicht verfügbar ist, wenden Sie sich an Microsoft Product Support Services, um Informationen darüber zu erhalten, wie Sie die Datenbank reparieren oder retten können.
  8. Dieser Schritt ist optional. Verwenden Sie den folgenden Befehl, um die Integrität von gesicherten Protokolldateien zu überprüfen:
    eseutil /ml E0n
    Der folgende Text ist ein Beispiel für die Ausgabe des voranstehenden Befehls:
    k:\backups>eseutil /ml E00
    							
    Sie müssen diesen Befehl in einem Ordner ausführen, der die gesicherten Protokolldateien enthält. Sie können diesen Befehl auch für den aktuell ausgeführten Protokollordner ausführen. Wenn das Dienstprogramm "Eseutil" jedoch versucht, den Header der Datei "E0n.log" zu lesen, während die Datenbank in der Speichergruppe ausgeführt wird, erscheint die Fehlermeldung "-1032" (JET_errFileAccessDenied).

    Dieser Befehl erkennt Fehler in den Protokolldateien und gibt eine Warnung aus, wenn eine Protokolldatei in einer Sequenz fehlt, oder wenn ein Signaturkonflikt zwischen den Protokolldateien vorliegt.
Zurück zum Überblick

Wiederherstellen der Offlinesicherung einer Exchange-Datenbank

In diesem Abschnitt werden zwei Verfahren zur Wiederherstellung einer Offlinesicherung beschrieben:
  • Wiederherstellung auf den Zustand zu einem bestimmten Zeitpunkt. Es werden keine Protokolldateien in die Datenbank zurückgespielt. Alle nach der Sicherung erstellten Daten gehen verloren.
  • "Rollforward"-Wiederherstellung. Die nach der Sicherung erstellten Protokolldateien werden in die Datenbank zurückgespielt. Wenn alle Protokolldateien verfügbar sind, können alle nach der Sicherung erstellten Daten erhalten werden. Wenn die zirkuläre Protokollierung aktiviert ist, müssen Sie eine Wiederherstellung auf einen bestimmten Zustand für Ihre Offlinesicherung ausführen. Sie können keine "Rollforward"-Wiederherstellung wählen.
Der von Ihnen wiederhergestellte Dateisatz muss folgende Mindestvoraussetzungen erfüllen:
  • Bei Wiederherstellungen auf einen bestimmten Zustand müssen alle angehaltenen Datenbanken der Speichergruppe konsistent sein. Außerdem muss eine gültige Prüfpunktdatei vorhanden sein. Löschen Sie keinesfalls die aktuelle Prüfpunktdatei oder die vorhandenen Protokolldateien.
  • Bei Rollforward-Wiederherstellungen müssen alle Datenbanken der Speichergruppen angehalten werden und konsistent sein. Außerdem müssen alle nach dem Zeitpunkt der Sicherung erstellten Protokolldateien vorhanden sein (einschließlich der aktuellen Datei "E0n.log"). Die Prüfpunktdatei muss gelöscht werden.
Wenn der Dateisatz die voranstehenden Bedingungen nicht erfüllt, schlagen die Wiederherstellung und das Zurückspielen zwar nicht fehl, jedoch wird während des Soft Recovery-Prozesses die Fehlermeldung "-1216 (JET_errAttachedDatabaseMismatch)" angezeigt.

Zurück zum Überblick

Umgang mit Fehler 1216

Zusätzliche Soft Recovery-Sicherheitsfunktionen in Exchange 2000 (und höher) verursachen die Fehlermeldung "-1216", wenn Exchange manuell veränderte Datendateien erkennt, und bestimmt, dass eine Wiederherstellung mit dem aktuellen Datensatz zum Verlust von zuvor vorhandenen Daten führen würde.

In früheren Exchange-Versionen startet der Soft Recovery-Vorgang ohne Warnung an den Administrator, wenn der Dateisatz zwar unvollständig, aber gültig für ein erfolgreiches Zurückspielen ist. In Exchange 2000 (und höher) muss der Administrator die Fehlermeldung "-1216" mithilfe von Eseutil übergehen. Zurück zum Überblick

Wiederherstellung einer Offlinesicherung auf den Zustand zu einem bestimmten Zeitpunkt

Gehen Sie folgendermaßen vor, um eine Offlinesicherung auf den Zustand zu einem bestimmten Zeitpunkt wiederherzustellen:
  1. Heben Sie die Bereitstellung auf, wenn die Datenbank, die Sie wiederherstellen möchten, derzeit bereitgestellt ist. Wenn die Bereitstellung weiterer Datenbanken in der Speichergruppe aufgehoben wurde, müssen die Datenbank- und Streamingdateien (EDB- und STM-Dateien) dieser Datenbanken konsistent sein und übereinstimmen. (Zum Überprüfen von Konsistenz und Übereinstimmung, siehe Schritt 2 im Abschnitt "Offlinesicherung einer Exchange-Datenbank" dieses Artikels.)

    Wenn die Bereitstellung aller Datenbanken in der Speichergruppe aufgehoben ist, müssen alle Datenbanken konsistent sein, und es muss eine gültige Prüfpunktdatei existieren. Eine gültige Prüfpunktdatei ist eine Prüfpunktdatei, die in Verwendung war, als eine der Datenbanken in der Speichergruppe, die einen Header mit dem Prüfpunkt "E0n.log" enthält, zuletzt ausgeführt wurde. Wenn noch eine der Datenbanken in der Speichergruppe bereitgestellt ist, ist die gültige Prüfpunktdatei die Prüfpunktdatei, die derzeit vom System verwendet wird. Wenn noch eine Datenbank in der Speichergruppe ausgeführt wird, existiert auch eine gültige Prüfpunktdatei.

    Führen Sie die folgenden Befehle aus, um die Prüfpunktdatei zu überprüfen, wenn alle Datenbanken angehalten sind:
    eseutil /mk E0n.chk | FIND /i "checkpoint"
    eseutil /ml E0n.log | FIND /i "lgeneration"
    Der folgende Text ist ein Beispiel für die Ausgabe der voranstehenden Befehle:
    D:\mdbdata>eseutil /mk e00.chk | find /i "checkpoint"
          Checkpoint file: e00.chk
          LastFullBackupCheckpoint: (0x0,0,0)
          Checkpoint: (0x2cc7,1B59,1A)
    
    D:\mdbdata>eseutil /ml e00.log |find /i "lgeneration"
          lGeneration: 11463 (0x2cc7)
    							
    Im voranstehenden Beispiel befindet sich der Prüfpunkt in dem Protokoll mit der Erstellungsnummer (lGeneration) 0x2cc7, d.h. im Protokoll "e00.log". Daher kann der Prüfpunkt als gültig betrachtet werden.

    Wenn der Prüfpunkt ungültig ist, wird bei dem Versuch, eine der Datenbanken in der Speichergruppe bereitzustellen, möglicherweise die Fehlermeldung "-1216" (JET_errAttachedDatabaseMismatch) angezeigt. Dieses Problem kann auch dann auftreten, wenn alle Datenbanken in der Speichergruppe konsistent sind.
  2. Kopieren Sie die gesicherten EDB- und STM-Dateien in die entsprechenden Datenbank- und Streamingdateipfade. (Den Verzeichnispfad dieser Dateien finden Sie in diesem Artikel im Abschnitt "Voraussetzungen".) Stellen Sie sicher, dass die wiederhergestellten Dateien konsistent sind und übereinstimmen.

    Hinweis: Wenn bereits Kopien der wiederherzustellenden Datenbankdateien auf dem Server vorhanden sind, müssen Sie diese Dateien vor dem Wiederherstellen der Datenbank sichern. Dies gilt auch dann, wenn die vorhandenen Dateien nicht startfähig sind. Sie können möglicherweise repariert werden, und Sie können die enthaltenen Daten eventuell mithilfe des Dienstprogramms "Exmerge" retten.
  3. Stellen Sie die wiederhergestellte Datenbank bereit. Die Datenbank wird an das Ende der Datei "E0n.log" angehängt. Nachdem die Datenbank erfolgreich gestartet wurde, können keine zuvor vorhandenen Protokolldateien mehr in die Datenbank zurückgespielt werden. Öffentliche Ordner-Datenbanken, die tausende Ordner in der Hierarchie enthalten, benötigen möglicherweise eine längere Zeit zum Starten. Sie müssen mit mindestens einer Minute pro 1000 Ordner in der Hierarchie rechnen.

    In früheren Versionen von Exchange Server musste in der Regel der Befehl ISINTEG -patch ausgeführt werden, nachdem eine Offlinesicherung einer Informationsspeicher-Datenbank wiederhergestellt wurde, um den Informationsspeicher mit dem Verzeichnis zu synchronisieren. Wenn eine Exchange-Datenbank gepatcht werden muss, wird dieser Vorgang automatisch vom System ausgeführt, sofern die Datenbank nicht auf einem anderen Server, in einer anderen Speichergruppe oder in einem anderen logischen Datenbankobjekt wiederhergestellt wurde, oder das Active Directory-Objekt für die Datenbank nicht gelöscht und erneut im Active Directory erstellt wurde. In diesen Fällen wird die folgende Fehlermeldung im Ereignisprotokoll für Anwendungen eingetragen.
    Ereignistyp: Error (Fehler)
    Quelle: MSExchangeIS Mailbox Store
    Kategorie: Allgemein
    Ereignis-ID: 1087
    Datum: 5/4/2001
    Uhrzeit: 8:33:42 PM
    Benutzer: Nicht zutreffend
    Computer: EXCHANGE1
    Beschreibung: Der Informationsspeicher wurde aus einer Offlinesicherung wiederhergestellt. Zeigen Sie im Microsoft Exchange-System-Manager an, dass die Wiederherstellung in Datenbank "Erste Speichergruppe\Privater Informationsspeicher" zulässig ist, damit das Patch angewendet werden kann.
    Um dieses Problem zu beheben, müssen Sie in den Datenbankeigenschaften des Datenbankobjekts im Exchange System-Manager das Kontrollkästchen Diese Datenbank kann bei einer Wiederherstellung überschrieben werden aktivieren, indem Sie darauf klicken.
Zurück zum Überblick

Rollforward-Wiederherstellung einer Offlinesicherung

Beachten Sie Folgendes, um die Protokolldateien erfolgreich in eine wiederhergestellte Datenbank zurückzuspielen:
  • Bewahren Sie eine Kopie aller Transaktionsprotokolle auf, die nach dem Zeitpunkt der ältesten vollständigen Sicherung erstellt wurden.
  • Ändern Sie den Datenbankpfad nicht, ohne unmittelbar anschließend eine neue vollständige Sicherung zu erstellen.
  • Führen Sie das Dienstprogramm ESEUTIL /p bzw. ESEUTIL /d nicht aus, ohne unmittelbar anschließend eine neue vollständige Sicherung zu erstellen.
  • Fügen Sie keine Datenbank zu einer Speichergruppe hinzu oder entfernen Sie sie nicht, ohne unmittelbar anschließend eine vollständige Sicherung aller Datenbanken in der Speichergruppe zu erstellen.
Gehen Sie folgendermaßen vor, um den Wiederherstellungsvorgang zu starten:
  1. Heben Sie die Bereitstellung auf, wenn die Datenbank, die Sie wiederherstellen möchten, noch bereitgestellt ist. Kopieren Sie anschließend die wiederherzustellenden Datenbankdateien in die entsprechenden Pfade auf dem Server. Wenn bereits Kopien der wiederherzustellenden Datenbankdateien auf dem Server vorhanden sind, müssen Sie diese Dateien vor dem Wiederherstellen der Datenbank sichern. Dies gilt auch dann, wenn die vorhandenen Dateien nicht startfähig sind. Sie können möglicherweise repariert werden, und Sie können die enthaltenen Daten eventuell mithilfe des Dienstprogramms "Exmerge" retten.
  2. Heben Sie die Bereitstellung aller Datenbanken in der Speichergruppe auf, und führen Sie anschließend den folgenden Befehl für jede Datenbank in der aktuellen Speichergruppe sowie für jede wiederhergestellte Datenbankdatei aus:
    eseutil /mh Datenbank-Dateiname | find /i "consistent"
    Hinweis: Exchange 2000 Service Pack 2 und höher meldet den Datenbankstatus nicht als "Konsistent" (Consistent) oder "Inkonsistent" (Inconsistent), sondern als "Ordnungsgemäßes Herunterfahren" (Clean Shutdown) oder als "Nicht ordnungsgemäßes Herunterfahren" (Dirty Shutdown). Die Bedeutung der Meldung "Ordnungsgemäßes Herunterfahren" entspricht der Angabe "Konsistent" und die Meldung "Nicht ordnungsgemäßes Herunterfahren" entspricht der Angabe "Inkonsistent". Führen Sie für Exchange 2000 Service Pack 2 oder höher diesen zusätzlichen Befehl aus, um den Status der einzelnen Datenbanken zu ermitteln:
    eseutil /mh database_name | find /i "Shutdown"
    Der folgende Text ist ein Beispiel für die Ausgabe des voranstehenden Befehls:
    D:\mdbdata>eseutil /mh PRIV.EDB   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2692,1ED)  04/12/2001 20:07:46
    
    
    I:\mdbdata<eseutil /mh PRIV.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2692,1ED)  00/00/1900 00:00:00
    
    E:\mdbdata>eseutil /mh PRIV2.edb   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2685,171)  04/12/2001 20:07:41
    
    J:\mdbdata>eseutil /mh PRIV2.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2685,171)  00/00/1900 00:00:00
    
    F:\mdbdata>eseutil /mh PRIV3.edb   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2ac8,87,1FC)  04/12/2001 20:05:04
    
    K:\mdbdata>eseutil /mh PRIV3.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2ac8,87,1FC)  00/00/1900 00:00:00
    
    G:\mdbdata>eseutil /mh PRIV4.edb   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,268C,19B)  04/12/2001 20:07:43
    
    L:\mdbdata>eseutil /mh PRIV4.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,268C,19B)  00/00/1900 00:00:00
    
    H:\mdbdata>eseutil /mh PUB.EDB   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2699,181)  04/12/2001 20:07:46
    
    M:\mdbdata>eseutil /mh PUB.stm   | find /i "consistent"
                State: Consistent
      Last Consistent: (0x2cc7,2699,181)  00/00/1900 00:00:00
    							
    Dieser Befehl hat drei Ziele:
    • Überprüfen, ob die Datenbankdateien konsistent sind.
    • Überprüfen, ob die EDB- und STM-Dateien für die einzelnen Datenbanken übereinstimmende Paare sind.
    • Ermitteln der Low Anchor- und High Anchor-Protokolldateien, d.h. der ersten und letzten Protokolldatei, die für die erfolgreiche Wiederherstellung aller Daten ohne Auftreten der Fehlermeldung "-1216" erforderlich ist. Der niedrigste, zuletzt konsistente Wert aller Datenbanken ist das Low Anchor-Protokoll und der höchste, zuletzt konsistente Wert ist das High Anchor-Protokoll.
    Im voranstehenden Beispiel ist "E0002ac8.log" die Low Anchor-Protokolldatei und "E0002cc7.log" die High Anchor-Datei.
  3. Vergewissern Sie sich, ob die Protokollsignatur, die im Header der Datenbanken erscheint, die Signatur des Low Anchor-Protokolls ist. Führen Sie die folgenden Befehle aus:
    eseutil /mh database_name | find /i "Log Signature"
    eseutil /ml low_anchor_log | find /i "Signature"
    Der folgende Text ist ein Beispiel für die Ausgabe des voranstehenden Befehls:
    D:\mdbdata>eseutil /mh priv.edb | find /i "Log Signature"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    E:\mdbdata>eseutil /mh PRIV2.edb   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    F:\mdbdata>eseutil /mh PRIV3.edb   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    G:\mdbdata>eseutil /mh PRIV4.edb   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    H:\mdbdata>eseutil /mh PUB.EDB   | find /i "consistent"
        Log Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
    
    
    D:\exchsrvr\mdbdata\save>eseutil /ml e0002ac8.log | find /i "Signature"
          Signature: Create time:12/29/2000 21:6:38 Rand:24842 Computer:
          Signature: Create time:12/29/2000 21:6:40 Rand:67798 Computer:
          Signature: Create time:12/29/2000 21:6:41 Rand:58314 Computer:
    							
    Eine Protokolldatei listet eventuell mehrere Signaturen auf. Die erste Signatur ist immer die Signatur der Protokolldatei. Bei den restlichen Signaturen handelt es sich um Signaturen für Datenbanken, die zum Zeitpunkt der Erstellung der Datenbank ausgeführt wurden. Im voranstehenden Beispiel stimmen die in den Datenbankdateien aufgezeichneten Protokollsignaturen mit der Protokollsignatur im Low Anchor-Protokoll überein.

    Wenn Sie das Low Anchor-Protokoll nicht finden können, sind Sie nicht in der Lage, Protokolle in diese Datenbank zu spielen. Wenn Sie die Low Anchor-Protokolldatei nicht finden können, sind Sie nicht in der Lage, Protokolldateien in die Datenbanken zu spielen. Es gibt zwei Verfahren, die Sie bei einem fehlenden Low Anchor-Protokoll verwenden können:
    • Sie können alle Protokolldateien entfernen. Weil die Datenbanken konsistent sind, können Sie sie ohne Protokolldateien starten. Sie können jedoch keine Daten wiederherstellen, die noch nicht in den Datenbankdateien enthalten sind.
    • Sie können die Datenbanken mit den niedrigsten, zuletzt konsistenten Werten entfernen, bis Sie eine ununterbrochene Protokollsequenz von Low Anchor-Protokollen bis zu High Anchor-Protokollen erstellen können. Führen Sie anschließend die Wiederherstellung für die verbleibenden Datenbanken aus. Wenn Sie die entfernten Datenbanken wieder in die Speichergruppe einfügen, können Sie keine zusätzlichen Daten mehr in die Datenbanken zurückspielen.
  4. Stellen Sie sicher, dass die aktuellen Datenbankpfade identisch mit den Pfaden zum Zeitpunkt der Sicherung sind.

    Sie können den Pfad des Transaktionsprotokolls bzw. den Arbeitspfad zwar nach dem Erstellen einer Sicherung ändern, jedoch können Sie die Protokolldatei nur zurückspielen, wenn die Datenbankdateien sich im selben Pfad befinden, in dem sie auch gesichert wurden. Führen Sie den folgenden Befehl aus, wenn Sie sich über den ursprünglichen Verzeichnispfad nicht sicher sind:
    eseutil /ml "Last_Consistent"_log | find /i "database name or pattern"
    Der folgende Text ist ein Beispiel für die Ausgabe des voranstehenden Befehls:
    N:\mdbdata>eseutil /ml e0002cc7.log |find /i ".edb"
          1 f:\MDBDATA\PRIV3.edb
          2 g:\MDBDATA\PRIV4.edb
          3 d:\MDBDATA\PRIV.EDB
          4 e:\MDBDATA\PRIV2.edb
          5 h:\MDBDATA\PUB.EDB
    
    d:\mdbdata>eseutil /ml e0002cc7.log |find /i ".stm"
            streaming file: k:\MDBDATA\PRIV3.stm
            streaming file: l:\MDBDATA\PRIV4.stm
            streaming file: i:\MDBDATA\PRIV.stm
            streaming file: j:\MDBDATA\PRIV2.stm
            streaming file: m:\MDBDATA\PUB.stm
    							
    Hinweis: Wenn "E0n00001.log" das Low Anchor-Protokoll ist, enthält es keine Pfadinformationen im Header, weil der Header des ersten Protokolls einer Sequenz generiert wird, bevor die erste Datenbank an das Protokoll angehängt wird. In diesem Fall müssen Sie den Header des nächsten Protokolls anzeigen, um den Datenbankpfad zu ermitteln. In seltenen Fällen gilt dies eventuell auch für Protokolle nach dem ersten Protokoll, weil eine Datenbank nach der Erstellung des Protokolls erstellt oder an den Protokollstream angehängt wurde.
  5. Sammeln Sie sämtliche Protokolle, beginnend mit dem Low Anchor-Protokoll, so weit wie möglich in ununterbrochener Reihenfolge, und kopieren Sie diese Protokolle in den Pfad der aktuellen Transaktionsprotokolle. Überschreiben Sie keinesfalls Protokolle, die bereits auf dem Server vorhanden sind, ohne diese Protokolle zuerst zu sichern. Dazu müssen Sie möglicherweise Protokolldateien aus mehreren Typen von Sicherungsmedien wiederherstellen.

    Im voranstehenden Beispiel ist "E0002ac8.log" die Low Anchor-Protokolldatei und "E0002cc7.log" die High Anchor-Datei. Wenn Sie die verfügbaren Protokolle überprüfen, befindet sich das Protokoll mit der höchsten Nummerierung möglicherweise eine Nummer unter der erforderlichen Nummer (z.B. "E0002cc6.log" anstatt "2cc7"). Dieses Problem tritt in der Regel auf, weil das Protokoll "E0n.log" noch nicht in die Sequenz eingetragen und in die entsprechende Nummer umbenannt wurde. Um festzustellen, ob "E0n.log" tatsächlich das High Anchor-Protokoll ist, müssen Sie mithilfe des folgenden Befehls den Wert lGeneration im Protokolldatei-Header überprüfen:
    eseutil /ml E0n.log | find /i "lGeneration"
    Der folgende Text ist ein Beispiel für die Ausgabe des voranstehenden Befehls:
    N:\mdbdata>eseutil /ml e00.log |find /i "lGeneration"
          lGeneration: 11463 (0x2cc7)
    							
    Hinweis: Verwenden Sie den Parameter /ml, um den Header einer Protokolldatei mit dem Dienstprogramm "Eseutil" anzuzeigen. Zum Anzeigen eines Datenbankdatei-Headers verwenden Sie den Parameter /mh. Wenn Sie die Parameter verwechseln, ist die Ausgabe der Befehle inkorrekt.

    In der Regel ist das High Anchor-Protokoll auch das höchste verfügbare Protokoll. Dies gilt jedoch nicht in den folgenden Fällen:
    • Wenn die Protokolldateien bei einem Ausfall zerstört wurden.

      -oder-
    • Wenn Sie gleichzeitig alle Datenbanken in einer Speichergruppe wiederherstellen.
    Im ersten Fall werden wahrscheinlich "-1216"-Fehlermeldungen bei der Wiederherstellung angezeigt. Im zweiten Fall können Sie die Protokolldateien sogar über das High Anchor-Protokoll hinaus zurückspielen, solange die "lGeneration"-Sequenz eingehalten wird.
  6. Vergewissern Sie sich, ob alle Protokolle die gleiche Protokollsignatur besitzen und in ununterbrochener Reihenfolge vorliegen. Führen Sie den folgenden Befehl aus:
    eseutil /ml E0n > filename.txt
    Der folgende Text ist ein Beispiel für die Ausgabe des voranstehenden Befehls:
    d:\mdbdata>eseutil /ml E00 > logverify.txt
    
    d:\mdbdata>type logverify.txt
    
    Microsoft(R) Exchange Server(TM) Database Utilities
    Version 6.0
    Copyright (C) Microsoft Corporation 1991-2000.  All Rights Reserved.
    
    Initiating FILE DUMP mode...
    
    Verifying log files...
          Base name: e00
    
          Log file: D:\exchsrvr\mdbdata\save1\E0000001.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000002.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000003.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000004.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000005.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000006.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000007.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000008.log
          Log file: D:\exchsrvr\mdbdata\save1\E0000009.log
          Log file: D:\exchsrvr\mdbdata\save1\E000000A.log
          Log file: D:\exchsrvr\mdbdata\save1\E000000B.log
          Log file: D:\exchsrvr\mdbdata\save1\E00.log
    
    No damaged log files were found.
    
    Operation completed successfully in 3.305 seconds.
    							
    Dieser Eseutil-Befehl führt drei Vorgänge aus: Prüfen jeder Protokolldatei auf Fehler, Melden von Lücken in der Protokolldateisequenz und Erkennen von Protokollsignaturkonflikten.

    Alle Protokollsignaturen müssen bei sämtlichen Protokolldateien übereinstimmen, die zurückgespielt werden sollen. Sie müssen alle Protokolle vor dem Zurückspielen entfernen, die keine übereinstimmenden Signaturen besitzen.

    Nachdem Sie die Dateien entfernt haben, die die Überprüfung nicht bestanden haben, sind nur noch Transaktionsprotokolldateien im Ordner für Transaktionsprotokolle vorhanden, welche folgende Bedingungen erfüllen:
    • Sie liegen in ununterbrochener "lGeneration"-Sequenz vor, beginnend mit der Low Anchor-Protokolldatei und fortlaufend bis zur High Anchor-Protokolldatei sowie darüber hinaus (sofern möglich).
    • Sie weisen übereinstimmende Protokollsignaturen auf.
  7. Wenn das High Anchor-Protokoll noch nicht in "E0n.log" umbenannt wurde, dann benennen Sie es jetzt um.
  8. Entfernen Sie die Datei "E0n.chk" aus dem Systempfad-Ordner.

    Bei Fehlen einer Prüfpunktdatei fängt Exchange Server mit dem Zurückspielen der Protokolle an, beginnend mit der Protokolldatei mit der niedrigsten Nummer im Ordner für Transaktionsprotokolle: dem Low Anchor-Protokoll. Wenn die Datei "E0n.chk" vorhanden ist, beginnt Exchange Server an dem Prüfpunkt, der in dieser Datei aufgezeichnet ist, mit dem Zurückspielen. Wenn die Datei "E0n.chk" auf einen Zeitpunkt nach dem Low Anchor-Protokoll verweist, schlägt das Zurückspielen für den wiederhergestellten Dateisatz fehl. Wenn Sie einen Fehler mit der Prüfpunktdatei machen, müssen Sie in vielen Fällen die Wiederherstellung der Datenbankdateien aus der Sicherung erneut starten.
  9. Bevor Sie die Speichergruppe bereitstellen, sollten Sie abschließend Folgendes überprüfen:
    • Sind alle Datenbankdateien in ihren Ausführungspfaden vorhanden?
    • Die einzigen Protokolldateien im laufenden Transaktionsprotokollpfad sind die Dateien, die mit dem Low Anchor-Protokoll beginnen und mindestens bis zum High Anchor-Protokoll reichen, wobei "E0n.log" das höchste verfügbare Protokoll ist.
    • Es existiert keine "E0n.chk"-Datei im Systempfad-Ordner.
    Sie sind nun in der Lage, die Speichergruppe erfolgreich bereitzustellen und bei diesem Dateisatz mit dem Zurückspielen der Transaktionsprotokolle zu beginnen. Nach Abschluss der Wiederherstellung und dem Starten der Datenbank sind möglicherweise nicht alle Daten in den Protokolldateien wiederhergestellt. Dies ist auf Datenbanksignatur- und Pfadprobleme zurückzuführen, die beim Zurückspielen aufgetreten sind. Im Abschnitt "Umgang mit Datenbanksignatur- und Pfadkonflikten" dieses Artikels finden Sie zusätzliche Informationen zu diesen Problemen.
  10. Falls der Informationsspeicher noch nicht ausgeführt wird, starten Sie ihn, und stellen Sie anschließend mindestens eine Datenbank in der Speichergruppe bereit. Dies veranlasst, dass der Soft Recovery-Vorgang für alle Datenbanken in der Speichergruppe ausgeführt wird.

    In früheren Versionen von Exchange Server musste in der Regel der Befehl ISINTEG -patch ausgeführt werden, nachdem eine Offlinesicherung einer Informationsspeicher-Datenbank wiederhergestellt wurde, um die Datenbank mit dem Verzeichnis zu synchronisieren. Wenn eine Exchange-Datenbank gepatcht werden muss, wird dieser Vorgang automatisch vom System ausgeführt, sofern die Datenbank nicht auf einem anderen Server, in einer anderen Speichergruppe oder in einem anderen logischen Datenbankobjekt wiederhergestellt wurde, oder das Active Directory-Objekt für die Datenbank nicht gelöscht und erneut im Active Directory erstellt wurde. In diesen Fällen wird die folgende Fehlermeldung im Ereignisprotokoll für Anwendungen eingetragen.
    Ereignistyp: Error (Fehler)
    Quelle: MSExchangeIS Mailbox Store
    Kategorie: Allgemein
    Ereignis-ID: 1087
    Datum: 5/4/2001
    Uhrzeit: 8:33:42 PM
    Benutzer: Nicht zutreffend
    Computer: EXCHANGE1
    Beschreibung: Der Informationsspeicher wurde aus einer Offlinesicherung wiederhergestellt. Zeigen Sie im Microsoft Exchange-System-Manager an, dass die Wiederherstellung in Datenbank "Erste Speichergruppe\Privater Informationsspeicher" zulässig ist, damit das Patch angewendet werden kann.
    Um dieses Problem zu beheben, müssen Sie in den Datenbankeigenschaften des Datenbankobjekts im Exchange System-Manager das Kontrollkästchen Diese Datenbank kann bei einer Wiederherstellung überschrieben werden aktivieren, indem Sie darauf klicken.
Prüfen Sie das Ereignisprotokoll für Anwendungen in der Microsoft Windows NT-Ereignisanzeige auf Fehler oder Anomalien, die eventuell beim Starten der Datenbank auftreten können. Für jede zurückgespielte Protokolldatei wird das Ereignis 301 angezeigt. Achten Sie sorgfältig auf Fehler und Warnungen während des Wiederherstellungsvorgangs.

Zurück zum Überblick

Umgang mit Datenbanksignatur- und Pfadkonflikten

Datenbanken haben, ähnlich wie Protokolldateien, eigene Signaturen. Die Protokollsignaturen ändern sich nach dem Zeitpunkt der Erstellung der Protokolldatei "E0n000001.log" nicht mehr. Datenbanksignaturen ändern sich jedoch, wenn die physische Topologie der Datenbank verändert wird, ohne dass die Änderungen in den Protokolldateien aufgezeichnet werden. Durch die Offlinedefragmentierung oder -reparatur einer Datenbank mit "Eseutil" wird die Datenbanksignatur geändert. Nach einem solchen Ereignis kann die Datenbank zwar an den gleichen Protokollstream wie zuvor angehängt werden, jedoch akzeptiert die Datenbank keine Zurückspielung von Transaktionen, die ausgeführt wurden, während die Datenbank die vorherige Signatur besaß. Eine frühere Kopie der Datenbank akzeptiert keine Zurückspielung von Transaktionen, die nach dem Ändern der Datenbanksignatur ausgeführt wurden.

Da die Datenbanksignaturen auf diese Weise zurückgesetzt werden, wird eindringlich empfohlen, unverzüglich eine vollständige Sicherung der Datenbank durchzuführen, nachdem eine Offlinedefragmentierung oder -reparatur der Datenbank vorgenommen wurde. Wenn Sie zu einem späteren Zeitpunkt eine Kopie der Datenbank mit der alten Signatur wiederherstellen, erfolgt das Zurückspielen bis zum Zeitpunkt der Signaturänderungen. Alle Änderungen nach diesem Zeitpunkt gehen jedoch verloren.

Wenn die Datenbankpfade inmitten eines Protokollstreams geändert werden, ähnelt der Effekt der Wirkung einer Signaturänderung: die Zurückspielung wird am Zeitpunkt der Änderung unterbrochen. (Die Online-Sicherungs-API umfasst eine Funktion, mit deren Hilfe die Pfade bei der Wiederherstellung erneut zugeordnet werden können. Daher kann die Online-Sicherungs-API die Protokolle vollständig zurückspielen, selbst wenn sich seit der Erstellung der Sicherung ein Pfad geändert hat.)

Wenn beim Zurückspielen Datenbanksignatur- oder Datenbankpfadprobleme festgestellt werden, werden diese Probleme zusammen mit den 301-Ereignissen für jede Protokolldatei im Ereignisprotokoll für Anwendungen aufgezeichnet. Protokolldateien, die nach dem Auftreten des Problems erstellt wurden, werden scheinbar erfolgreich zurückgespielt. Dies ist jedoch darauf zurückzuführen, dass identische Konfliktwarnungen nicht wiederholt protokolliert werden. Im Allgemeinen wird die Zurückspielung in eine bestimmte Datenbank an dem Punkt abgeschnitten, an dem der erste Datenbanksignatur- oder Pfadfehler festgestellt wird, der auf diese Datenbank verweist.

Zurück zum Überblick

Eigenschaften

Artikel-ID: 296788 - Geändert am: Montag, 3. Dezember 2007 - Version: 4.3
Die Informationen in diesem Artikel beziehen sich auf:
  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Exchange 2000 Server Standard Edition
  • Microsoft Windows Small Business Server 2003 Premium Edition
  • Microsoft Windows Small Business Server 2003 Standard Edition
Keywords: 
kberrmsg kbhowto kbproductlink KB296788
Microsoft stellt Ihnen die in der Knowledge Base angebotenen Artikel und Informationen als Service-Leistung zur Verfügung. Microsoft übernimmt keinerlei Gewährleistung dafür, dass die angebotenen Artikel und Informationen auch in Ihrer Einsatzumgebung die erwünschten Ergebnisse erzielen. Die Entscheidung darüber, ob und in welcher Form Sie die angebotenen Artikel und Informationen nutzen, liegt daher allein bei Ihnen. Mit Ausnahme der gesetzlichen Haftung für Vorsatz ist jede Haftung von Microsoft im Zusammenhang mit Ihrer Nutzung dieser Artikel oder Informationen ausgeschlossen.

Ihr Feedback an uns

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com