Offline Backup- und Wiederherstellungsverfahren für Exchange

Zusammenfassung

Dieser Artikel beschreibt Methoden, die zum Umgehen der online backup Anwendungsprogrammierschnittstellen (APIs) und manuell sichern und Wiederherstellen von Exchange-Informationsspeicher-Datenbanken. Haben Sie mehrere Speichergruppen auf einem Exchange-Server jede Speichergruppe eine unabhängige, in sich geschlossene Einheit zu offline-Sicherung und Wiederherstellung zu berücksichtigen. Weitere Informationen über offline und Snapshot-Backups finden Sie der Microsoft Knowledge Base:

296787 XADM: Offline Backup- und Wiederherstellungsverfahren für Exchange Server 4.0, 5.0 und 5.5

Weitere Informationen

Bevor Sie beginnen

Vor dem Durchführen einer offline-Sicherungskopie stellen Sie sicher, dass Sie die folgende Informationen:
  • Bestimmen Sie, ob die zirkuläre Protokollierung für die Speichergruppe aktiviert ist. (Zirkuläre Protokollierung ist in Exchange standardmäßig.) Um zu bestimmen, ob die zirkuläre Protokollierung aktiviert ist, öffnen Sie die Eigenschaften des Objekts Speichergruppe im Exchange-System-Manager, und zeigen Sie die Seite Allgemein . Deaktivieren, deaktivieren Sie das Kontrollkästchen Zirkuläre Protokollierung . Zirkuläre Protokollierung geändert werden bis Sie jede Datenbank in der Speichergruppe anhalten wirksam.


    Sie müssen nicht offline-Backups durchführen zirkuläre Protokollierung deaktivieren. Allerdings müssen Sie Transaktionsprotokolle in wiederhergestellten offline-Backups wiedergeben soll zirkuläre Protokollierung deaktivieren.
  • Bestimmen Sie den Pfad Ihrer Exchange-Datenbank, streaming Transaktionslog und Prüfpunktdateien sowie das Protokolldatei-Präfix für die Speichergruppe.


    Suchen, öffnen Sie die Eigenschaften des Objekts Speichergruppe im Exchange-System-Manager, und zeigen Sie die Seite Allgemein . Notieren Sie die Werte für die folgenden drei Felder:
    • Präfix für Protokolldatei (E0n, wobei E0n E00, E01, E02 oder E03 sein kann)
    • Pfad des Transaktionsprotokolls (E0n*.log)
    • Systempfad ("E0n.chk")
    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 Exchange-System-Manager nicht verfügbar ist, finden alle vorherigen Informationen Sie durch Attribute mit eines Tools wie ADSIEDIT oder LDIFDE direkt aus Active Directory lesen. Den folgenden LDIFDE-Befehl können Sie Informationen für alle Exchange-Server in Active Directory-Gesamtstruktur ausgeben.

Hinweis: der Text für diesen Befehl wurde zur 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=*))"
Folgendes ist ein Beispiel für die Ausgabe des voranstehenden Befehls:
D:\Exchsrvr\Mdbdata > Ldifde -f con -d "Cn = Configuration, dc = Test, dc = com" -l msExchRequireAuthToSendTo Eseparamlogfilepath, Msexcheseparamsystempath, Msexcheseparambasename, Msexchesepar Amcircularlog, Msexchslvfile, Msexchedbfile - R "(| () MsExchESEParamLogFilePath = *) (ms excheseparamsystempath=*)(msexcheseparambasename=*)(msexchslvfile=*) (Msexchedbfi le=*)(msexcheseparamcircularlog=*))"
Verbindung mit "DC1.Child.Test.com"wird hergestellt
Anmelden als aktueller Benutzer unter Verwendung von SSPI
Verzeichnis in Datei Con exportieren
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 = = Organisation, CN = Microsoft Excha Nge, CN = Dienste, CN = Configuration, DC = Test, DC = com
ChangeType: Hinzufügen
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 = = Organisation, CN = Microsoft Exchange, CN = Dienste, CN = Configuration, DC = Tes t, DC = com
ChangeType: Hinzufügen
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 = Organisation, CN = Microsoft Exchange, CN = Dienste, CN = Configuration, DC = Te St, DC = = com
ChangeType: Hinzufügen
MsExchEDBFile: D:\exchsrvr\MDBDATA\PRIV. EDB
MsExchSLVFile: D:\exchsrvr\MDBDATA\PRIV.stm
Um die Transaktionsprotokolle erfolgreich zurückspielen zu können, müssen Sie Datenbankdateien (EDB und STM) zu den gleichen Pfad wiederherstellen die Dateien gesichert wurden. Z. B. Wenn Sie die Datenbankdatei E:\Mdbdata Ordner und der Streamingdatenbank aus Ordner "F:\Mdbdata" Sichern, müssen Sie die Dateien E:\Mdbdata und F:\Mdbdata bzw. wiederherstellen. Diese Einschränkung gilt auch, wenn Sie die Datenbank auf einem vollkommen anderen Server (z. B. in Notfallsituationen Postfachs) wiederherstellen möchten.


Wenn Sie einen Datenbankpfad nach der letzten Sicherung ändern, können Sie Transaktionsprotokolle nur teilweise zurückspielen und erreichen eine teilweise Wiedergabe nur, wenn auf den ursprünglichen Speicherort den Pfad zu ändern. Wenn wieder auf den alten Pfad können Sie Protokolle bis zu dem Punkt wiedergeben, an denen der Pfad geändert wurde.


