Acties:
  • 0 Henk 'm!

  • Urk
  • Registratie: Maart 2000
  • Laatst online: 30-08 23:13
Ik heb iets vreemds bij een klant met een Exchange 2010 server hebben we een database restore moeten doen met Backup EXEC 15 (backup gemaakt met Backup EXEC 2012). Die restore job gaat prima en heb een redirected restore naar folder gedaan. Zodra ik die map kopieer naar de Exchange server en met ESEUTIL een check doe op de database met:

eseutil /mh ExchangeDB.edb

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
E:\Exchange Databases>esentutl /mh "Primairy Mailbox Database.edb"

Extensible Storage Engine Utilities for Microsoft(R) Windows(R)
Version 6.1
Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating FILE DUMP mode...
         Database: Primairy Mailbox Database.edb

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

Fields:
        File Type: Database
         Checksum: 0x13fa140d
   Format ulMagic: 0x89abcdef
   Engine ulMagic: 0x89abcdef
 Format ulVersion: 0x620,17
 Engine ulVersion: 0x620,17
Created ulVersion: 0x620,17
     DB Signature: Create time:06/16/2015 18:18:33 Rand:11872475 Computer:
         cbDbPage: 32768
           dbtime: 205368719 (0xc3dad8f)
            State: Dirty Shutdown
     Log Required: 156147-156166 (0x261f3-0x26206)
    Log Committed: 0-156167 (0x0-0x26207)
  GenMax Creation: 03/17/2016 21:29:31
         Shadowed: Yes
       Last Objid: 51147
     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: (0x25B96,8,2E)  03/17/2016 06:42:53
      Last Attach: (0x25B97,9,86)  03/17/2016 06:42:55
      Last Detach: (0x0,0,0)  00/00/1900 00:00:00
             Dbid: 1
    Log Signature: Create time:06/16/2015 16:52:30 Rand:6674031 Computer:
       OS Version: (6.1.7601 SP 1 NLS ffffffff.ffffffff)

Previous Full Backup:
        Log Gen: 153835-153855 (0x258eb-0x258ff) - OSSnapshot
           Mark: (0x25900,8,16)
           Mark: 03/15/2016 21:30:51


Krijg ik de zien dat de database in Dirty shutdown state is. Vreemd want ten tijde van die backup was de Exchange database zeker in goede conditie. Vreemd is ook dat hetzelfde gebeurde bij de CertAuth database van Active Directory Certification Authority Service, ook die DB was in Dirty shutdown state.
Via Google gezocht of het normaal is dat een Microsoft JET DB altijd in Dirty Shutdown state is na een restore maar dat kan ik niet zeggen, zie ook wel mensen die het ook hebben maar lijkt geen normale zaak te zijn.

Nou goed, dan kan je natuurlijk recoveren, met eseutil /ml E00 de logfiles gechecked, en dan wordt het echt vreemd want krijg ik output als:

Log file: E:\Exchange Databases\E00000261F1.log
ERROR: Cannot read log file header. Error -514.

Dit krijg ik echter niet bij 1 logfile maar vrijwel bij allemaal (zo'n 2300 stuks).
Echter wanneer ik:

eseutil /r E00 /d"Primairy Mailbox Database.edb" /i
doe krijg ik het volgende resultaat:

code:
1
2
3
4
5
6
7
8
9
10
11
12
13
Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 14.03
Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating RECOVERY mode...
    Logfile base name: E00
            Log files: <current directory>
         System files: <current directory>
   Database Directory: Primairy Mailbox Database.edb

Performing soft recovery...

Operation completed successfully in 0.125 seconds.


De vraag is: hoe kan het dat alle logfiles ERROR: Cannot read log file header. Error -514 geven en dat ik ook na bovenstaand commando de database niet terugkrijg naar Clean Shutdown state?

Any Exchange expert? ;) _/-\o_


Update (0:32 uur): HUH 8)7 Nou breekt mijn klomp. Toevallig doe ik net nogmaals eseutil /ml E00 en nu opeens zijn alle LOGS status OK 8)7 |:(

Update (2:12 uur): Iemand nog een idee hoe het komt dat eseutil /r zo snel klaar is en eigenlijk niets doet? De DB blijft in Dirty shutdown state.

[ Voor 3% gewijzigd door Urk op 05-04-2016 02:13 ]


Acties:
  • 0 Henk 'm!

  • Question Mark
  • Registratie: Mei 2003
  • Laatst online: 14:40

Question Mark

Moderator SSC/WOS

F7 - Nee - Ja

Ik zou op dit punt gewoon eens proberen wat een hard recovery (/p) doet.

MCSE NT4/2K/2K3, MCTS, MCITP, CCA, CCEA, CCEE, CCIA, CCNA, CCDA, CCNP, CCDP, VCP, CEH + zwemdiploma A & B


Acties:
  • 0 Henk 'm!

  • jimbo123
  • Registratie: November 2007
  • Laatst online: 26-03-2023
En anders vanuit backup exec een restore doen direct naar Exchange i.p.v. naar folder?

Acties:
  • 0 Henk 'm!

  • Urk
  • Registratie: Maart 2000
  • Laatst online: 30-08 23:13
Question Mark schreef op woensdag 06 april 2016 @ 10:15:
Ik zou op dit punt gewoon eens proberen wat een hard recovery (/p) doet.
Thanks, dat voor jouw bericht inderdaad uiteindelijk maar gedaan en dat werkte prima, voor zower we konden zien ook geen mail verdwenen sinds de backup datum.
Toch blijf ik het raar vinden dat Backup EXEC de database in een dirty shutdown modus terug heeft gezet.

Acties:
  • 0 Henk 'm!

  • Urk
  • Registratie: Maart 2000
  • Laatst online: 30-08 23:13
jimbo123 schreef op woensdag 06 april 2016 @ 11:09:
En anders vanuit backup exec een restore doen direct naar Exchange i.p.v. naar folder?
Helaas kon dat op dat moment niet vanwege andere redenen, maar daar zou mijns inziens toch ook geen verschil tussen moeten zitten, de data die hij restored is immers hetzelfde lijkt me.

Acties:
  • 0 Henk 'm!

  • jimbo123
  • Registratie: November 2007
  • Laatst online: 26-03-2023
Urk schreef op maandag 11 april 2016 @ 14:20:
[...]

Helaas kon dat op dat moment niet vanwege andere redenen, maar daar zou mijns inziens toch ook geen verschil tussen moeten zitten, de data die hij restored is immers hetzelfde lijkt me.
Hoe dit precies allemaal werkt? geen idee!

Hoe ik het mij voorstel is als volgt:
- BE maakt via een VSS snapshot een back-up van de Exchange DB terwijl deze draait
- Restore naar redirected locatie zorgt dat de draaiende DB "crashed" en raakt in dirty shutdown state
- Bij restore direct naar Exchange kan deze meteen weer online meedraaien en wordt geheel niet shutdown.

Nogmaals, misschien zit ik er helemaal langs.. maar dit is waarom ik dacht dat het misschien wel zou kunnen werken :)
Pagina: 1