NetBackup and Commvault with Exchange DAGs: passive copies, status 156 and VSS errors

Enterprise backup suites protect a database availability group by picking one copy of each database — ideally a healthy passive copy on a nearby node — and asking the Microsoft Exchange Writer on that node for a VSS snapshot. When either step goes wrong you see NetBackup status 156, Commvault jobs that complete with errors, and logs that never truncate. Here's how to read each product's clues next to Exchange's own and fix the broken side.

Symptoms#

NetBackup#

NetBackup status code: 156
Message: snapshot error encountered

NetBackup also keeps a backup status for each DAG database on the primary server, recording which node the last attempt used and whether it succeeded (step 1 shows how to read it).

Also watch for databases skipped with a progress-log message: NetBackup's guide documents this when it can't choose a server for Passive copy only.

Commvault#

The job ends as Completed w/ one or more errors in Job History, or fails with codes such as Error Code [82:128] Network receive failed or Error Code [80:36]: No more allocated streams are available.

Exchange#

On the node that was backed up, vssadmin list writers shows the Microsoft Exchange Writer with Last error: Timed out or Retryable error, logs keep growing and LastFullBackup is days old.

Why it happens#

Both products choose a copy (NetBackup through its database backup source and preferred server list, Commvault through its DAG client), then the Exchange writer on that node freezes the database for the snapshot. Failures fall into three layers:

How to fix it#

1. Identify the node that was used#

NetBackup: on the primary (formerly master) server, display the DAG backup status. -EXDB is case-sensitive.

bpclient -client DAG01 -EXDB
bpclient -All -EXDB

The output lists, for each database, the node used last and the status of the last attempt, where 0 is success; the guide's topic Displaying and resetting the backup status for a Database Availability Group (DAG) covers the options. Commvault: open the job details in Job History, then the Exchange Database Agent logs in the Log Files folder of the Commvault installation on the DAG members, and the Windows Event Viewer on those members for VSS errors.

2. Check that node from Exchange's side#

vssadmin list writers
Test-ReplicationHealth -Identity EX02
Get-MailboxDatabaseCopyStatus -Server EX02 | Format-Table Name, Status, CopyQueueLength, ReplayQueueLength -AutoSize
Get-MailboxDatabase -Status | Format-Table Name, BackupInProgress, LastFullBackup, LastIncrementalBackup -AutoSize

Good looks like the writer at [1] Stable with No error, every Test-ReplicationHealth check Passed, the copy Healthy with queues near zero and BackupInProgress False. A broken copy is a bad backup source in any product, so fix replication first: high copy or replay queues or FailedAndSuspended copies.

3. Reset the writer and stop overlapping snapshots#

Restart MSExchangeRepl on that node (move active copies away first), confirm the writer is Stable, and make sure no hypervisor snapshot or second agent hits the server in the same window. Deeper checks: Microsoft Exchange Writer failed or retryable.

4. Deal with VSS timeouts#

• Back up local copies: NetBackup's guide suggests a preferred server list of local servers so replicated data doesn't cross the WAN; with Commvault, back up DAG members in the same site as the backup infrastructure.
• Keep backups away from migration batches, large mailbox moves and other heavy I/O.
• Check volume latency, the installed VSS providers (vssadmin list providers) and, for array snapshots, the product's snapshot method.

5. NetBackup: preferred servers and backup status#

In the NetBackup web UI, the policy's Attributes tab has a Microsoft Exchange Server DAG group with the Exchange database backup source list and an Edit preferred server list option. A preferred server list is required for Passive copy only (unless a database has only an active copy), optional for Passive copy if available, or use active copy (the default), and ignored for Active copy only. Add the DAG nodes by FQDN in the order you want them used.

NetBackup reuses the last successful server when it's on the list and pushes a server that failed to the bottom; with no usable list it ranks the health of the passive copies. To steer the next backup of a database to a specific node, reset its status (lowercase -exdb here):

bpclient -client DAG01 -update -exdb DB01:EX03:0:0:0

6. Commvault: read the job, not just its status#

• Completed w/ one or more errors is the Job History status Commvault documents for Exchange Database Agent jobs that finish with errors: open the job details, find the database that failed and apply steps 2–4.
• [80:36] is documented for backups that use an incremental storage policy: a storage policy (stream allocation) issue, not Exchange.
• [82:128] is a network receive failure: check the path from the member to the backup infrastructure first.
• If the DAG has no administrative access point (an IP-less DAG), confirm in Commvault's documentation that your version's DAG client supports it.

7. Make sure logs can truncate#

Logs truncate after a full or incremental backup completes through the Exchange writer, and in a DAG only once every copy has replicated and replayed them; lagged copies hold logs for their ReplayLagTime and TruncationLagTime (each up to 14 days). Copy backups never truncate.

Get-MailboxDatabase DB01 | Format-List Name, CircularLoggingEnabled, ReplayLagTimes, TruncationLagTimes

If the log volume is already filling, follow transaction logs filling the disk.

Verify the fix#

• NetBackup: the job ends with status 0 and bpclient -client DAG01 -EXDB shows a last status of 0 on the node you expect.
• Commvault: the job completes without errors and its job details list no failed databases.
• The writer is Stable with No error before and after the job, LastFullBackup updates and log counts drop on every copy.
• A granular restore test works — each product has its own granular recovery prerequisites, so test before you need it.

Key takeaways#

• Status 156 and "completed with errors" are symptoms; writer state and copy health on the chosen node are usually the cause.
• Find out which node was backed up before changing anything.
• Prefer healthy, local passive copies and one VSS backup per server at a time.
• Check the vendor's compatibility list before moving to Exchange Server SE or a new CU. Using Backup Exec instead? See Backup Exec and Exchange.

References#

• Monitor database availability groups (Microsoft Learn)
• Mailbox database copies (Microsoft Learn)
• Configuring a preferred server list for a DAG (NetBackup for Microsoft Exchange Server Administrator's Guide)
• Exchange Database Agent Backup Troubleshooting (Commvault)