Datenbank Recovery nach Serverabsturz (aktualisiert 11.03.2012)

0

Es kann bei dem Betrieb eines Exchange Servers immer wieder zu Probleme kommen. Wichtig ist in dem Fall nur, dass Sie die richtigen Entscheidungen treffen andernfalls verlieren Sie Zeit oder im schlimmsten Fall Daten.

Bevor Sie anfangen zu handeln, nehmen Sie sich einen Zettel und schreiben Sie sich folgende Informationen auf.

Systeminformationen sammeln

  • letzte Sicherung vom ____._____.________
  • Was sagt der Eventlog
  • seit wann existiert der Fehler
  • was passierte in dem Zeitraum an den beteiligten System (Exchange, AD, Domain Controller, DNS-Server)
  • welchen Status hat die Datenbank (mounted/umounted)?
  • Prüfen Sie den freien Speicherplatz auf allen Laufwerken und beteiligten Systemen
  • Speichergruppen- oder Postfachproblem?
  • Gibt es Fehler/Probleme bei der DNS oder Wins Auflösung?
  • ist der Globale Katalog verfügbar (welcher DC hält den GC)
  • liegt ein Hardware defekt vor?
  • Reicht es ein Backup wiederherzustellen oder muss der aktuelle Datenbestand um jeden Preis gesichert werden

Nachdem Sie all diese Informationen zusammen getragen haben schauen Sie sich die betreffende Datenbank an.

1. Muss verhindert werden, dass weiterhin E-Mails auf dem betroffenen System eingehen?

Diese Frage ist gar nicht so uninteressant. Sollten Sie auf der Partition auf der die Log-Dateien liegen nicht mehr viel oder keinen Speicherplatz mehr haben, müssen Sie unter Umständen den Exchange Transport Dienst stoppen um zu vermeiden, dass die Festplatte ganz voll läuft oder Ihr Reparaturversuch, der unter Umständen einige Zeit dauern kann, gestört wird, weil auf einmal der Speicherplatz alle ist.

2. Dismounten Sie die Datenbank

Für fast alle Reparaturarbeiten ausgenommen einer Datenbank Wiederherstellung muss die DB offline genommen werden.

Machen Sie, insofern Sie genügend Speicherplatz haben, eine Sicherung der DB+check Datei sowie ALLER Logs der entsprechenden Speichergruppe. Achten Sie bei einem CCR darauf, dass Sie auch die E00.log erwischen, denn diese ist nur auf dem aktiven Knoten vorhanden. Eine Sicherung der Log-Dateien am passiven Knoten wäre damit nicht ausreichend!

3. Prüfen der Vollständigkeit der Transaktionslogs

Wenn alle Log-Dateien vorhanden sind, sieht die Ausgabe folgendermaßen aus:

C:Program FilesMicrosoftExchange ServerV14Bin>eseutil /ml "C:Program FilesMicrosoftExchange ServerV14MailboxMailbox Database 1030133071E00" | find /V "OK" 
Extensible Storage Engine Utilities for Microsoft(R) Exchange Server Version 14.00 Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating FILE DUMP mode...

Verifying log files...
      Base name: E00
No damaged log files were found.
Operation completed successfully in 0.703 seconds.

Fehlt eine Log-Datei, so wird diese ausgegeben.

C:Program FilesMicrosoftExchange ServerV14Bin>eseutil /ml "C:Program FilesMicrosoftExchange ServerV14MailboxMailbox Database 1030133071E00" | find /V "OK" Extensible Storage Engine Utilities for Microsoft(R) Exchange Server Version 14.00 Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating FILE DUMP mode...

Verifying log files...
      Base name: E00
      Missing log file: C:Program FilesMicrosoftExchange ServerV14MailboxM ailbox Database 1030133071E0000000008.log Operation terminated with error -528 (JET_errMissingLogFile, Current log file mi ssing) after 0.734 seconds.

Je nach Anzahl der Log-Dateien, dauert dieser Vorgang seine Zeit.

3. Konsistenz der Datenbank prüfen

C:Program FilesMicrosoftExchange ServerV14Bin>eseutil /mh "C:Program FilesMicrosoftExchange ServerV14MailboxMailbox Database 1030133071Mailbox Datab ase 1030133071.edb" | find /i "consistent"    Last Consistent: (0x0,0,0)  03/11/2012 09:18:2

Das Datum ermöglicht Ihnen, festzustellen wann die Datenbank das letzte mal konsistent war. Dies kann für die Auswahl des Backups von interesse sein. Idealerweise war die DB beim letzten Dismounten konsistent.

4. shutdown status der Datenbank prüfen

C:Program FilesMicrosoftExchange ServerV14Bin>eseutil /mh "C:Program FilesMicrosoftExchange ServerV14MailboxMailbox Database 1030133071Mailbox Datab ase 1030133071.edb" | find /i "shutdown"
             State: Clean Shutdown

