I had seen reference to this error in earlier posts, but as you see below, I tried and it didn't help. Hoping a new posting might gather some new insight? :)
I am on BE2016, now with Exchange 2016...
I was getting 100% success rates with Exhange 2010, but now that we have migrated to Ex2016, I am also getting this old error. I have tried the DWORD mentioned in the other article (which I assume is NOT a typo in that there is a space in the DWORD name)... rebooted, ran another incremental, and the same error popped up.
(please advise if I should now remove the DWORD, or if it's safe to leave with BE2016/Ex2016)
Any thoughts? Or something I am missing?
Here is the exact text of the error:
October 25, 2017 12:23:48 AM - V-79-57344-759 - The backup selection '\\Crom.aquilonia.orb\Microsoft Information Store\Mailbox Database xxxx2' was not successfully processed for Granular Recovery Technology (GRT). The Database Recovery failed with Error '*Null*'. You will not be able to restore individual items for this backup selection
Job Completion Status
Job ended: October 25, 2017 at 12:23:49 AM
Completed status: Failed
Final error: 0xe00002f7 - Cannot extract mailbox messages from the Exchange backup. Review the job log for more information.
Final error category: Resource Errors
For additional information regarding this error refer to link V-79-57344-759
Seeing this also. It was working fine a week ago. No updates as far as I know. BE 16 fully patched, Exchange 2016.
If I change it to Non-GRT, it backs up fine. If I change it back to GRT after a successful backup, it still fails again.
Probably be opening a ticket next Monday. For now, everything is set to non-GRT.
Thanks... always nice to know I'm not alone.
Let's not open two tix, just let us know what you find out, ok?
And, I'm not 100% sure the backup is failing to backup data, reads more like it's failing to verify the successful nature of a granular backup. Wondering if that simply means I have a good full database backup, but would be unable to restore a sinlge message somewhere... or... well, hard to say, with such cryptic error codes.
Let us know what they say... ok? :)
(BE2016 is a new animal to me, so I'm not even sure how granular a restore it supports on Ex2016 anyhow)
I'll let you know. If it's critical don't wait on me, BE issues can take weeks to resolve sometimes.
I saw last nights backup finish, then it went to verify, got through 200GB of verify and I signed off. Came in this morning and it was failed. It does look like if I needed I could do a full database restore, but no GRT. Anywho, I'll post back.
GRT with 2016 is good. You can select a single message and restore it right back into someones mailbox in a few clicks if you want. It's that granular. You want GRT to work.
Oddest thing. Hadn't checked on it in a few days... and ever since it's last full backup (which completed with exceptions), each incremental backup has also completed (with exceptions).
(exceptions are all on an older 2003 server, still hosting web stuff for now)
even GRT... right there in the log...
"Job Log: BEX_CROM_00078.xml
The backup selection '\\Crom.aquilonia.orb\Microsoft Information Store\Mailbox Database 0945360672' has been successfully processed for Granular Recovery Technology (GRT)
Maybe it just needed to get one good full backup...? Not sure. Before that, I had a good backup, followed by a failed (I rebooted) incremental, and then all those failed GRTs in a row...
I finally got a good backup after trying many things with support. Apparently for GRT, the exchange servers themselves need enough free space to temporaily stage the database backups for GRT to work. In my case, I created 1.5TB drives on each server which is larger than my total database size. I had to change the OnHostTemp registry entry referenced here: https://www.veritas.com/support/en_US/article.100001360.html to the new drive and it worked.
I was using a 300GB free drive prior, which was apparently not large enough. I know for certain when it was working in the past, that I never had more free space available than the entire DB size combined. So there must be some thresh hold that no one knows about. Might it work with just 500GB? 800? 1TB?
Hopefully this helps someone. By default I think it uses the C:\ to stage.