Hello Neelam - Are you able to provide log cuts from the SQLBackupMaster.log from your environment?

Can you check the SQLBackupMaster.log for any errors on server r your SQL Server ] for this Job?
The log Files are usually located at: <Install Drive>:\Program Files\Commvault\ContentStore\Log Files\

@Neelam Jain Ideally we would need to check those logs also to see if and what is returned before we are able to determine the issue. Knowing that you are seeing the _1 clients also is helpful but we would still like to confirm in more detail the issue before making assumptions on the resolution.

It also may be best to open a support incident so a member of the support staff can view full logging to narrow this down further.

@Chris Hollis @Ron Potts 

Thanks guys for your valuable comment.

I had opened a case with support and issue resolved by merging the duplicate clients as per the link provided byr Ron also.

https://documentation.commvault.com/commvault/v11_sp20/article?p=31667.htm

Regards

Neelam Jain

@Neelam Jain 

Further to Ronalds update, the _1 usually comes as a result of the following: https://documentation.commvault.com/commvault/v11_sp20/article?p=31667.htm - this will impact our AG unless fixed.

The knowledge base article for this issue is here: https://kb.commvault.com/article/63652

Probably best to raise a case so we can validate as there is a small chance it’s something else entirely.

Please let us know how you go.

Chris 

Hi Eldan,

Can you check the SQLBackupMaster.log for any errors on server hsapsqldb9 for this Job?
The log Files are usually located at: <Install Drive>:\Program Files\Commvault\ContentStore\Log Files\

Best Regards,

Michael

Hi @Eldan 

May be best to raise a support case to check this out as there may be a number of things that cause this. 

Out of curiosity, are you able to confirm if this was a working AG and it’s now problematic or is this a new setup? 

If you view the properties of the AG, do the either of the replicas have an _1 appended to their name? 

E.G. 
 

Hey @Eldan , following up to see if you managed to raise a case for this issue.  If you did, please share the number so I can track it accordingly 

Thanks!

Great!  I marked your reply as the Best Answer then!

Hi, I am also facing similar issue and _1 is visible for both the replicas.

Please let me know what should be done here.

Hi @Eldan 

May be best to raise a support case to check this out as there may be a number of things that cause this. 

Out of curiosity, are you able to confirm if this was a working AG and it’s now problematic or is this a new setup? 

If you view the properties of the AG, do the either of the replicas have an _1 appended to their name? 

E.G. 
 

 

Hi, I am also facing similar issue and _1 is visible for both the replicas.

Please let me know what should be done here.

I’m sorry we couldn’t help…..is this something you expect to retry soon as o we can try and get to the bottom of it for you?

Hi, it’s not relevant right now. the instance was moved back to the original node and the backup is running

Gentle follow up, @Eldan.  I don’t see any support case in your name, so please advise if you have a case number, or were able to get this resolved.

Thanks!

Hi Eldan,

Are the AG Nodes the same SP/MR level as the CommServe?

Best Regards,

Michael

@Eldan , can you raise a support case and share the number here?

It was working and now problematic

I don’t have the underscore+number added

@MichaelCapon I don’t see any meaningful information

40556 1f98  08/02 15:53:02 3390473 SQLBackupController::FetchAGFromRemoteAgentAndUpdateCS(531): -Debug-: Got AG infromation from replica iHSAPSQLDB9\IPD].

40556 1f98  08/02 15:53:03 3390473 NetMessage::verifyResponseHeader() - Error Code C-1] returned - e].

40556 1f98  08/02 15:53:03 3390473 InstInterfaceNet::setMSSQLAGProperties() - 

40556 1f98  08/02 15:53:03 3390473 SQLBackupController::FetchAGFromRemoteAgentAndUpdateCS(579): -Error-: Failed to update AG information of MSSQLAGInstance with error h-1].

40556 1f98  08/02 15:53:03 3390473 SQLBackupController::MarkJobStatusFailed(187): -Debug-: JOB STATUS FAIL.

40556 1f98  08/02 15:53:03 3390473 BKP CALLED COMPLETE (PHASE Status::FAIL), 3390473. Token 73390473:2:5:0:55415]
 

yes, the nodes and the software are at the same level

My apologies! - SP = Service Pack, which has been replaced by FR (Feature Release) and MR = Maintenance Release which replaced HotFix Pack (HPK).

I would suggest to ensure the AG Nodes are the same Commvault Software Level as the CommServe.

Hi Michael, sorry but i’m not familiar with the SP/ MR abbreviations  ;)