none
Exchange 2010 - Log Dateien versehentlich gelöscht RRS feed

  • Frage

  • Hallo Team,

    habe wegen Platzründen aus Dummheit die Log-Dateien gelöscht und auch den Papierkorb geleert. Nun erhalte ich folgende Fehler im Windows Event-Log für Anwendungen:

    •  Information Store (2236) Mailbox Database 1617125503: Fehler - 1811 (0xfffff8ed) beim Öffnen von Protokolldatei C:\Program Files\Microsoft\Exchange Server\V14\Mailbox\Mailbox Database 1617125503\E0000000009.log

    •  Information Store (2236) Public Folder Database 1617125503: Fehler - 1811 (0xfffff8ed) beim Öffnen von Protokolldatei C:\Program Files\Microsoft\Exchange Server\V14\Mailbox\ Public Folder Database\E01000038E8.log

    Die Daten konnte ich mit Recovery-Tools wieder herstellen, jedoch haben diese nun andere Dateinamen. Auch das komplette Auslesen der Master File Table brachte nur die Namen der gelöschten Dateien, z.B. $R9IYFXE.log. Das Ausprobieren welche die gesuchte Log-Datei ist gestaltet sich bei über 92.000 Dateien etwas schwierig.

    Nun suche ich nach folgenden Möglichkeiten:

    •  Tool zum Wiederherstellen der ursprünglichen Dateinamen, oder
    •  einer andern Möglichkeit die Protokolle wieder herzustellen, oder
    •  mit Verzicht auf den Inhalt der Protokolldateien, den Betrieb von Exchange wieder herzustellen.

    Über eine schnelle Hilfe würde ich mich freuen.

    ITSam

    Mittwoch, 26. Dezember 2012 22:00

Antworten

  • Moin,

    vielen Dank für Deine Antwort. Ich werde Deine Lösung in ein paar Minuten ausprobieren. Aber noch die Frage: was meinst Du mit 'dem fortlaufenden Zähler'?

    Jede LOG-Datei besteht aus zwei Teilen: Dem Prefix (3 Stellen) und einem fortlaufen Hexadezimalen Zähler (8 Stellen).

    Wenn ich die Dateien mit einem anderen Namen versehe wie er vorher war, ist das dann egal, oder muss ich den original Dateinamen herausfinden?

    Den findest Du ja heraus, mit eseutil /ml.

    Nehmen wir an, dass Die eseutil /ml folgendes zeigt: lGeneration: 61205 (0xEF15). Dann ist das der Zähler.

    Außerdem kannst Du anhand der Datei "E00.log" das Prefix sehen.

    Die gerettete Datei, die Du Dir mit eseutil /ml angesehen hast, müsste dann"E000000EF15.log" heißen:   "E00" + "EF15" rechtsbündig auf 8 Stellen aufgefüllt.

    Das ganze System muss man für Rettungen verstanden haben, was der Grund ist, warum Dir schon im ersten Post geraten wurde, einen Fachmann dazuzuholen. ;)

    Du musst Dir im klaren sein, dass alle Rettungsversuche auch komplett schiefgehen können und ein Datenverlust droht, der höher als 18 MB ist.


    Grüße aus Berlin schickt Robert
    MVP Exchange Server
    • Als Antwort markiert Alex Pitulice Donnerstag, 3. Januar 2013 12:13
    Donnerstag, 27. Dezember 2012 17:20