Sie können Transaktionsprotokolldateien (E0n*.log) in einem anderen Pfad als den ursprünglichen Speicherort wiederherstellen. Dies ist da Transaktionsprotokolle Aufzeichnen der Standorte der Datenbanken, die Transaktionsprotokolle zugeordnet sind, Datenbanken nicht den Standort der Transaktionsprotokolle aufzeichnen. Beim zurückspielen finden"" die Protokolle die Datenbanken anhand von Pfadinformationen, die im Header Transaktionsprotokolle gespeichert sind. (Online backup-API kompensiert intern Datenbank Pfad ändert und so diese Einschränkung nicht angewendet.)


Nicht sichern oder Wiederherstellen die Prüfpunktdatei ("E0n.chk"), jedoch benötigen Sie die aktuelle Position der Prüfpunktdatei da möglicherweise untersuchen oder während der Wiederherstellung löschen.

Wie Exchange-Datenbankdateien zueinander

Die EDB- und STM-Dateien sind endgültige Repositories für alle Datenbankinformationen. In den meisten Fällen behandeln Sie diese beiden Dateien, als wären sie eine einzelne Datei. Sichern Sie und Wiederherstellen Sie dieser Dateien zusammen. Diese Dateien müssen chronologisch miteinander synchronisiert bleiben. eine EDB-Datei, die an einem Tag gesichert kann gemeinsam mit einer Streamingdatei zugeordnet werden, die an einem anderen Tag gesichert.


Exchange 2000 oder Exchange 2003-Server unterstützen bis zu vier Speichergruppen und jede Speichergruppe wiederum bis zu fünf Datenbanken unterstützen. Eine Speichergruppe ist eine Gruppe von Datenbanken, die eine Gruppe von Transaktionsprotokolldateien gemeinsam nutzen. Microsoft Exchange Server 5.5 kann maximal eine Speichergruppe unterstützen bis zu zwei Datenbanken (die privaten und öffentlichen Informationsspeicher) unterstützt.


Der Datenbank geändert werden, werden die Änderungen zunächst die aktuelle Transaktionsprotokolldatei und dann einen Cache im Arbeitsspeicher geschrieben. Als Änderungen im Cache vorhanden sind, werden diese Änderungen für Benutzer sichtbar. Seiten im Cache geleert werden die Datenbankdatei, die zu zu verwenden ist. Der Prüfpunkt markiert den Zeitpunkt in der Protokolldateisequenz, bis zu der alle Transaktionen physisch in die Datenbankdatei übertragen wurden. Es ist normal, dass der Prüfpunkt drei oder mehr Protokolldateien hinter der aktuellen Protokolldatei zurück.


Zur Vermeidung von namens Verwirrung über die Protokolldateien jeder Speichergruppe Exchange-Protokollen gehören, die in einer bestimmten Speichergruppe gehören mit einer eindeutigen Protokollpräfix, die 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 als E0n festgelegt. Die aktuelle Protokolldatei für eine Speichergruppe ist immer "E0n.log".


Transaktionsprotokolle werden eine einheitliche 5 Megabyte (MB). Die aktuelle Protokolldatei voll ist, wird mit hexadezimale Sequenznummer, die Protokollerzeugungsnummer, umbenannt und eine neue aktuelle Protokolldatei generiert. Protokolldateien werden als "E0n00001.log", "E0n00002.log" usw. nummeriert. In diesem Artikel werden nummerierte Protokolldateien im Allgemeinen E0nXxxxxgekennzeichnet. Log.


Wenn eine Datenbank nicht normal angehalten, die Prüfpunktdatei ("E0n.chk") Datensätze Wiedergabe des Transaktionsprotokolls aus der Wiederherstellungsprozess beginnen muss zum Wiederherstellen der Datenbank konsistent. Dieser Vorgang wird "soft Recovery" bezeichnet. Wiederherstellung kann mit "hard Recovery" ist der Prozess von dem Protokolldateien nach der Wiederherstellung einer online-Sicherung Wiedereinspielen bereitstehen. Der wichtigste Unterschied zwischen den harten und weichen Recovery ist die Interpolation Patchdatei-Daten in das Protokoll Datei Wiedergabevorgang während des hard Recovery.


Eine inkonsistente Exchange-Datenbankdatei ist eine Datei, in die noch nicht alle ausstehenden Transaktionen geschrieben wurden. Während des normalen Betriebs sind Exchange-Datenbankdateien inkonsistent, weil Informationen im Cache, der noch nicht physisch in die Datei 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.

Sichern einer Exchange-Datenbank

