Status 103 and 130 for DAG Incremental Backup

[Maurice_Byrd]

***** Moved to new discussion from https://www-secure.symantec.com/connect/forums/exchange-2010-dag-backups-failing-69-and-130  by MvdB ****

Has anyone found an answer to this issue?  My environment is as follows.

NBU v7.1.0.4

2010 DAG with three members - circular logging disabled on mail databases and enabled for Journal

All servers are running Windows Server 2008 R2 - 64bit

Full backups run successfully; incrementals fail on two members of the DAG. On the servers where the backup fails the same two databases are passive on both. In the Exchange mgmt console all databases report healthy.

VSS writers on all Exchange servers report stable: no error

Here's a sample of the job details:

6/21/2012 9:48:11 AM - Info bpfis(pid=9444) Backup started          

6/21/2012 9:48:50 AM - Critical bpbrm(pid=6452) from client DDPEXCMBX01: FTL - snapshot preparation failed - Error attempting to find volumes to snap., status 130

6/21/2012 9:48:50 AM - Info bpbrm(pid=6452) DB_BACKUP_STATUS is 103         

6/21/2012 9:48:50 AM - Critical bpbrm(pid=6452) from client DDPEXCMBX01: FTL - snapshot preparation failed, status 130  

Thoughts?

[rawilde]

Maurice

Unfortunately there is no real way to find the issue without seeing the bpfis logs from the nodes.  This is under the netbackup\logs\bpfis directory.  Have you tried opening a support case?

[V4]

does volume have ample space to hold snapshots. (DB which are failing)

Also check shadow copie settings by right clicking on drive

Check if you enable it and set it to no limit, does works... I tried this at several times and it did worked.

before that create bpfis dir under logs. and set it to verbose 5 using BAR gui

[Maurice_Byrd · Accepted solution]

I've resolved this issue.  It turns out that it was something that I and Symantec support overlooked - human error.

We were including the Journal database in the Incremental backups. Since circular logging was enabled for Journal the backups were failing.

To resolve this condition, I broke out the databases into separate jobs. Now each database has its own individual backup policy. For Journal I'm only running Full backups