Showing results for 
Search instead for 
Did you mean: 

JET_errDatabaseDirtyShutdown after Exchange 2010 GRT backup

Level 2

We have a customer that is using Backup Exec 15. Last week we updated from FP2 to FP3.
We also updated Exchange 2010 SP3 to the latest rollup. We went from Exchange 2010 SP3 Rollup 11 to Exchange 2010 SP3 Rollup 12.

Backup Exec 15 and Exchange 2010 are running on the same server (SBS 2011)

After the installation of FP3 for Backup Exec 15 and Exchange 2010 SP3 Rollup 12 we restarted the server, but now we are seeing an error message for the Exchange backup when the job is finished. We are using the GRT option and the Exchange backup is always a Full backup.

V-79-57344-65193 - The backup selection '\\SERVERNAME\Microsoft Information Store\Mailbox Database Name' was not successfully processed for Granular Recovery Technology (GRT). The Database Recovery failed with Error 'JET_errDatabaseDirtyShutdown This error is obsolete and has been replaced by JET_errDatabaseDirtyShutdown. '. You will not be able to restore individual items for this backup selection.

I tried to restore individual items and the restore is successful, but the error message is always there.

I turned off the GRT option for the Exchange backup job and the job is successful without any errors, so the issue is only with GRT enabled.

Maybe someone who can help me to resolve the error message?


Level 0

I have exactly the same issue, did you get a resolution?

Level 2

Yesterday I installed Rollup 12 again and the Exchange backup was successful yesterday, I will check the job tomorrow and the day after to make sure.

Level 2

Stil having issues, sometimes it shows successful, on other days it says failed with the same message, so reinstalling RU12 was not a solution.
I updated SBS Edition to Capacity Edition Lite, hoping that installation would replace/update certain files that is causing the issue, but that didn't help either.
The backup itself is successful, because a GRT restore is always successful, but the error is bothering me.

Level 6
Employee Accredited Certified

If running any AV, exclude it from scanning BE processes.

Sounds similar to -

This may require a formal support case to be logged for us to investigate.

Not applicable

We have a customer receiving the same intermittent error on what appears to be the same software.

Backup Exec 15 FP3

Microsoft Exchange 2010 SP3 UR12

Microsoft Windows SBS 2011 (2008 R2)


The error last occurred during the overnight backup, I have checked all VSS Writers just now and they are all stable/no last error.


Sounds like I'll need to log a case with Technical Support, but would be very glad to hear if anyone else gets a resolution!

Level 3
Partner Accredited

We're getting the same error as well over the past few weeks with a client.  Seems above is exactly what happened here too.  Any update in the past two weeks on this?  Did anyone open a case?  What was the solution?

Level 2

Also seeing this on one (of many) SBS 2011 servers we manage - this backs up to a NAS, although we got (slightly less of) the failures if backing up to a local disk.

As part of our support case open for the last few weeks- we have been told the issue is likely with our Exchange Databases being corrupt. ESUTIL checks show they are not.

Very latest BEWS V15 FP3 - Clean install, not upgraded.

Circular logging is enabled as per default and very few transaction logs exist- Exchange is not heavily used at all on this server, we can find no general health issues. No VSS issues.

Disabled AV on the server for a few jobs, no change- approx 1 in 5 jobs randomly "fails", but no real consistency.

Debug logs indicate that the actual failure is at the point of the "AttachDatabase" command and this is being attached from the NAS drive/Backup Exec TEMP folder that contains the backup file. After this we then see an "OPEN DATABASE FAILED" event logged which again relates to the NAS and Backup Exec TEMP folder location.

Glad to see we are not alone here.

Not applicable

We have this too; same versions of BackupExec as above on an SBS 2008 server. Just as random but becoming more frequent. Did anyone discover a solution or mitigation?

Level 2

Following on from my previous post, we have now had a support case open for 3 months- no conclusion on the matter to date. Just random failures and can we collect more logs.I am currently trying to get a SGMon log of a successful and a failed backup so the logs can be compared, this is easier said than done.

As a side note- I (stupidly) upgraded another SBS 2011 server from BEWS 2014 to 15 FP4 on friday. Never had a GRT dirty shutdown error before. Guess what- from the fist backup after the upgrade, it's now finising jobs with the  same failed error. 



Level 4


@Slave2BEWS. Any update from Support-Team ? I see the same error on a BE15 installaton, also on SBS2011.


Regrads Timo


PS: What will you do if your BE support will expire, because Veritas do not sell anymore support for BE 15 SBS licence.


Level 2

@Timo- What are you backing up to ?

In addition to the steps taken in my support case, I elected to recreate a clean test lab SBS install. This gave me firm result on my suspicions:

Physical (HP Proliant) server, with all standard MS updates applied to the OS, but did not apply all the Exchange Updates etc. No AV, nothing else installed to interfere.

The Exchange mailbox store was therefore tiny as it only had a few messages in the Admin mailbox.

I then configured three backup destinations, one external Disk Based (in this case a Buffalo NAS), one internal RAID array that was not being used by the system, and a DLT-V4 Tape drive.

I configured a GRT backup of exchange data to run every 20 mins, overwriting the previous job. This ran continuously for a few days, and I routinely changed the destination between the 3 available.

The findings were the GRT error ONLY EVER occurred when the destination was disk based- if being written to the Tape device, not one GRT error occurred. Secondly- I also confirmed that in any of the apparent "failed" GRT backups, I could then configure a restore job, and fully expand the mailbox structure to selectively restore, which should not be possible if there is a genuine GRT failure.

So I concluded that as per my affected production servers that backup to Disk/NAS- there is nothing wrong with Exchange or the servers at all.

I have had a 2nd line Support Tech look at the information I have gathered on my test server, and as such they have informed me they are submitting it to engineering as a PRODUCT DEFECT. I await the outcome of this. I was warned that  this may take considerable time to resolve as it seems this issue has not been seen/reported widely- the bulk of Backup Exec users do not backup SBS (or possibly stay on older versions to avoid the per TB licensing limitations.)

Hence if anyone is affected with this isuse I strongly recommend they raise a case to add weight to the problem, else it will not be prioritised.

Depending on the outcome of this issue, I may look to another product Vendor as all my clients are SBS based, and hence this is a real problem



Not applicable

We are experiencing the exact same behavior under the same configuration(s).  I will open a case with support too.