So sichern Sie eine Exchange-Datenbank
  1. Heben Sie die Bereitstellung der Datenbank, die Sie sichern möchten. Sie müssen nicht alle Datenbanken in der Speichergruppe nur die Datenbank oder Datenbanken, die Sie sichern möchten.
  2. Überprüfen Sie die Datenbankdateien (EDB- und STM-Datei) konsistent und miteinander übereinstimmen. Führen Sie hierzu den folgenden Befehl für jede Datei:
    Eseutil/mh Datenbankdatei | i "Datenbanksignatur" Suchen
    Hinweis: Exchange 2000 Servicepack 2 und höher meldet den Datenbankstatus nicht als "Konsistent" oder "Inkonsistent", sondern als "Ordnungsgemäßes Herunterfahren" oder "Dirty Shutdown". "Clean Shutdown" bedeutet dasselbe wie "Konsistent" und "Dirty Shutdown" bedeutet "Inkonsistent" identisch. Führen Sie für Exchange 2000 Service Pack 2 oder höher diesen zusätzlichen Befehl ermitteln den Zustand der Datenbank aus:

    Eseutil/mh Datenbankname | Suchen Sie/i "Herunterfahren"
    Folgendes 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 vorhergehenden Beispiel sind die Datenbanksignaturen identisch beweist, dass die EDB- und STM-Dateien denselben angehören. (Beide Signaturzeilen müssen Zeichen in ihrer Gesamtheit als Signatur übereinstimmend übereinstimmen.)


    Nicht nur müssen die Übereinstimmung der Datenbanksignaturen vorliegen, sondern die Dateien müssen auch miteinander synchronisiert und konsistent sein. Jede Datei den folgenden Befehl ausführen:
    Eseutil/mh Datenbankdatei | i "konsistent" Suchen
    Folgendes ist ein Beispiel für die Ausgabe des voranstehenden Befehls führt:
    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 vorhergehenden Beispiel beide Dateienbericht "Status: konsistent." Die hexadezimalen Zahlen in Klammern für die einzelnen Dateien (0x2CC7, 1F14, 1F7) müssen ebenfalls übereinstimmen. Der letzte konsistente Zeitstempel muss nicht übereinstimmen. Diese Dateien sind konsistent und miteinander abgestimmt.


    Wenn eine Berichtsdatei "Status: inkonsistent" oder das letzte konsistente Protokoll nicht synchronisiert sind, wurde die Datenbank nicht ordnungsgemäß aufgehoben. Bereitstellen Sie und entfernen Sie die Datenbank erneut. Wenn die Dateien noch nicht ordnungsgemäß übereinstimmen oder inkonsistent, wenden Sie sich an Microsoft Product Support Services (PSS) für weitere Unterstützung.
  3. Kopieren Sie jede EDB-Datenbankdateien und die entsprechenden STM-Streamingdatenbank an einen Sicherungsspeicherort.
  4. Laden Sie die gesicherten Datenbanken.
  5. Wenn die zirkuläre Protokollierung aktiviert ist, überspringen Sie diesen Schritt. Wenn "später ein Rollforward" soll zirkuläre Protokollierung deaktiviert ist, müssen Sie alle nummerierten Transaktionsprotokolldateien (E0nXxxxx.log-Dateien) sichern. Führen Sie keine Sicherungskopie der Dateien "E0n.log" Res1.log und Res2.log.

    Nummerierte Protokolldateien können jederzeit, sogar unmittelbar nach Erstellung sichern weil eine Protokolldatei in E0nXxxxx.log von "E0n.log" umbenannt wurde, Exchange keine Datei erneut ändern. Protokolldateien nach der Anleitung in Schritt 6 jedoch löschen gesichert.


    Die Sicherungskopien müssen nicht mit Ihren Datenbanksicherungsdateien. Jede Sicherung ist eine Verknüpfung in einer Kette von Protokolldateien, die gegen mehrere Datenbanksicherungskopien gespielt werden. Sie können eine bestimmte Sicherung Rollforward von als einen ununterbrochenen Stream der Protokolle mit der "Last Consistent" in der Kopfzeile der Datenbank aufgeführt sind. In diesem Artikel wird das letzte konsistente Protokoll als das "low Anchor-Protokoll" bezeichnet.


    Wenn Sie im vorangehenden Beispiel verweisen, wird der letzte konsistente Eintrag (0x2CC7, 1F14, 1F7). Die drei Zahlen stehen für eine Protokolldatei, eine Seite in die Protokolldatei und einen Byteoffset in dieser Seite. Jede Protokolldatei enthält ungefähr 10.000 Seiten mit jeweils 512 Byte. Seiten-Offset vermittelt einen guten Überblick darüber, wie schließen die Protokolldatei ist (die Protokolldatei im vorangehenden Beispiel ist 80 Prozent voll, weil 0x1F14 Dezimalzahl 7956 entspricht), aber für Recovery. Die Wiederherstellung beginnt stets am Anfang einer Protokolldatei.


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


    Möglicherweise nicht immer das letzte konsistente Protokoll auf der Festplatte als nummeriertes Protokoll angezeigt, da das letzte konsistente Protokoll weiterhin "E0n.log" benannt ist. Sehen Sie Sequence Number "E0n.log" schließlich erfolgt durch den Protokolldatei-Header überprüfen, während die Datenbank angehalten (Zugriff verweigert "E0n.log" Header bei laufender Datenbank).


    Führen Sie den folgenden Befehl, um die interne Protokollerzeugungsnummer anzuzeigen:
    Eseutil/ML [Datei] | i "lGeneration" Suchen
    Folgendes 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, sicherzustellen, dass die Sicherungskopien Ihrer Protokolldateien sind gut als es ist, sicherzustellen, dass jede Sicherung ist. Ist jeder Sicherung bietet Redundanz für die anderen, aber vollständige Wiederherstellung von Datenbank-Backup hängt nach dieser Sicherung jeder Datei beibehalten.
  6. Überspringen Sie diesen Schritt, wenn die zirkuläre Protokollierung aktiviert ist. Überprüfen Sie den Header der Prüfpunktdatei höchste nummerierte Protokolldatei bestimmen, die sicher entfernt werden kann. Die Prüfpunktdatei zeichnet die niedrigsten nummerierte Protokolldatei, die für automatische Wiederherstellung erforderlich ist, wenn die Datenbank nicht normal angehalten wird. Führen Sie den folgenden Befehl, um die Prüfpunktdatei anzuzeigen:
    "Eseutil" /mk "E0n.chk"
    Folgendes 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 der Checkpoint-Zeile enthält Informationen (die LastFullBackupCheckpoint Eintrag von online-Sicherung verwendet und Nullen bleibt, wenn Sie eine online-Sicherung nicht in der Datenbank ausgeführt wird). Formatiert den Prüfpunkt entspricht der letzte konsistente Eintrag im Datenbank-Header. In diesem Beispiel befindet sich der Prüfpunkt in der Protokolldatei "E0002cc7.log".


    Wenn die zirkuläre Protokollierung deaktiviert ist, sammeln sich die Protokolldateien, bis sie manuell gelöscht oder automatisch vom Online-backup-Prozess entfernt. Zirkuläre Protokollierung aktiviert, keine Management alte Protokolldateien ist erforderlich, weil der Datenbankdienst alte Protokolldateien automatisch löscht, nachdem der Prüfpunkt Sie durchlaufen hat.


    Nachdem Sie alle nummerierten Protokolldateien sichern, können Sie alle nummerierten Protokolldateien bis zu entfernen, aber nicht einschließlich Checkpoint-Log Speicherplatz freigeben.

    Wichtig: das Checkpoint-Log nicht entfernen.

    In diesem Beispiel können Sie alle Protokolle bis E0002cc6.log entfernen.
  7. Dieser Schritt ist optional. Das Dienstprogramm "Esefile" können, auf Integrität der kopierten Datenbank überprüfen.

    Die Datei Esefile.exe steht im Ordner Support auf der Exchange Server 5.5 Service Pack 3-CD, der Exchange 2000 Server-Installations-CD oder der Exchange Server 2003-Installations-CD. Sie können auch die Datei Esefile.exe von Microsoft PSS abrufen. Das Dienstprogramm "Esefile" kann für .edb-Dateien von Exchange Server 5.0 und 5.5 sowie Exchange 2000 und Exchange 2003.


    Es gibt keine andere Methode als online-Sicherung die Prüfsummen für jede Seite einer STM-Datei überprüfen. Die STM-Datei enthält unaufbereitete Daten. Alle Indizes und Zeiger, die diese Daten strukturieren werden 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 manipulieren.


    Um die Seitenprüfsummen für eine Exchange-Datenbank zu überprüfen, führen Sie den folgenden Befehl des Dienstprogramms "Esefile":
    Esefile/s Datenbankname
    Folgendes 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, aber in einer Datenbank ohne Probleme sind 0 ungültige Prüfsummen und 0 falsche Seitenzahlen.


    Einer Überprüfung Integrität Dienstprogramm "Esefile" nicht bestanden hat, ist die beste Option auf eine frühere Sicherungskopie wiederherstellen, die gut und Rollforward für die Datenbank kennen. Wenn eine solche Sicherung nicht verfügbar ist, finden Sie in PSS Ratschläge zum Reparieren oder retten der Datenbank.
  8. Dieser Schritt ist optional. Den folgenden Befehl können Sie zum Überprüfen der Integrität von gesicherten Protokolldateien:
    Eseutil/ML E0n
    Folgendes ist ein Beispiel für die Ausgabe des voranstehenden Befehls:
    k:\backups>eseutil /ml E00 
    Aus einem Ordner, die die gesicherten Protokolldateien enthält, müssen Sie diesen Befehl ausführen. Sie können diesen Befehl auch gegen aktuelle ausgeführten Protokollordner ausführen, aber wenn Eseutil versucht, lesen den Header von "E0n.log" jede Datenbank in der Speichergruppe ausgeführt wird, wird die Fehlermeldung-1032 (JET_errFileAccessDenied).


    Dieser Befehl erkennt Fehler in den Protokolldateien und warnt Sie auch, wenn eine Protokolldatei in einer Sequenz fehlt oder ein Signaturkonflikt zwischen den Protokolldateien vorhanden ist.