Ein Dirty Shutdown ist immer schlecht. Liegt dieser Fall vor, sollten Sie folgende Schritte versuchen

  • Log-Replay
  • Defragmentierung
  • Soft Repair
  • Hard Repair (es gehen sehr wahrscheinlich Daten verloren)

5. prüfen von wann das letzte Backup ist – ist es auch physikalisch noch vorhanden?

Die grün markierten Stellen sind noch einen Blick wert.

eseutil /mh "c:Program FilesMicrosoftExchange ServerV14MailboxMailbox Database 1030133071Mailbox Database 1030133071.edb"

Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 14.00
Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating FILE DUMP mode...
         Database: C:Program FilesMicrosoftExchange ServerV14MailboxMailbx Database 1030133071Mailbox Database 1030133071.edb

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

Fields:
        File Type: Database
         Checksum: 0x10bb66b
   Format ulMagic: 0x89abcdef
   Engine ulMagic: 0x89abcdef
Format ulVersion: 0x620,17
Engine ulVersion: 0x620,17
Created ulVersion: 0x620,17
     DB Signature: Create time:03/11/2012 09:18:23 Rand:726187 Computer:
         cbDbPage: 32768
           dbtime: 15941 (0x3e45)
            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
         Shadowed: Yes
       Last Objid: 307
     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: (0x0,0,0)  03/11/2012 09:18:26
      Last Attach: (0x0,0,0)  03/11/2012 09:18:23
      Last Detach: (0x0,0,0)  03/11/2012 09:18:26
             Dbid: 2
    Log Signature: Create time:00/00/1900 00:00:00 Rand:0 Computer:
       OS Version: (6.1.7601 SP 1 NLS 60101.60101)

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: 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: 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.109 seconds.

6. prüfen welche Logs für eine Konsistente DB benötigt werden

eseutil /mh "D:programmeExchsrvrMDBDATApriv1.edb" | find /i "Log Required"
Log Required: 0-0 (0x0-0x0) eseutil /mh "D:programmeExchsrvrMDBDATApriv1.stm" | find /i "Log Required"
Log Required: 0-0 (0x0-0x0)

In diesem Fall werden keine Log-Dateien benötigt. Steht bei „Log Required“ etwas anderes, stellen Sie sicher das die Log-Dateien alle noch vorhanden sind.

Sollten Sie wirklich keine Logs für eine konsistente DB benötigen und die Log Partition lediglich voll gelaufen sein, so ist es das beste die Log Datei Sequenz zurücksetzten.

7. Checksumme prüfen

Eine Überprüfung der Checksumme kann auch noch evtl. Fehler zu Tage befördern. Zudem kann man hier gleich die Lese-Performance der DB sehen.

C:Program FilesMicrosoftExchange ServerV14Bin>eseutil /k "C:Program FilesMicrosoftExchange ServerV14MailboxMailbox Database 1030133071Mailbox Database 1030133071.edb"

Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 14.00
Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating CHECKSUM mode...'
        Database: C:Program FilesMicrosoftExchange ServerV14MailboxMailbox Database 1030133071Mailbox Database 1030133071.edb
  Temp. Database: TEMPCHKSUM4736.EDB

File: C:Program FilesMicrosoftExchange ServerV14MailboxMailbox D

                     Checksum Status (% complete)
          0    10   20   30   40   50   60   70   80   90  100
          |----|----|----|----|----|----|----|----|----|----|
          ...................................................

1026 pages seen
0 bad checksums
0 correctable checksums
667 uninitialized pages
0 wrong page numbers
0x3e45 highest dbtime (pgno 0xf7)
513 reads performed
32 MB read
1 seconds taken
32 MB/second
5172 milliseconds used
10 milliseconds per read
109 milliseconds for the slowest read
0 milliseconds for the fastest read

 

8. DB defragmentieren

Bei der Online-Wartung werden die freien Seiten innerhalb der Datenbank zwar gelöscht, jedoch werden diese nicht aus der DB entfernt. Eine Datenbank wird also immer größer, bis eine Offline Defragmentierung durchgeführt wird. Hierbei werden die leeren Seitenbereiche physikalisch wirklich entfernt.

C:Program FilesMicrosoftExchange ServerV14Bin>eseutil /d "C:Program FilesMicrosoftExchange ServerV14MailboxMailbox Database 1030133071Mailbox Database 1030133071.edb"

Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 14.00
Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating DEFRAGMENTATION mode...
            Database: C:Program FilesMicrosoftExchange ServerV14MailboxMailbox Database 1030133071Mailbox Database 1030133071.edb

                  Defragmentation Status (% complete)'

          0    10   20   30   40   50   60   70   80   90  100
          |----|----|----|----|----|----|----|----|----|----|
          ...................................................

Moving 'TEMPDFRG4596.EDB' to 'C:Program FilesMicrosoftExchange ServerV14MailboxMailbox Database 1030133071Mailbox Database 1030133071.edb'... DONE!
Note:
  It is recommended that you immediately perform a full backup
  of this database. If you restore a backup made before the
  defragmentation, the database will be rolled back to the state
  it was in at the time of that backup.

