cancel
Showing results for 
Search instead for 
Did you mean: 

Exchange 2013 backups complete with status code 0 on Netbackup however last backup time stamp on exchange doesn't update

Kisad
Level 5

Hi All,

I'm facing a strange issue with exchange backups. The backup complete successfully with status code 0 however the exchange admin reports that the last backup time stamp within exchange does not update. I was wondering if anyone has seen similar issue and can help troubleshoot it.Thanks

 

Master Server: Netbackup  7.7.1 on Windows 2012

Media Server: Netbackup  7.7.1 on Windows 2012

Exchange 2013

 

 

13 REPLIES 13

sdo
Level 6
Partner    VIP    Certified

Is that a feature of MS Exchange?

https://social.technet.microsoft.com/Forums/exchange/en-US/43d47a78-b9b4-4ed3-86a4-da538145522d/backup-timestamp-on-active-copy-is-different-from-the-passive-copy?forum=exchange2010

Is this a DAG?  Checked time stamp on all passive and active copies?

sdo
Level 6
Partner    VIP    Certified

Are you using the -status switch on your powershell query?

https://www.veritas.com/support/en_US/article.000086899

http://www.veritas.com/docs/000086899

Kisad
Level 5

Thanks sdo. Its a DAG with 9 databases.The backup policy is setup to use the DAG name as the client name with three node sever name mentioned in the preferred server list. Also its setup to backup from the Passive copy only.

I'm using the -status switch in query and the output is same when checked from any of three servers in the DAG.

If you look at the attached screenshots you will notice that though there was a successful full backup of all 9 databses on 10th Jan exchange doesnt show the updated backup time stamps.

 

 

 

sdo
Level 6
Partner    VIP    Certified

Ok - I'll check my DAG in a little while...

sdo
Level 6
Partner    VIP    Certified

Hmmm, I don't have rights at my site to use the Exchange management shell.  Sorry.  So, I can't check the dates.

Can anyone else check theirs, an confirm whether they have the same symptoms?

sdo
Level 6
Partner    VIP    Certified

Kisad, I've ust been advised from one of our messaging admins that the PS query reports the same backup dates across all four DAG nodes.  I wasn't sent actual evidence of this, but I have no reason to doubt his word.  BTW, we're using NetBackup Client v7.6.1.1 on Windows Server 2012 R2 hosting MS Exchange 2013  CU6.

So apologies, but I don't know what might be causing your problem.  Maybe open a Veritas Support case?  Maybe an internal step is being missed at the end ofthe backups?

Michael_G_Ander
Level 6
Certified

Haven't worked with exchange 2013, but seen a lot of errors/strange things related to permissions on exchange systems from 2003 to 2010.

Have often found the indications of the problem in the bpbkar, bpresolver and/or the event logs on the exchange servers.

A place to start could be to check with your exchange admin that the netbackup client service user has the rights described in the Netbackup Admin Guide for Exchange

 

The standard questions: Have you checked: 1) What has changed. 2) The manual 3) If there are any tech notes or VOX posts regarding the issue

Kisad
Level 5

@sdo I have opened a support case, will update when I have more information.

 

@Michael  We use a separate account with permissions for exchange for netbackup client service on the DAG nodes. I would think that the permissions are okay as the backup jobs are completing with status code 0.

sdo
Level 6
Partner    VIP    Certified

What does the Activity Monitor job activity detail show?  I get the feeling that you cannot post the contents for us to check, so if you have a look yourself... sometimes what can happen is that the NetBackup Client software has been developed and written such that it knows that... a backup is succesful, yet it was unable to finish some minor admin task (e.g. update the MS Exchange database "backup dates")... i.e. something which isn't serious enough to invalidate the backup itself... and so the backup looks, and is, successful.    So, have a look in the activity monitor detail for all of teh related MS Exchange backup jobs (i.e. all parent jobs too)... Do you see any errors or warnings which are reported as "info" severity level?

Kisad
Level 5

@sdo I just checked the jobs in activity monitor, none of them have any errors or warnings. On the nodes I do see even id 2046,2037 and 2033 stating that backup has completed.

Kisad
Level 5

update:

Support suggested to create a new policy and try the backup. So I created a new policy and  tested the backup for a few databases, backup worked fine and exchange updated the backup time stamp. I also tested by copying the old policy into a new one, that too worked (surprisingly). Anyways things worked for a week however the problem is back after this weekend's backup. I'll reopen the suport case though  I have a feeling this might not be a netbackup issue.

sdo
Level 6
Partner    VIP    Certified

Funnily enough, my initial reaction is to lean the other way, and say that it does look like a NetBackup side issue, because a policy change on the NetBackup side does cause the 'dates' on the MS Exchange side to be updated... which makes it look as if it is NetBackup code which requests the "date to be updated" on the Exchange side.   A support case is best, because sometimes, as in this case, it's not probably not easy for us as admins to determine where the true root cause actually resides... you kind of need access to the source code to identify exactly where the call is taking place and what the related log messages would be.

Kisad
Level 5

Thanks @sdo, I'll post an update when  I have one. I have been googling what exactly is the significance of the backup time stamp on exchange without much luck yet. I mean is there any exchange tasks that cannot run till the backup time stamp update on exchange side and more importantly does it render the successful backup in Netbackup useless for a restore since exchange doesnt know it was backed up.

I know this is not an exchange forum however it would be great if someone knows about this, please comment.Thank you.