none
Replay Transaction Log ohne Fehler – aber auch ohne Erfolg RRS feed

  • Allgemeine Diskussion

  • Hallo Profis,

    nach einer Rücksicherung der Exchange DB möchte ich über ein Soft Recovery die fehlenden Transaction Logs einspielen. Da ich die Transaction Logs vom gecrashten Server geholt habe sind auch ein paar defekte Logs dabei. Auf ein paar Webseiten habe ich gelesen dass man ein Soft Recovery auch in mehreren Schritten durchführen kann. Es wird immer mit der letzten vorhandenen Transaction Log begonnen und die Kette abgearbeitet.

    So bin ich vorgegangen:

    Rücksicherung des gesicherten virutellen Server Image in eine isolierte Umgebung. Exchange läuft auf dem Stand von der Rücksicherung fehlerfrei und die DB hat einen 'clean Shutdown'.

    Rücksicherung aller Transaction Logs vom gecrashten Server die neuer sind als die von der Rücksicherung in ein Verzeichnis C:\Log\warten\

    Mit eseutil /ml E00 habe ich die defekte Transaction Log Dateien ausfindig gemacht.

    1. Ich habe bis zur defekten Log Datei alle Transaction Logs in mein Verzeichnis C:\Log kopiert. Das defekte Log habe ich weggelassen.

    2. In diesem Verzeichnis habe ich die letzte Log Datei in E00.log umbenannt

    3. Im Datenbankverzeichnis habe ich die Datei E00.chk gelöscht

    4. Anschließend konnte ich im Datenbankverzeichnis folgenden Befehl ausführen: Eseutil /r E00 /i /l"C:\Log"

    Dabei wurde das Soft Recovery der Transaction Logs ohne jeglichen Fehler durchgeführt und hat folgendes Ergebnis ausgegeben:

    Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
    Version 15.00
    Copyright (C) Microsoft Corporation. All Rights Reserved.
    
    Initiating RECOVERY mode...
        Logfile base name: E00
                Log files: C:\Log
             System files: <current directory>
    
    Performing soft recovery...
                          Restore Status (% complete)
    
              0    10   20   30   40   50   60   70   80   90  100
              |----|----|----|----|----|----|----|----|----|----|
              ...................................................
    
    
    
    Operation completed successfully in 3.369 seconds.

    Die Schritte oben 1. – 4. habe ich ca. 10-mal wiederholt mit etwa 9 GB Logdateien. Immer die defekte Transaction Log weggelassen und immer mit dem Ergebnis fehlerfrei.

    Allerdings wurde die Datenbank nicht verändert. Das konnte ich an der Änderungsuhrzeit der DB Datei sehen und über eseutil /mh '.\Mailbox Database 1474747554.edb'

    Hier das Ergebnis:

    Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
    Version 15.00
    Copyright (C) Microsoft Corporation. All Rights Reserved.
    
    Initiating FILE DUMP mode...
             Database: .\Mailbox Database 1474747554.edb
    
    
    DATABASE HEADER:
    Checksum Information:
    Expected Checksum: 0x0672ad6a
      Actual Checksum: 0x0672ad6a
    
    Fields:
            File Type: Database
             Checksum: 0x672ad6a
       Format ulMagic: 0x89abcdef
       Engine ulMagic: 0x89abcdef
     Format ulVersion: 0x620,20
     Engine ulVersion: 0x620,20
    Created ulVersion: 0x620,20
         DB Signature: Create time:02/17/2014 21:47:37.294 Rand:3993687841 Computer:
             cbDbPage: 32768
               dbtime: 433833261 (0x19dbc52d)
                State: Clean Shutdown
         Log Required: 0-0 (0x0-0x0)
        Log Committed: 0-0 (0x0-0x0)
       Log Recovering: 0 (0x0)
      GenMax Creation: 00/00/1900 00:00:00.000
             Shadowed: Yes
           Last Objid: 267760
         Scrub Dbtime: 0 (0x0)
           Scrub Date: 00/00/1900 00:00:00
         Repair Count: 0
          Repair Date: 00/00/1900 00:00:00.000
     Old Repair Count: 0
      Last Consistent: (0x3,33,370)  12/29/2015 16:29:43.584
          Last Attach: (0x1,1,268)  12/29/2015 16:27:53.551
          Last Detach: (0x3,33,370)  12/29/2015 16:29:43.584
        Last ReAttach: (0x7F4CF,2,0)  12/18/2015 08:27:07.613
                 Dbid: 1
        Log Signature: Create time:12/29/2015 16:27:53.005 Rand:4151495402 Computer:
           OS Version: (6.2.9200 SP 0 NLS ffffffff.ffffffff)
    
    Previous Full Backup:
            Log Gen: 0-0 (0x0-0x0)
               Mark: (0x0,0,0)
               Mark: 00/00/1900 00:00:00.000
    
    Previous Incremental Backup:
            Log Gen: 0-0 (0x0-0x0)
               Mark: (0x0,0,0)
               Mark: 00/00/1900 00:00:00.000
    
    Previous Copy Backup:
            Log Gen: 0-0 (0x0-0x0)
               Mark: (0x0,0,0)
               Mark: 00/00/1900 00:00:00.000
    
    Previous Differential Backup:
            Log Gen: 0-0 (0x0-0x0)
               Mark: (0x0,0,0)
               Mark: 00/00/1900 00:00:00.000
    
    Current Full Backup:
            Log Gen: 0-0 (0x0-0x0)
               Mark: (0x0,0,0)
               Mark: 00/00/1900 00:00:00.000
    
    Current Shadow copy backup:
            Log Gen: 0-0 (0x0-0x0)
               Mark: (0x0,0,0)
               Mark: 00/00/1900 00:00:00.000
    
         cpgUpgrade55Format: 0
        cpgUpgradeFreePages: 0
    cpgUpgradeSpaceMapPages: 0
    
           ECC Fix Success Count: none
       Old ECC Fix Success Count: none
             ECC Fix Error Count: none
         Old ECC Fix Error Count: none
        Bad Checksum Error Count: none
    Old bad Checksum Error Count: none
    
      Last checksum finish Date: 00/00/1900 00:00:00.000
    Current checksum start Date: 00/00/1900 00:00:00.000
          Current checksum page: 0
    
    
    Operation completed successfully in 0.46 seconds.
    
    
    Nun meine Fragen:

    Was mache ich falsch dass die Logdateien nicht in die Datenbank übertragen werden?

    Wie kann ich den Erfolg von Soft Recovery / Replay Transaction Logs messen?

    Der einzige Grund für das saubere aber ergebnislose Replay der mir kommt könnte sein, dass ich mit zu alten Transaction Log Dateien arbeite und eine Änderung der DB noch nicht notwendig ist. Aber da müsste doch auch etwas an der DB verändert werden oder?

    Ich freue mich über jede Rückmeldung.

    Gruß Samuel

    • Typ geändert Teodora MilushevaModerator Montag, 11. Januar 2016 09:58 Die Threads die keine Aktivität haben, werden als Diskussion geändert. Das machen wir, um die Suche in dem Forum zu verbessern. Sie können den Typ jede Zeit ändern.
    Dienstag, 29. Dezember 2015 18:10

