2011 - Exchange-Protokolldateien fehlen nach Stromausfall

[iDiddi 27]

Hallo Leute,

 

jetzt haben wir hier aber ein dickes Problem:

 

Nach einem Stromausfall (Wackelkontakt am Stromstecker der USV :eek: ) bekomme ich die Mailbox Store nicht mehr hoch (dirty shutdown).

 

Lt. Log fehlen die zwei letzten Protokolldateien (79-84 werden benötigt, bis 82 ist vorhanden).

 

Da sie ja nicht da sind und die letzte Sicherung 2 Stunden her ist, bleibt mir nix anderes übrig, als mit ESEUTIL zu arbeiten und die Protokolle mit ESEUTIL /P abzuschneiden und danach ISINTEG auszuführen, oder?

 

So wie ich das noch im Kopf habe, gehen mir alle Protokolle (auch die vorhandenen) verloren, richtig?

 

Gibt es keine Möglichkeit, wenigstens diese zu erhalten?

 

Danke vorab

[iDiddi 27]

Hier mal das Ergebnis von ESEUTIL /MH:

 

Extensible Storage Engine Utilities for Microsoft® Exchange Server

Version 14.01

Copyright © Microsoft Corporation. All Rights Reserved.

 

Initiating FILE DUMP mode...

Database: D:\Program Files\Microsoft\Exchange Server\V14\Mailbox\Mailbox Database\Mailbox Database.edb

 

 

DATABASE HEADER:

Checksum Information:

Expected Checksum: 0x09a099ba

Actual Checksum: 0x09a099ba

 

Fields:

File Type: Database

Checksum: 0x9a099ba

Format ulMagic: 0x89abcdef

Engine ulMagic: 0x89abcdef

Format ulVersion: 0x620,17

Engine ulVersion: 0x620,17

Created ulVersion: 0x620,17

DB Signature: Create time:02/18/2012 13:47:47 Rand:950775 Computer:

cbDbPage: 32768

dbtime: 32117885 (0x1ea147d)

State: Dirty Shutdown

Log Required: 69753-69764 (0x11079-0x11084)

Log Committed: 0-69765 (0x0-0x11085)

Log Recovering: 69763 (0x11083)

GenMax Creation: 03/12/2012 14:14:42

Shadowed: Yes

Last Objid: 3509

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: (0x5F8D,25E,1BC) 02/23/2012 07:44:48

Last Attach: (0x5F8E,9,86) 02/23/2012 07:44:51

Last Detach: (0x0,0,0) 00/00/1900 00:00:00

Dbid: 1

Log Signature: Create time:02/18/2012 13:47:47 Rand:916504 Computer:

OS Version: (6.1.7600 SP 0 NLS ffffffff.ffffffff)

 

Previous Full Backup:

Log Gen: 68067-68081 (0x109e3-0x109f1) - OSSnapshot

Mark: (0x109F2,8,16)

Mark: 03/11/2012 23:00:43

 

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: 0-0 (0x0-0x0)

Mark: (0x0,0,0)

Mark: 00/00/1900 00:00:00

 

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: found (1)

Last Bad Checksum Error Date: 03/12/2012 14:22:28

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.47 seconds.

 

[##mur 10]

Hallo,

 

wenn die letzte Sicherung 2 Stunden her ist dann restore zu diesem Zeitpunkt. Somit verlierst du ja dann maximal 2 Stunden und da sollte jeder mit leben können.

 

cu

 

Maik

[iDiddi 27]

Das ist aber nur 'ne Schattenkopie-Sicherung der Transaktionslogs. Die Windows-Sicherung ist von gestern. Das ist schon einiges, was weg wäre, da das Mailaufkommen dort sehr hoch ist.

 

Es muss doch irgendeine Möglichkeit geben, die noch vorhanden Logs einzulesen. Sind ja alle bis auf 2 da.

 

Und warum fehlen die eigentlich? Der müsste die doch wenigstens korrupt auf die Platte geschrieben haben. Ist schon merkwürdig. Beim 2010er ist das jetzt schon das zweite Mal, dass so was nach einem Reset passiert.

[tcpip 12]

Ich denke das hat sich bei 2010 nicht geändert.

 

Also müßte es der Befehl Eseutil /R bzw. /P sein wenn Protokolle fehlen.

 

Gruß

 

tcpip

[iDiddi 27]

Ich denke das hat sich bei 2010 nicht geändert.

 

Also müßte es der Befehl Eseutil /R bzw. /P sein wenn Protokolle fehlen.

 

Gruß

 

tcpip

Danke Dir für Deine Antwort. Das mit Eseutil ist klar. /R nimmt man für Soft Recovering, wenn alle Protokolle vorhanden sind. /P ist fürs Hard Recovering. Dabei werden aber doch alle Protokolle abgeschnitten.

 

Ich frage mich jetzt nur, warum es keine Möglichkeit gibt, die Protokolle einzeln einzulesen. Was nützen mir die Transaktionsprotokolle bei einem Backup von gestern, wenn das letzte Protokoll bei einem Ausfall ins Nirvana verschwindet und ich dadurch Datenverlust in Kauf nehmen muss?

 

Na ja. Ich hab die DB jetzt mit /P + /D in einen clean status versetzt, vorher aber die letzten Mails an den Clients in eine PST-Datei exportiert.

 

Aber was macht man in größeren Umgebungen? Von DAG jetzt mal abgesehen.

 

Ach ja: Hätte fast isinteg ausgeführt und mich gewundert, dass nix passiert. Hab aber entdeckt, dass es ab 2010 dafür ein cmdlet gibt:

 

MSXFAQ.DE - ISINTEG

[iDiddi 27]

Kein Exchange-Crack im Board unterwegs? Wo sind denn hier die ganzen Norberts und Roberts ;) :)

 

Für alle, die vor dem gleichen Problem stehen, habe ich auf MSExchange.org einen interessanten Artikel (2 Teile) gefunden:

 

Eseutil - Part 1: Database Technologies

 

 

Eseutil - Part 2: Eseutil Switches

 

Leider beantwortet er mir aber auch nicht die Frage, ob die vorhandenen Protokolle noch eingelesen werden können. Aber dafür wird detailliert beschrieben, was es mit der Exchange-Datenbank und ihren Transaktionsprotokollen auf sich hat und wie ESEUTIL arbeitet.

 

Dort steht auch, dass die Chance eines korrupten Logs bei einem Crash bei 1 % liegt:

 

In 99% of all cases the database are normally mounted in such a scenario, but for the remaining 1%, the ESEUTIL tool can be very useful. Also bad things can happen with the database pages on the physical hard disk, or in the disk controller. Then pages get corrupted and usually result in a -1018 error in the event log. ESEUTIL can help you in this case as well.

 

Na, da haben wir ja mal wieder so richtig in den Donnerbalken gegriffen :cry:

 

Ich mach jetzt einfach mal einen Haken für mich dahinter. Danke an diejenigen, die versucht haben, mir zu helfen :)

 

 

 

EDIT: Kleine Selbstkorrektur.

 

Hätte fast isinteg ausgeführt und mich gewundert, dass nix passiert. Hab aber entdeckt, dass es ab 2010 dafür ein cmdlet gibt:

Ab Exchange 2010 SP1, wenn man es genau nimmt ;)