Eine Offline-Sicherung von Exchange-Datenbanken wiederherstellen

Dieser Abschnitt beschreibt zwei Methoden, um eine offline-Sicherung wiederherzustellen:
  • "Point-in-Time" wiederherstellen. Keine Protokolldateien sind in die Datenbank zurückgespielt. Alle nach der Sicherung erstellten Daten geht 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. Wenn die zirkuläre Protokollierung aktiviert ist, führen Sie eine Wiederherstellung "Zeitpunkt" offline-Sicherung; Sie können keine "Rollforward" Wiederherstellung auswählen.
Die Dateigruppe wiederherstellen muss folgenden Mindestkriterien erfuellen:
  • Punkt in Mal Wiederherstellung aller angehaltenen Datenbanken in der Speichergruppe konsistent sein und muss eine gültige Prüfpunktdatei. Löschen Sie die aktuelle Prüfpunktdatei oder die vorhandenen Protokolldateien.
  • Roll forward Wiederherstellung aller Datenbanken in der Speichergruppe muss angehalten und konsistent sein und alle Protokolldateien, die nach der Zeit erstellt wurden und der Sicherung vorhanden sein (einschließlich der aktuellen "E0n.log"). Die Prüfpunktdatei muss gelöscht werden.
Wenn die Dateigruppe vorhergehenden Bedingung nicht erfüllt, werden Sie wahrscheinlich eine-1216 (JET_errAttachedDatabaseMismatch) während der Wiederherstellung Fehlermeldung Wiederherstellung und Wiedergabe nicht unbedingt auftreten