Alle Antworten

  • Hallo ITSAM77,

    erstelle bitte zunächst einmal eine Kopie der noch vorhandenen Daten (Logfiles und Datenbanken) auf einer anderen Festplatte.

    Poste danach mal den Output von (Ggf. Pfad zur EDB anpassen!):

    eseutil.exe /mh "C:\Program Files\Microsoft\Exchange Server\V14\Mailbox\Mailbox Database 1617125503\Mailbox Database 1617125503.edb"

    eseutil.exe /mh "C:\Program Files\Microsoft\Exchange Server\V14\Mailbox\ Public Folder Database\Public Folder Database.edb"

    Auch wenn wir Dir hier vielleicht im Laufe des Tages noch helfen können, würde ich Dir empfehlen einen Dienstleister zu beauftragen oder einen Call bei PSS aufmachen. Das ist vermutlich der schnellste und sicherere Weg. Vor allem kann jemand mit Dir zusammen auf das System schauen.

    VG, Timo

    Donnerstag, 27. Dezember 2012 07:10
  • Hallo Timo,

    danke für Deine Hilfe. Ich habe die beiden Ordner ‚Mailbox Database 1617125503‘ und ‚Public Folder Database‘ auf ein anderes Laufwerk gesichert.

    Hier die Ergebnisse von Eseutil /mh

    Initiating FILE DUMP mode...
             Database: C:\Program Files\Microsoft\Exchange Server\V14\Mailbox\Mailbox Database 1617125503\Mailbox Database 1617125503.edb


    DATABASE HEADER:
    Checksum Information:
    Expected Checksum: 0x0e064cd0
      Actual Checksum: 0x0e064cd0

    Fields:
            File Type: Database
             Checksum: 0xe064cd0
       Format ulMagic: 0x89abcdef
       Engine ulMagic: 0x89abcdef
     Format ulVersion: 0x620,17
     Engine ulVersion: 0x620,17
    Created ulVersion: 0x620,17
         DB Signature: Create time:01/04/2011 13:56:27 Rand:5765382 Computer:
             cbDbPage: 32768
               dbtime: 52193809 (0x31c6a11)
                State: Dirty Shutdown
         Log Required: 61186-61204 (0xef02-0xef14)
        Log Committed: 0-61205 (0x0-0xef15)
       Log Recovering: 0 (0x0)
      GenMax Creation: 12/24/2012 10:15:38
             Shadowed: Yes
           Last Objid: 6013
         Scrub Dbtime: 0 (0x0)
           Scrub Date: 00/00/1900 00:00:00
         Repair Count: 0
          Repair Date: 00/00/1900 00:00:00
     Old Repair Count: 0
      Last Consistent: (0xEE82,8,1F)  12/24/2012 08:27:19
          Last Attach: (0xEE83,9,86)  12/24/2012 07:54:49
          Last Detach: (0x0,0,0)  00/00/1900 00:00:00
                 Dbid: 1
        Log Signature: Create time:01/04/2011 13:56:25 Rand:5771115 Computer:
           OS Version: (6.1.7600 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

    Previous Incremental Backup:
            Log Gen: 0-0 (0x0-0x0)
               Mark: (0x0,0,0)
               Mark: 00/00/1900 00:00:00

    Previous Copy Backup:
            Log Gen: 33759-33766 (0x83df-0x83e6) - OSSnapshot
               Mark: (0x83E7,8,16)
               Mark: 07/20/2012 22:20:58

    Previous Differential Backup:
            Log Gen: 0-0 (0x0-0x0)
               Mark: (0x0,0,0)
               Mark: 00/00/1900 00:00:00

    Current Full Backup:
            Log Gen: 0-0 (0x0-0x0)
               Mark: (0x0,0,0)
               Mark: 00/00/1900 00:00:00

    Current Shadow copy backup:
            Log Gen: 0-0 (0x0-0x0)
               Mark: (0x0,0,0)
               Mark: 00/00/1900 00:00:00

         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
    Current checksum start Date: 00/00/1900 00:00:00
          Current checksum page: 0


    Operation completed successfully in 0.297 seconds.

    Und hier für die öffentlichen Ordner: 

    Initiating FILE DUMP mode...
             Database: C:\Program Files\Microsoft\Exchange Server\V14\Mailbox\Public Folder Database\Public Folder Database.edb


    DATABASE HEADER:
    Checksum Information:
    Expected Checksum: 0x0d2e4648
      Actual Checksum: 0x0d2e4648

    Fields:
            File Type: Database
             Checksum: 0xd2e4648
       Format ulMagic: 0x89abcdef
       Engine ulMagic: 0x89abcdef
     Format ulVersion: 0x620,17
     Engine ulVersion: 0x620,17
    Created ulVersion: 0x620,17
         DB Signature: Create time:01/05/2011 15:27:58 Rand:43855437 Computer:
             cbDbPage: 32768
               dbtime: 3453393 (0x34b1d1)
                State: Dirty Shutdown
         Log Required: 14568-14568 (0x38e8-0x38e8)
        Log Committed: 0-14569 (0x0-0x38e9)
       Log Recovering: 0 (0x0)
      GenMax Creation: 12/24/2012 08:27:06
             Shadowed: Yes
           Last Objid: 5253
         Scrub Dbtime: 0 (0x0)
           Scrub Date: 00/00/1900 00:00:00
         Repair Count: 0
          Repair Date: 00/00/1900 00:00:00
     Old Repair Count: 0
      Last Consistent: (0x38E7,8,1F)  12/24/2012 08:26:54
          Last Attach: (0x38E8,9,86)  12/24/2012 08:27:04
          Last Detach: (0x0,0,0)  00/00/1900 00:00:00
                 Dbid: 1
        Log Signature: Create time:01/05/2011 15:27:56 Rand:43862934 Computer:
           OS Version: (6.1.7600 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

    Previous Incremental Backup:
            Log Gen: 0-0 (0x0-0x0)
               Mark: (0x0,0,0)
               Mark: 00/00/1900 00:00:00

    Previous Copy Backup:
            Log Gen: 11549-11550 (0x2d1d-0x2d1e) - OSSnapshot
               Mark: (0x2D1F,8,16)
               Mark: 07/20/2012 22:20:58

    Previous Differential Backup:
            Log Gen: 0-0 (0x0-0x0)
               Mark: (0x0,0,0)
               Mark: 00/00/1900 00:00:00

    Current Full Backup:
            Log Gen: 0-0 (0x0-0x0)
               Mark: (0x0,0,0)
               Mark: 00/00/1900 00:00:00

    Current Shadow copy backup:
            Log Gen: 0-0 (0x0-0x0)
               Mark: (0x0,0,0)
               Mark: 00/00/1900 00:00:00

         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
    Current checksum start Date: 00/00/1900 00:00:00
          Current checksum page: 0

    Operation completed successfully in 0.93 seconds.

    Ich würde mich freuen wenn Du mir helfen könntest.

    Grüße ITSam

    Donnerstag, 27. Dezember 2012 07:48
  • Moin,

    also:

    Initiating FILE DUMP mode...
             Database: C:\Program Files\Microsoft\Exchange Server\V14\Mailbox\Mailbox Database 1617125503\Mailbox Database 1617125503.edb
                State: Dirty Shutdown
         Log Required: 61186-61204 (0xef02-0xef14)

    da fehlen also 18 Log-Dateien, das sind 18 MB-Daten, die bei einem Reparatur verloren gehen.

    Hier allerdings:

    Initiating FILE DUMP mode...
             Database: C:\Program Files\Microsoft\Exchange Server\V14\Mailbox\Public Folder Database\Public Folder Database.edb
                State: Dirty Shutdown
         Log Required: 14568-14568 (0x38e8-0x38e8)

    fehlt nur eine Log-Datei, also 1 MB an Daten.

    Du kannst nun die DB reparieren, dann fehlen die oben erwähnten Daten.

    Oder Du findest die Daten noch irgendwo.


    Grüße aus Berlin schickt Robert
    MVP Exchange Server
    Donnerstag, 27. Dezember 2012 09:08
  • Hallo Robert,

    vielen Dank für Deine Antwort. Ich konnte alle Protokolldateien wiederherstellen. Allerdings wurde wegen dem Papierkorb die Dateinahmen geändert und ich weiß nicht mehr welche Datei wie umbenannt werden muss.

    Steht denn in der Datei selbst auch der Dateiname der Log-Datei, so wie der Pfad auch darin steht? In manchen Protokolldateien kann man auch etwas lesen, aber in den meisten ist der Inhalt nicht lesbar, zumindest für Notepad ++, auch in HEX. Wenn ich den Dateinamen aus dem Inhalt lesen könnte, oder den original Dateinamen wiederherstellen könnte, wäre ich in der Lage die Logdateien wieder herzustellen.

    Über eine Antwort würde ich mich freuen.

    Grüße

    ITSAM

    Donnerstag, 27. Dezember 2012 11:34
  • Hallo Team,

    eseutil /ml E00.log kann die Informationen von Log-Dateien lesen:

          Base name: E00
          Log file: E00.log
          lGeneration: 61205 (0xEF15)
          Checkpoint: (0x9,2EE,1FF)
          creation time: 12/24/2012 10:15:38
          prev gen time: 12/24/2012 09:51:27...

    Wenn ich mit dem Texteditor die Datei öffne erhalte ich nur:

    Èkcï... und viele weitere wirre Zeichen.

    Nun möchte ich mit einer anderen Software die Log Header Information auslesen um bei meinen wiederhergestellten Daten den richtigen Log-File-Namen zu finden.

    Über eine schnelle Antwort würde ich mich freuen

    Grüße ITSam

    Donnerstag, 27. Dezember 2012 14:16
  • Du hast doch die Nummer schon gefunden:

    eseutil /ml E00.log kann die Informationen von Log-Dateien lesen:

          lGeneration: 61205 (0xEF15)

    HIER steht sie.

    Schau Dir mit eseutil /ml die wiederhergestellten Dateien an und benenne sie mit dem fortlaufenden Zähler, den Du hier siehst.

    Danach probierst Du, die LOG-Files mit "eseutil /r Exx" einzuarbeiten.

    Über eine schnelle Antwort würde ich mich freuen

    Dann solltest Du den Support anrufen. Ein Forum ist zwischen den Jahren sicher kein guter Ort, um schnelle Hilfe zu bekommen.


    Grüße aus Berlin schickt Robert
    MVP Exchange Server
    Donnerstag, 27. Dezember 2012 16:54
  • Hallo Robert,

    vielen Dank für Deine Antwort. Ich werde Deine Lösung in ein paar Minuten ausprobieren. Aber noch die Frage: was meinst Du mit 'dem fortlaufenden Zähler'? Wenn ich die Dateien mit einem anderen Namen versehe wie er vorher war, ist das dann egal, oder muss ich den original Dateinamen herausfinden?

    Der Tipp mit dem Support ist ok, aber ich werde erst einmal alles selbst geben um die Situation zu meistern bevor ich die Notbremse ziehe. Dabei freue ich mich über Support vom Forum :-)))

    Vielen vielen Dank für Eure Hilfe.

    Grüße ITSam

    Donnerstag, 27. Dezember 2012 17:08
  • Moin,

    vielen Dank für Deine Antwort. Ich werde Deine Lösung in ein paar Minuten ausprobieren. Aber noch die Frage: was meinst Du mit 'dem fortlaufenden Zähler'?

    Jede LOG-Datei besteht aus zwei Teilen: Dem Prefix (3 Stellen) und einem fortlaufen Hexadezimalen Zähler (8 Stellen).

    Wenn ich die Dateien mit einem anderen Namen versehe wie er vorher war, ist das dann egal, oder muss ich den original Dateinamen herausfinden?

    Den findest Du ja heraus, mit eseutil /ml.

    Nehmen wir an, dass Die eseutil /ml folgendes zeigt: lGeneration: 61205 (0xEF15). Dann ist das der Zähler.

    Außerdem kannst Du anhand der Datei "E00.log" das Prefix sehen.

    Die gerettete Datei, die Du Dir mit eseutil /ml angesehen hast, müsste dann"E000000EF15.log" heißen:   "E00" + "EF15" rechtsbündig auf 8 Stellen aufgefüllt.

    Das ganze System muss man für Rettungen verstanden haben, was der Grund ist, warum Dir schon im ersten Post geraten wurde, einen Fachmann dazuzuholen. ;)

    Du musst Dir im klaren sein, dass alle Rettungsversuche auch komplett schiefgehen können und ein Datenverlust droht, der höher als 18 MB ist.


    Grüße aus Berlin schickt Robert
    MVP Exchange Server
    • Als Antwort markiert Alex Pitulice Donnerstag, 3. Januar 2013 12:13
    Donnerstag, 27. Dezember 2012 17:20