Exchange Backup

We have been having a problem backing up our exchange database on our SBS 2003 server. It has been backing up file for about 3 years now and just this week we started having problems. We back it up using Backup Exec 2010 R2 with all the latest service packs and hot fixes. The job fails and tells us that the Mailbox store is corrupt and cannot be verified. If we try to backup the database through NTBackup, we get the following error:

Backup Status
Operation: Backup
Active backup destination: File
Media name: "Exchange.bkf created 2/17/2011 at 10:03 PM"

Volume shadow copy creation: Attempt 1.
Backup of "SERVER\Microsoft Information Store\First Storage Group"
Backup set #1 on media #1
Backup description: "Set created 2/17/2011 at 10:03 PM"
Media name: "Exchange.bkf created 2/17/2011 at 10:03 PM"

Backup Type: Normal

Backup started on 2/17/2011 at 10:03 PM.
The 'Microsoft Information Store' returned 'Error returned from an ESE function call (d).

' from a call to 'HrESEBackupRead()' additional data '-'The 'Microsoft Information Store' returned 'Error returned from an ESE function call (d).

' from a call to 'HrESEBackupRead()' additional data '-'
The operation was ended.
Backup completed on 2/17/2011 at 10:07 PM.
Directories: 0
Files: 1
Bytes: 4,281,598,632
Time:  3 minutes and  23 seconds


The operation did not successfully complete.


Exchange is still operating completely fine and we see no kinds of errors in the system or application log. Do we really have a problem with our database?

Who is Participating?
craig_j_LawrenceConnect With a Mentor Commented:
It is safe to say that if NTbackup is having errors reading the database, there is some type of corruption in the file.

You will need some downtime to run some integrity checks on the database
Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
are they any errors reported in the event log?
StarfishTechAuthor Commented:
That seems to be pretty clean with the exception of the following error in the application log that has surfaced twice in the last week.

Event Type:      Error
Event Source:      EXOLEDB
Event Category:      General
Event ID:      111
Date:            2/17/2011
Time:            9:39:34 PM
User:            N/A
Computer:      DHTLSERVER
Microsoft Exchange OLEDB was unable to do Schema propagation on MDB startup HRESULT = 0x80040e19.

For more information, click
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

StarfishTechAuthor Commented:
what would you suggest - running isinteg?
absolutely. take a physical copy of your database and logs, then run ISINTEG as per this article
mass2612Connect With a Mentor Commented:

isinteg will fix logical corruption in the database. It does this by deleting internal links to records that no longer exist in the database. Therefore if you repair a database you loose data. That's why you should restore the database in preference to running a repair.

If you are going to repair you need to repair the physical corruption first (if any) with eseutil then run isinteg to fix the logical corruption. Eseutil /p deletes the damaged physical pages from the database and then eseutil /d cleans up the physical links to the damaged pages that eseutil /p deletes from the database.

I would check the physical structure of the database using eseutil /g and /k before doing a fix with isinteg and only do a repair if there were no backups available to restore from.
Thanks for chiming in Mass2612,

If you read the earlier posts, I suggested running CHECKs on the database. if all else fails, then restoring a previous copy of the database may be a last resort
Hi Craig - sure. Just wanted to make sure that Startfish thinks about the order of a repair. So many times I've seen people fix one or the other i.e. the physical and not logical or vice versa and then they wonder why the database keeps corrupting or giving strange behaviour.
Just make sure your EDB, STM, log & chk files are excluded from file level AV scanning. You can also try disabling AV and running the NTBackup to see what happens...

Maybe your backups are struggling because your AV software is locking the EDB file for scanning everytime the backup software accesses the file
StarfishTechAuthor Commented:
I've been considering moving the users to a new database? Would that be a viable option? Is it possible in exchange 2003? Would would be the best way to go about that?
Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
get some down time and complete a chkdsk on the storage volumes, before you do any database maintenance, or moving users.
lucid8Connect With a Mentor Commented:
1. Are you by chance getting a -613 in the event log as well?

2. Yes moving users to a new DB is certainly an option

3. All good suggestions above and If you upgraded AV recently its certainly worth looking at as MegaNuk3 suggested to see if that makes a difference. I have seen times where a vendor does a major update and things go south.

4. If you have a corrupt database and end up needing to do an Eseutil /P then /D and Isinteg etc be sure that AFTER you take the database offline you make a backup of the database in case things go terribly wrong.
Hi StarfishTech,

Sadly with SBS 2003, the version of exchange (standard) only allows you 1 mailbox database.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.