Mit einem 1216

Zusätzliche soft Recovery-Sicherheitsfunktionen in Exchange 2000 und höher Ursache der-1216 Wenn Exchange manuell veränderte Datendateien erkennt, und, dass eine Wiederherstellung mit dem aktuellen Datensatz bestimmt zum Verlust der zuvor Fehler würde vorhandener Daten.

In früheren Versionen von Exchange Wenn der Dateisatz unvollständig zwar, aber gültig für ein erfolgreiches Zurückspielen startet der soft Recovery ohne Warnung an den Administrator. In Exchange 2000 und höher muss der Administrator übergehen die 1216 mithilfe von Eseutil.

Point-in-Time-Wiederherstellung einer Offline-Sicherung

So etwas Zeit Wiederherstellung eine offline-Sicherung:
  1. Wenn die Datenbank, die Sie wiederherstellen möchten, derzeit bereitgestellt ist, heben Sie die Bereitstellung auf. Wenn alle Datenbanken in der Speichergruppe aufgehoben werden, muss diese Datenbanken Datenbank- und Streamingdateien (EDB- und STM) jedes konsistent sein und übereinstimmen. (Überprüfen Sie Konsistenz und entsprechen, finden Sie unter Schritt 2 im Abschnitt "Sichern von einer Exchange-Datenbank Offline" in diesem Artikel.)

    Wenn alle Datenbanken in der Speichergruppe aufgehoben werden, müssen alle Datenbanken konsistent sein und muss auch eine gültige Prüfpunktdatei existieren. Eine gültige Prüfpunktdatei ist eine Prüfpunktdatei, die Datenbanken in der Speichergruppe ausgeführt wurden, zuletzt wurde mit einem Header, der als der Prüfpunkt "E0n.log" enthält. Wenn eine Datenbank in der Speichergruppe bereitgestellt ist, ist die gültige Prüfpunktdatei die Prüfpunktdatei, die derzeit vom System verwendet. Wenn eine Datenbank in der Speichergruppe ausgeführt wird, ist eine gültige Prüfpunktdatei vorhanden.

    Führen Sie folgende Befehle, um die Prüfpunktdatei zu überprüfen, wenn alle Datenbanken angehalten:
    "Eseutil" /mk "E0n.chk" | I "Checkpoint" Suchen
    Eseutil/ML "E0n.log" | I "Lgeneration" Suchen
    Folgendes 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 vorherigen Beispiel ist der Prüfpunkt im Protokoll mit lGeneration 0x2cc7, e00.log. Daher kann der Prüfpunkt als gültig betrachtet werden.

    Wenn der Prüfpunkt ungültig ist, möglicherweise Fehlermeldung eine-1216 (JET_errAttachedDatabaseMismatch) Wenn Sie versuchen, eine Datenbank in der Speichergruppe bereitgestellt. Dieses Problem kann auftreten, selbst wenn alle Datenbanken in der Speichergruppe konsistent sind.
  2. Kopieren Sie die gesicherten EDB- und STM-Dateien der entsprechenden Datenbank und streaming Speicherorte (Zu diesen Speicherorten finden Sie im Abschnitt "Vorbereitung" dieses Artikels.) Stellen Sie sicher, dass die wiederhergestellten Dateien konsistent und übereinstimmen sind.


    Hinweis: Wenn Kopien der Datenbankdateien, die bereits auf dem Server vorhanden, sichern diese Dateien vor dem Wiederherstellen der Datenbank, auch wenn die vorhandenen Dateien nicht gestartet werden kann. Möglicherweise repariert werden, und möglicherweise Daten retten von ihnen mithilfe des Dienstprogramms "ExMerge".
  3. Bereitstellen Sie die wiederhergestellte Datenbank. Die Datenbank wird an das Ende der Datei "E0n.log". Nachdem die Datenbank erfolgreich gestartet wurde, können keine zuvor vorhandenen Protokolldateien nie in die Datenbank zurückgespielt. Öffentliche Ordner-Datenbanken, die Tausende Ordner in der Hierarchie enthalten dauern zu lange. Für mindestens eine Minute pro 1000 Ordner in der Hierarchie zulassen


    In früheren Versionen von Exchange Server in der Regel ausgeführt werden musste die ISINTEG-Patch Befehl nach dem Wiederherstellen einer offline-Sicherungskopie der Informationsspeicher-Datenbank, um die Informationsspeicher-Datenbank mit dem Verzeichnis synchronisieren. Wenn ist eine Exchange-Datenbank notwendig, dass Patches automatisch vom System durchgeführt wird, sofern die Datenbank auf einem anderen Server wiederhergestellt Speichergruppe oder logischen Datenbankobjekt oder Active Directory-Objekt für die Datenbank gelöscht und wurde erneut in Active Directory erstellt. In diesen Fällen wird die folgende Fehlermeldung im Ereignisprotokoll Anwendung protokolliert.
    Ereignistyp: Fehler
    Ereignis Quelle: MSExchangeIS Mailbox Store
    Kategorie: Allgemein
    Ereignis-ID:1087
    Date:5/4/2001
    Zeit: 8:33: 42 PM
    User:N/A
    Computer:EXCHANGE1
    Beschreibung: Informationsspeicher wurde von einer externen Sicherungskopie wiederhergestellt. Bedeuten Sie in Microsoft Exchange-System-Manager, dass die Datenbank "erste Speichergruppe\Privater Informationsspeicher" zulässig ist, wiederhergestellt werden, damit das Patch angewendet werden kann.
    Um dieses Problem zu beheben, müssen Sie aktivieren das Kontrollkästchen diese Datenbank kann bei einer Wiederherstellung überschrieben werden in Exchange-System-Manager in den Datenbankeigenschaften des Datenbankobjekts.

