Benutzer mit den meisten Antworten
Exchange 2010 - Log Dateien versehentlich gelöscht

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
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
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
-
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: 0x0e064cd0Fields:
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:00Previous Incremental Backup:
Log Gen: 0-0 (0x0-0x0)
Mark: (0x0,0,0)
Mark: 00/00/1900 00:00:00Previous Copy Backup:
Log Gen: 33759-33766 (0x83df-0x83e6) - OSSnapshot
Mark: (0x83E7,8,16)
Mark: 07/20/2012 22:20:58Previous Differential Backup:
Log Gen: 0-0 (0x0-0x0)
Mark: (0x0,0,0)
Mark: 00/00/1900 00:00:00Current Full Backup:
Log Gen: 0-0 (0x0-0x0)
Mark: (0x0,0,0)
Mark: 00/00/1900 00:00:00Current Shadow copy backup:
Log Gen: 0-0 (0x0-0x0)
Mark: (0x0,0,0)
Mark: 00/00/1900 00:00:00cpgUpgrade55Format: 0
cpgUpgradeFreePages: 0
cpgUpgradeSpaceMapPages: 0ECC 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: noneLast 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: 0x0d2e4648Fields:
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:00Previous Incremental Backup:
Log Gen: 0-0 (0x0-0x0)
Mark: (0x0,0,0)
Mark: 00/00/1900 00:00:00Previous Copy Backup:
Log Gen: 11549-11550 (0x2d1d-0x2d1e) - OSSnapshot
Mark: (0x2D1F,8,16)
Mark: 07/20/2012 22:20:58Previous Differential Backup:
Log Gen: 0-0 (0x0-0x0)
Mark: (0x0,0,0)
Mark: 00/00/1900 00:00:00Current Full Backup:
Log Gen: 0-0 (0x0-0x0)
Mark: (0x0,0,0)
Mark: 00/00/1900 00:00:00Current Shadow copy backup:
Log Gen: 0-0 (0x0-0x0)
Mark: (0x0,0,0)
Mark: 00/00/1900 00:00:00cpgUpgrade55Format: 0
cpgUpgradeFreePages: 0
cpgUpgradeSpaceMapPages: 0ECC 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: noneLast checksum finish Date: 00/00/1900 00:00:00
Current checksum start Date: 00/00/1900 00:00:00
Current checksum page: 0Operation completed successfully in 0.93 seconds.
Ich würde mich freuen wenn Du mir helfen könntest.
Grüße ITSam
-
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 -
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
-
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
-
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 -
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
-
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
-
Hallo ITSam,
ist dieser Thread noch aktuell? Bist Du hier inzwischen weitergekommen?
Gruss,
AlexAlex Pitulice, MICROSOFT
Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.