Microsoft Exchange GRT backup failing with error code 130

[Mux]

I have Exchange 2010 with 2 node dag.

Netbackup 7.5.0.6 is installed on all the servers(Master, media, clients).

On node2, the VSS admin writer has an error. But everything is fine on node1.

In the policy attributes, database backup source is " Passive Copy" and in the preferred server list, both the node names are provided.

But all the DBs mounted on node2 is failing with error code 130(the DBs are mounted on node2 and as it is mentioned to use passive node, the policy should use node1 for the backup). 

I know that once i fix the vss error on node2, the backups shall works fine.

But my question, the backup is tried on the passive node and the passive node is having no issues. So why is the backups failing?

Any help?

Thanks in advance.

[RiaanBadenhorst]

Sorry, don't understand your question here.

"On node2, the VSS admin writer has an error." <<<<So you know there is an issue with this node

"But my question, the backup is tried on the passive node and the passive node is having no issues. So why is the backups failing?"<<<<<But it DOES have an issue, as you stated above.

What am I missing here?

Please post the detailed status from the jobs (all 3).

[Mux]

Riaan, node2 is the active node and i am using passive node for backup. Passive node is node1 and it has no issues.

[Marianne]

Please ensure that all of these log folders exist so that we can see what is node 2's involvement:

On media server: bpbrm

On both nodes: bpresolver, bpfis, bpbkar

Copy logs to .txt files (e.g. bpresolver1.txt for node1) and upload as File attachments.

[RiaanBadenhorst]

Please post the detailed status from the jobs (all 3).

[Mux]

Please find the logs attached.

No logs were generated on node2.

[RiaanBadenhorst]

See below

VSS is not 100%

12:17:14.055 [11856.14872] <2> onlfi_vfms_logf: INF - INF - vss__complete: ***** Complete VSS snapshot processing *****
12:17:14.055 [11856.14872] <2> onlfi_vfms_logf: INF - bedsExchange2000Term(): INF - Enter
12:17:14.055 [11856.14872] <2> onlfi_vfms_logf: INF - _bedsTermFsys(): INF - Detaching from DLE '\\Q2022SCDAG\Microsoft Information Store\Diamond DB'
12:17:14.055 [11856.14872] <2> onlfi_vfms_logf: INF - BEDS Resource ID - 0xF36
12:17:14.055 [11856.14872] <2> onlfi_vfms_logf: INF - BEDS Resource ID - 0xF36
12:17:14.055 [11856.14872] <2> onlfi_vfms_logf: INF - Informational: Operation abort detected. Forcing the status to 'false' for SetBackupSucceeded() when detaching from Shadow?Copy?Components Dle
12:17:14.055 [11856.14872] <2> onlfi_vfms_logf: INF - Informational: Component - Path: 'Microsoft Exchange Server\Microsoft Information Store\Replica\Q2022MPMB01'  IDs: {76FE1AC4-15F7-4BCD-987E-8E1ACB462FB7}|{0388178E-9280-4730-9FFD-F56E95F85EDC}
12:17:14.055 [11856.14872] <2> onlfi_vfms_logf: INF - Informational: calling IVssBackupComponents::SetBackupSucceeded for status event 'SUCCESS (0x00000000)' with succeeded set to 0(False) for Component '87885824-3c16-4189-9318-d00996275eed' object '87885824-3c16-4189-9318-d00996275eed' when detaching from Shadow?Copy?Components Dle
12:17:14.070 [11856.14872] <2> onlfi_vfms_logf: INF - ERR - vss__complete: Exchange Transaction Logs will not be truncated by VSS because of errors encountered during the backup, Backup Status = 130, Validation Status = 0.
12:17:14.086 [11856.14872] <2> onlfi_vfms_logf: INF - VSS AbortBackup called successfully
12:17:14.086 [11856.14872] <2> onlfi_vfms_logf: INF - Attached [0x77f350]
12:17:14.086 [11856.14872] <2> onlfi_vfms_logf: INF -  EXIT BESC::VssBackupComponents::BackupComplete() return=[0x80042301 VSS_E_BAD_STATE]!
12:17:14.086 [11856.14872] <2> onlfi_vfms_logf: INF - Ignore VSS_E_BAD_STATE since we are aborting
12:17:14.086 [11856.14872] <2> onlfi_vfms_logf: INF - Unattaching [0x77f350]
12:17:14.086 [11856.14872] <2> onlfi_vfms_logf: INF - Freeing gathered writer metadata
12:17:14.086 [11856.14872] <2> onlfi_vfms_logf: INF - Releasing vss interface 0x77f350

[Mux]

Riaan, there were no VSS writer issues on node1 (passive).

Anyways we moved all the DBs to node1 and rebooted the node2. After rebooting the node2, the VSS errors on node2 was fixed and the backups started working fine.

i still cant understand why the VSS error on node2 is affecting while using node1 for backups.

weird.

[Marianne · Accepted solution]

The fact that nothing is logged in NBU folders on node 2 says to me that it is not NBU trying to do anything on node 2, but Exchange.

There should be 'something' in Event Viewer logs to say what is happening at Exchange/VSS level.

[Mux]

There were some VSS errors on the Event viewer.

So may be it is exchange trying to do something on node2...

Thanks.