Roll Forward Wiederherstellung einer Offline-Sicherung

Wiedergabe von Protokolldateien für die Chancen erfolgreich in eine wiederhergestellte Datenbank:
  • Bewahren Sie eine Kopie aller Transaktionsprotokolle, die nach dem Zeitpunkt der ältesten vollständigen Sicherung erstellt wurden.
  • Ändern Sie einen Datenbankpfad nicht, ohne eine neue vollständige Sicherung unmittelbar danach.
  • Führen Sie ESEUTIL/p oder ESEUTIL/d nicht ohne eine neue vollständige Sicherung unmittelbar danach.
  • Hinzufügen oder Entfernen einer Datenbank in einer Speichergruppe ohne sofort eine vollständige Sicherung aller Datenbanken in der Speichergruppe nicht.
Mit der Wiederherstellung beginnen:
  1. Wenn die wiederherzustellende Datenbank bereitgestellt ist, heben Sie und kopieren Sie die Datenbankdateien auf die entsprechenden Pfade auf dem Server wiederherstellen möchten. Wenn Kopien der Datenbankdateien, die bereits auf dem Server vorhanden, Sichern Sie diese Kopien vor dem Wiederherstellen der Datenbank auch wenn die vorhandenen Dateien nicht gestartet werden kann. Möglicherweise repariert werden, und möglicherweise das Dienstprogramm Daten retten von ihnen verwenden.
  2. Alle Datenbanken in der Speichergruppe, und führen Sie den folgenden Befehl für jede Datenbank in der aktuellen Speichergruppe sowie für jede wiederhergestellte Datenbankdatei:
    Eseutil/mh Datenbank-Dateiname | i "konsistent" Suchen
    Hinweis: Exchange 2000 Servicepack 2 und höher meldet den Datenbankstatus nicht als "Konsistent" oder "Inkonsistent" als "Clean Shutdown" oder "Dirty Shutdown". "Clean Shutdown" bedeutet dasselbe wie "Konsistent" und "Dirty Shutdown" bedeutet "Inkonsistent" identisch. Führen Sie für Exchange 2000 Service Pack 2 oder höher diesen zusätzlichen Befehl ermitteln den Zustand der Datenbank aus:

    Eseutil/mh Datenbankname | Suchen Sie/i "Herunterfahren"
    Folgendes 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.
    • Um sicherzustellen, dass die EDB- und STM-Dateien für jede Datenbank ein aufeinander abgestimmtes Paar.
    • Zu niedrig und high Anchor-Protokolldateien sind die ersten und letzten Protokolldateien, die erfolgreiche Wiederherstellung aller Daten ohne eine 1216 erforderlich sind. 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 vorangehenden Beispiel ist "E0002ac8.log" niedrige Anchor-Protokolldatei und E0002cc7.log high Anchor-Protokolldatei.
  3. Überprüfen Sie die Protokollsignatur, die im Header Datenbanken erfasst die Signatur des low Anchor-Protokoll. Führen Sie die folgenden Befehle aus:
    Eseutil/mh Datenbankname | i "Protokollsignatur" Suchen
    Eseutil/ML Low_anchor_log | i "Signature" gefunden
    Folgendes 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 kann mehrere Signaturen anzeigen. Die erste Signatur ist immer die Protokollsignatur der Datei. die übrigen sind Datenbanken gleichzeitig ausgeführt wurden, die die Datei erstellt wurde. Im vorherigen Beispiel entsprechen die in den Datenbankdateien aufgezeichneten Protokollsignaturen die Protokollsignatur im low Anchor-Protokoll.


    Wenn Sie low Anchor-Protokoll nicht finden, können Sie Protokolle in der Datenbank nicht wiedergeben. Niedrige Anchor-Protokolldatei finden, können keine Protokolldateien in die Datenbanken wiedergegeben werden. Es gibt zwei Methoden, mit denen Sie mit einem fehlenden low Anchor-Protokoll:
    • Sie können alle Protokolldateien entfernen. Weil die Datenbanken konsistent sind, ohne Protokolldateien starten, aber Sie verlieren Möglichkeit zur Wiederherstellung von Daten, die nicht bereits in die Datenbankdateien.
    • Sie können Datenbanken mit den niedrigsten zuletzt konsistenten Werten entfernen, bis eine ununterbrochene Reihe von niedrig zu high Anchor zu erstellen, und führen Sie für die verbleibenden Datenbanken Wiederherstellung. Wenn Sie die entfernten Datenbanken wieder in die Speichergruppe, können nicht in diese zusätzliche Daten wiedergegeben werden.
  4. Stellen Sie sicher, dass die aktuellen Datenbankpfade identisch sind, wie die Zeit, die der Sicherung.

    Sie können zwar ändern Transaktionsprotokollpfad oder Arbeitspfad nach eine Sicherungskopie zu erstellen, können Sie nur Protokolldateiwiedergabe durchführen, Datenbankdateien angegeben sind, der sie gesichert wurden. Wenn Sie den ursprünglichen Speicherort kennen, führen Sie den folgenden Befehl ein:
    Eseutil/ML "Last_Consistent" "_log" | i "Datenbankname oder Muster" Suchen
    Folgendes 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: ist das low Anchor-Protokoll "E0n00001.log", es nicht über die Informationen im Header, weil der Header des ersten Protokolls einer Reihe generiert wird, bevor die erste Datenbank immer an das Protokoll angehängt wird. In diesem Fall müssen Sie im Header des nächsten Protokolls Anzeigen von Datenbankinformationen Pfad suchen. In seltenen Fällen dies auch für Protokolle nach dem ersten true möglicherweise eine Datenbank erstellt oder an den Protokollstream angehängt werden, nachdem das Protokoll erstellt wurde.
  5. Sammeln Sie alle Protokolle aus der niedrigen Anker Zahl so weit vorne in durchgehende Reihenfolge, und kopieren Sie diese Protokolle auf den Pfad der aktuellen Transaktion Protokolle. Überschreiben Sie keinesfalls Protokolle, die bereits auf dem Server ohne diese Protokolle zuerst. Dazu müssen Sie die Protokolldateien von mehr als einem Sicherungsmedium wiederherstellen.


    Im vorangehenden Beispiel ist "E0002ac8.log" die low Anchor und high Anchor E0002cc7.log. Wenn Sie die verfügbaren Protokolle überprüfen, möglicherweise höchste nummerierte Protokolldateien, die Sie finden eine Nummer unter der erforderlichen Nummer (z. B. E0002cc6.log, statt "2cc7"). Das Problem tritt gewöhnlich die "E0n.log" noch nicht ausgefüllt und die Zahl in der Folge umbenannt. Um festzustellen, ob "E0n.log" tatsächlich das high Anchor-Protokoll ist, verwenden Sie den folgenden Befehl lGeneration Wert im Protokolldatei-Header überprüfen:
    Eseutil/ML "E0n.log" | i "lGeneration" Suchen
    Folgendes ist ein Beispiel für die Ausgabe des voranstehenden Befehls:
    N:\mdbdata>eseutil /ml e00.log |find /i "lGeneration"
    lGeneration: 11463 (0x2cc7)

    Hinweis: um den Header einer Protokolldatei mit dem Dienstprogramm "Eseutil" anzuzeigen, verwenden Sie den Schalter/ml ; zum Anzeigen eines Datenbankdatei-Headers verwenden Sie die Option MH . Wenn Sie die Parameter verwechseln, ist die Ausgabe der Befehle falsch.


    Normalerweise ist das high Anchor-Protokoll auch das höchste verfügbare Protokoll, aber dies gilt nicht wenn:
    • Protokolldateien sind bei einem Ausfall zerstört.


      – oder –
    • Sie werden alle Datenbanken in einer Speichergruppe gleichzeitig wiederherstellen.
    Im ersten Fall sind Sie wahrscheinlich "-1216"-Fehlermeldungen bei der Wiederherstellung Im zweiten Fall können Sie Protokolldateien sogar über das high Anchor-Protokoll spielen, solange sie die "lGeneration"-Sequenz.
  6. Stellen Sie sicher, dass alle Protokolle die gleichen Protokollsignatur und ununterbrochene Sequenz. Führen Sie den folgenden Befehl ein:
    Eseutil/ML E0n > Dateiname.txt
    Folgendes 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: jede Protokolldatei auf Schäden überprüft, Lücken in der Protokolldateisequenz und Protokollsignaturkonflikten erkennt.


    Alle Protokollsignaturen müssen sämtlichen Protokolldateien übereinstimmen, die zurückgespielt werden. Sie müssen alle Protokolle entfernen, die nicht übereinstimmende Signaturen vor dem zurückspielen.


    Zu diesem Zeitpunkt nach dem Entfernen der Dateien, die nicht die Überprüfungstests bestanden haben, Dateien nur Transaktionsprotokoll Dateien in den Ordner für Transaktionsprotokolle:
    • Ununterbrochene lGeneration Sequenz, beginnend mit der niedrigen Anchor-Protokolldatei und bis mindestens die high Anchor-Protokolldatei und wenn möglich sind.
    • Weisen Sie übereinstimmende Protokollsignaturen.
  7. Wenn das high Anchor-Protokoll "E0n.log" noch nicht genannt wird, benennen Sie sie.
  8. Entfernen Sie die Datei "E0n.chk" aus dem Systempfad-Ordner.


    In Ermangelung einer Prüfpunktdatei beginnt Exchange Server die Protokolle aus der niedrigsten nummerierte Protokolldatei wiedergeben, die in den Ordner für Transaktionsprotokolle: low Anchor-Protokoll. Wenn die Datei "E0n.chk" vorhanden ist, beginnt Exchange Server Wiedergabe am Kontrollpunkt in dieser Datei aufgezeichnet. "E0n.chk" nach dem low Anchor-Protokoll verweist, schlägt Replay für den wiederhergestellten Dateisatz fehl. In vielen Fällen Wenn Sie einen Fehler mit der Prüfpunktdatei machen müssen Sie Starten über Datenbanken aus einer Sicherung wiederherstellen.
  9. Letzte Überprüfung vor der Bereitstellung der Speichergruppe überprüfen:
    • Alle Datenbankdateien sind in ihren Ausführungspfaden vorhanden.
    • Die einzigen Protokolldateien im laufenden Transaktionsprotokollpfad sind Dateien, die das low Anchor-Protokoll beginnen und mindestens das high Anchor-Protokoll mit der höchsten verfügbaren "E0n.log" benannt.
    • Es ist keine Datei "E0n.chk" im Systempfad-Ordner.
    Sie sollte jetzt erfolgreich die Speichergruppe bereitstellen und Transaktionsprotokolle mit dieser Dateien wiedergeben können. Auch nach Abschluss der Wiederherstellung und dem Starten der Datenbank kann alle Daten in den Protokolldateien nicht tatsächlich aufgrund DB Signatur und Pfad wiederhergestellt werden, die während der Wiedergabe auftreten. Abschnitt "Umgang mit Datenbank Datenbanksignatur-und Pfadkonflikten" dieses Artikels stellt weitere Informationen zu diesen Problemen.
  10. Wenn der Informationsspeicher nicht ausgeführt wird, starten und mindestens eine Datenbank in der Speichergruppe bereitstellen. Dadurch wird die Wiederherstellung für alle Datenbanken in der Speichergruppe ausgeführt.


    In früheren Versionen von Exchange Server in der Regel müssen Sie Ausführen der ISINTEG-Patch Befehl nach dem Wiederherstellen einer offline-Sicherungskopie der Informationsspeicher-Datenbank, um die Datenbank mit dem Verzeichnis synchronisieren. Wenn ist eine Exchange-Datenbank notwendig, dass Patches automatisch vom System durchgeführt wird, sofern die Datenbank auf einem anderen Server wiederhergestellt Speichergruppe oder logischen Datenbankobjekt oder Active Directory-Objekt für die Datenbank gelöscht und wurde erneut in Active Directory erstellt. In diesen Fällen wird die folgende Fehlermeldung im Ereignisprotokoll Anwendung protokolliert.
    Ereignistyp: Fehler
    Ereignis Quelle: MSExchangeIS Mailbox Store
    Kategorie: Allgemein
    Ereignis-ID:1087
    Date:5/4/2001
    Zeit: 8:33: 42 PM
    User:N/A
    Computer:EXCHANGE1
    Beschreibung: Informationsspeicher wurde von einer externen Sicherungskopie wiederhergestellt. Bedeuten Sie in Microsoft Exchange-System-Manager, dass die Datenbank "erste Speichergruppe\Privater Informationsspeicher" zulässig ist, wiederhergestellt werden, damit das Patch angewendet werden kann.
    Um dieses Problem zu beheben, müssen Sie aktivieren das Kontrollkästchen diese Datenbank kann bei einer Wiederherstellung überschrieben werden in Exchange-System-Manager in den Datenbankeigenschaften des Datenbankobjekts.