Alle Antworten

  • Moin,

    wenn die Datenbank den Status "Clean Shutdown" hat, denn fehlen für die ESE keine Log-Dateien und Du kannst nichts einarbeiten und ein Soft Recovery funktioniert nicht. Ein Soft Recovery bringt eine Dirty-Datenbank mit den aktuellen Log-Dateien wieder auf einen fehlerfreien Stand.

    Normalerweise müsste der Status nach dem Recovery "Dirty Shutdown" sein und die DB startet nicht, solange man den Schalter "Datenbank wurde durch Restore überschrieben" nicht gesetzt hat.

    Das ist dann der Zeitpunkt, an dem man einen sog. "Hard Recovery" durchführt (das ist keine Reparatur mit /p, wie man oft liest, sondern ein "Soft Recovery" nach Restore).

    Bei Hard Recovery hast Du ein paar Log-Dateien, die in der Sicherung sind und die, die Du noch "findest":

    http://msexchangeguru.com/2009/07/12/exchange-database-recovery-using-eseutil-commands/

    Ist zwar ein wenig älter, müsste aber noch stimmen.

    Weitere Infos (immer noch halbwegs ok, auch wenn noch älter):

    https://technet.microsoft.com/de-de/library/aa996168(v=exchg.65).aspx


    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Dienstag, 29. Dezember 2015 21:17
  • Hallo Robert,

    danke für Deine Rückmeldung. Ich habe die beiden Links gelesen und noch weitere zu 'Hard Recovery'. Das lässt Hoffnung aufkommen.

    Ich habe jedoch das Problem dass ich die DB nicht über eine Windows Server Sicherung zurückgesichert habe sondern das komplette Server-Image hergestellt wurde. Deshalb vermisse ich auch die Datei restore.env.

    Bei eseutil /cm erhalte ich auch den Hinweis dass die Informationen zum Wiederherstellen der Umgebung nicht gefunden wurden.

    Hier nun meine Frage:

    Kann ich mir eine restore.env selbst basteln?

    Kann ich sie aus einer E00.chk kopieren?

    Gibt es einen Befehl der diese Datei direkt erstellt?

    Ich freue mich über Deine Rückmeldung.

    Gruß Samuel

    Dienstag, 29. Dezember 2015 22:04
  • Moin,

    wie sieht denn da die Image-Sicherung aus? Kann es sein, dass da Exchange nicht bekannt ist?

    Bei einem Restore ist dann das Backup-Programm dafür verantwortlich, die Datenbank mit einer restore.env zu versorgen.


    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Mittwoch, 30. Dezember 2015 07:48
  • Ok, die Image-Sicherung hat eben den kompletten Server als Image wieder hergestellt. Darauf ist der Exchange mit einem 1a Zustand enthalten. Eine restore.env ist nicht enthalten.

    Selbst wenn ich mir die Datei bastle aus einer Vorlage aus dem Internet bleibt die Datenbank immer noch bei einem 'clean Shutdown'.

    Einige Anleitungen sprechen von einem 'Offline Backup' das ebenfalls in einem 'clean Shutdown' ist wo man die Logfiles nachträglich einspielen kann. Das funktioniert bei mir aber nicht.

    Wie kann ich weiter machen?

    Gruß Samuel

    Mittwoch, 30. Dezember 2015 09:18
  • Moin,

    zunächst wäre es mal gut zu wissen, warum das überhaupt passieren soll.

    Image ist kein Backup.

    ;)


    Gruß Norbert

    Mittwoch, 30. Dezember 2015 09:38
    Moderator
  • OK, mit unserer Backup Software (A...) haben wir täglich vom virtuellen Server eine Image-Sicherung gemacht. Dabei wurden vom Erfolg auch E-Mails versendet. Als die Sicherung eben nicht mehr lief wurden auch keine E-Mails mehr versendet. Deshalb wurde der Schaden erst später entdeckt.

    Das gesicherte Image wurde als isolierter Server wieder hergestellt, jedoch mit den fehlenden Tagen wo der Ausfall der Sicherung nicht bemerkt wurde. Diese fehlenden Tage habe ich als Transaction Logs verfügbar wo hin und wieder eine Log-Datei defekt ist. Bei diesen fehlenden Tagen sind eben E-Mails enthalten wo wir nicht darauf verzichten möchten. Diese E-Mails hätte ich gerne wieder hergestellt.

    Soviel zum Hintergrund.

    Mein Ziel ist es diese Transaction Logs in mehreren Replays einzuspielen.

    Kannst Du mir helfen?

    Mittwoch, 30. Dezember 2015 09:54