tdpexcc backup * incr : HrESEBackupGetLogAndPatchFiles() error

[mschenone]

Hi all,
often I have an issue when doing incremental backup of First Storage Group (only on the this one). The issue is solved by a full backup, however I have not enough room for daily full backup.

The output of tdpexcc query exchange is:

IBM Tivoli Storage Manager for Mail:
Data Protection for Microsoft Exchange Server
(C) Copyright IBM Corporation 1998, 2006. All rights reserved.

Microsoft Exchange Server Information
-------------------------------------

Server Name: MAIL01
Domain Name:
Exchange Server Version: 6.5.7638.1

Storage Groups with Databases and Status
----------------------------------------

First Storage Group
Circular Logging - Disabled
Mailbox Store 1.1 (MAIL01) Online
Mailbox Store 1.2 (MAIL01) Online
Mailbox Store 1.3 (MAIL01) Online
Mailbox Store 1.4 (MAIL01) Online
Public Folder Store 1.1 (MAIL01) Online

Second Storage Group
Circular Logging - Disabled
Mailbox Store 2.1 (MAIL01) Online
Mailbox Store 2.2 (MAIL01) Online
Mailbox Store 2.3 (MAIL01) Online
Mailbox Store 2.4 (MAIL01) Online
Mailbox Store 2.5 (MAIL01) Online

Third Storage Group
Circular Logging - Disabled
Mailbox Store 3.1 (MAIL01) Online
Mailbox Store 3.2 (MAIL01) Online
Mailbox Store 3.3 (MAIL01) Online
Mailbox Store 3.4 (MAIL01) Online
Mailbox Store 3.5 (MAIL01) Online

and the error message:

Beginning incr backup of First Storage Group, 1 of 1.
Full: 0 Read: 0 Written: 0 Rate: 0.00 Kb/Sec
Backup of storage group First Storage Group failed.
ACN5798E MS Exchange API HRESEBACKUPGETLOGANDPATCHFILES() failed with HRESULT: 0xc8000232 -Alcuni file registro o di correzione risultano mancanti.

(translation from italian: some log or correction files are missing)

Looking around I found out this brief description of the Exchange behaviour during backup operations:

"During a full backup operation, the transaction logs must be stored to the backup set next. Remember from above that the checkpoint is halted at the beginning of backup (for a full backup). Even though the checkpoint is halted, transactions continue to be written to the log files, and dirty pages from the database cache in memory are flushed to disk during the backup operation. Note that with Exchange 2000 SP2 and later, dirty pages that cause patching operations are not flushed; this is how Microsoft was able to get rid of the patch files in SP2. In order to back up the log files, the backup application requests a list of log files (and patch files if applicable) from ESE (via the HrESEBackupGetLogAndPatchFiles API call). When ESE receives this call, it closes the current log file as the next log generation and opens a new E0n.log. In the case of a full backup, ESE then returns a list of log files to the backup application that starts with the current log generation where the checkpoint is halted and ends with the generation of the log file that was just closed (E0n.LOG -- 1). In the case of an incremental or differential backup, ESE returns a list beginning with the oldest generation on disk up to the most recent log file closed (E0n.LOG -- 1). During incremental, differential, and copy backup operations, only log files are backed up and the checkpoint is not halted. Using this list of files, the backup application can open file handles to the logs and copy them to the backup set (using the HrESEBackupOpenFile, HrESEBackupReadFile, and HrESEBackupClose-File). During these operations, ESE also ensures that no log generation is missing from the sequence passed to the backup application. This operation will continue until all relevant log and patch files have been written to the backup set by the backup application. "



Has anyone experienced something like that? may be is it an Exchange problem and not a TDP bug?


Thanks a lot in advance,
M

 

[mschenone]

I guess it should not be TDP problem, because googling around I found out the same issue for several different backup tool (e.g. Legato).

Possible solution:

"It seems to be something wrong with the public folder databases.
Running eseutil /d pub1.edb (defragmentation) and then eseutil /p pub1.edb (repair) solved the problem. Note: The public folder database has to be dismounted during this process."

 

[mschenone]

No way!

 

[mschenone]

In order to do a restore I created a Recovery Storage Pool on Exchange Server and a mailbox store inside it... well, since that time the incremental backup started working properly. Maybe MS Exchange API HRESEBACKUPGETLOGANDPATCHFILES() - called by tdp - needs RSG to be defined.. or may be not! Anyway I get it done