Ereignisprotokoll der Anwendung in Microsoft Windows NT-Ereignisanzeige für Fehler oder Anomalien beim Starten der Datenbank auftreten. Für jede Protokolldatei, die wiedergegeben wird, wird Ereignis 301 angezeigt. Achten Sie sorgfältig auf Fehler und Warnungen während des Wiederherstellungsprozesses.


Umgang mit Datenbanksignatur- und Pfadkonflikten

Datenbanken wie Protokolldateien, eigene Signaturen. Aber Obwohl Protokollsignaturen nicht nach der Zeit ändern, die die E0n000001.log-Datei erstellt wird, wenn ändert die physische Topologie der Datenbank unverändert verfolgt die Protokolldateien Datenbanksignaturen ändern. Offlinedefragmentierung oder-Reparatur einer Datenbank mit "Eseutil" wird die Datenbanksignatur geändert. Nach einer solchen Datenbank an den gleichen Protokollstream wie zuvor angefügt werden kann, aber die Datenbank akzeptiert 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 Wiedergabe der Transaktionen, die nach dem Ändern der Datenbanksignatur ausgeführt wurde.


Da die Datenbanksignaturen auf diese Weise zurückgesetzt werden, sollten Sie dringend Datenbank unmittelbar nach der Offlinedefragmentierung oder-Reparatur einer Datenbank sichern. Wenn Sie eine Kopie der Datenbank mit der alten Signatur später wiederherstellen, Wiedergabe erfolgreich bis zum Zeitpunkt der Signatur ändern, aber Sie verlieren alle Änderung an diesem Punkt.


Geänderte Datenbankpfade in einen Datenstrom, der Effekt ähnelt Signaturen ändern: Wiedergabe am Zeitpunkt der Änderung unterbrochen. (Die Online-Sicherung-API bietet die Möglichkeit, Pfade während der Wiederherstellung neu zuordnen, daher online backup-API kann Datenbankprotokolle erneut ausführen, auch wenn ein Pfad seit der Sicherung geändert wurde.)


Datenbanksignatur oder DB werden Pfad Probleme während der Wiedergabe die Datenbanksignatur oder Datenbankpfad berichteten Probleme im Anwendungsereignisprotokoll mit 301 Replay-Ereignisse für jede Protokolldatei. Protokolldateien, die über den Punkt des Problems scheinbar erfolgreich, aber dies ist die gleiche Konflikt Warnung nicht wiederholt protokolliert wird. Eine Regel ist Zurückspielung in eine bestimmte Datenbank an dem Punkt abgeschnitten mit der ersten DB Signatur oder Pfad verweisen auf diese Datenbank auftritt.


Eigenschaften

Artikelnummer: 296788 – Letzte Überarbeitung: 20.01.2017 – Revision: 2

Feedback