Operation completed successfully in 3.156 seconds.

8. Log Replay

Um die Datenbank auf den aktuellen Stand zu bringen, können die Log-Dateien manuell eingespielt werden.

C:Program FilesMicrosoftExchange ServerV14MailboxMailbox Database 1030133071>eseutil /R E00 /i /d"C:Program FilesMicrosoftExchange ServerV14MailboxMailbox Database 1030133071Mailbox Database 1030133071.edb"

Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 14.00
Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating RECOVERY mode...
    Logfile base name: E00
            Log files:
         System files:
   Database Directory: C:Program FilesMicrosoftExchange ServerV14MailboxMailbox Database 1030133071Mailbox Database 1030133071.edb

Performing soft recovery...

Operation completed successfully in 0.63 seconds.

Log Datei Sequenz zurück setzten

Um die Log Sequenz zurück zu setzten müssen Sie sicherstellen, dass die DB in einem „Clean Shutdown“ Status ist und keine weiteren Log Dateien benötigt werden. Anschließend verschieben Sie alle Log-Dateien sowie chk Dateien in einen anderen Ordner und mounten Sie die DB erneut. Exchange fängt nun an neue log-Dateien mit von bei Null an beginnenden Sequenznummer zu erstellen.

restore.env

Haben Sie eine Datenbank aus einer Sicherung wiederhergestellt und die Log-Dateien noch nicht replayed können Sie – insofern nur die wiederhergestellten Log-Dateien replayed werden müssen – dies anhand der restore.env machen.

eseutil /cc /T restore.env

soft repair (Eseutil)

  1. Heben Sie die Bereitstellung des Öffentlichen- sowie des Postfachspeichers auf.
  2. starten Sie dem soft repair Vorgang
    eseutil /r E00 /l ..MDBDATA
  3. Prüfen Sie den Status sowie die Checksumme der Datenbank erneut
  4. Informationsspeicher wieder bereitstellen
  5. Eventlog & Systemmanager überprüfen
    Hard repair (Eseutil)
    Das Hard repair sollte nur dann verwendet werden wenn:
    nicht mehr alle Logfiles zur Reparatur vorhanden sind
    sich die Datenbank trotz aller benötigten Logfiles nicht bereitstellen lässt

hard repair (eseutil)

Es gehen bei einem hard repair in der Regel Daten verloren!

  1. Heben Sie die Bereitstellung aller zu reparierenden Informationsspeicher auf.
  2. reparieren Sie die Datenbanken (Exchange 2007 hat keine stm-Dateien mehr)
    eseutil /p ..mdbdatapriv1.edb /s ..mdbdatapriv1.stm
    eseutil /p ..mdbdatapub1.edb /s ..mdbdatapub1.stm
  3. Prüfen Sie den Status der Datenbanken
    eseutil /mb ..mdbdatapriv1.edb
  4. Anschließend die Dateien *.chk, *.log löschen so das nur noch die eigentlichen Datenbanken vorhanden sind.
  5. DB mit ISInteg auf Integrität prüfen
  6. Informationsspeicher wieder bereitstellen
  7. Eventlog & Systemmanager überprüfen

Integrität prüfen (ISInteg)

  1. Bereitstellung des Informationsspeichers aufheben
  2. Integrität prüfen (es wird an der DB nichts verändert)
    isinteg -s -test alltests
  3. Wenn Fehler gefunden wurden, dann reparieren
    isinteg –s -fix -test alltests
  4. Informationsspeicher wieder bereitstellen
  5. Eventlog & Systemmanager überprüfen

Hinweis zum CCR

  •  nur auf dem aktiven Knoten sind alle Log-Dateien vorhanden. Auf dem Passiven fehlt die E0x.log
  • Ein Backup auf dem aktiven Knoten bei einer nicht konsistentes des CCR bringt Ihnen nichts außer einem Backup. Die Log-Dateien bleiben aller erhalten. Erst nach einer erfolgreiche Replizierung aller Logs auf den passiven Knoten werden die nicht mehr benötigten logs gelöscht.
  • Haben Sie Probleme mit einer DB halten Sie zuerst die Speichergruppenreplikation an. Dies ermöglicht Ihnen auf dem aktiven Knoten das Problem zu lösen, während Sie auf dem passiven ein Backup der Daten haben. Dies geht allerdings nur, wenn die Log-Partition der entsprechenden Speichergruppe noch über ausreichend Plattenplatz verfügt.
Teilen.

Über den Autor

Seit der Ausbildung zum Fachinformatiker Systemintegration (2002-2005) bei der DaimlerChrysler AG, beruflich im Bereich der E-Mail Kommunikation (Exchange, Linux) sowie des ActiveDirectory, mit entsprechenden Zertifizierungen (MCSE 2003, MCITP Ent.-Admin 2008, MCSE 2012, LPIC 1-3) tätig. Abgeschlossenes Studium zum Master of Science der IT-Management an der FOM sowie zertifizierter Datenschutzbeauftragter. Aktuell im Projektmanagement tätig.

Antworten