07-27-2011 03:54 AM
We've been having some intermittent problems vaulting Microsft Exchange 2010 images to tape, with the duplication erroring with "Error bpduplicate (pid=8491) Duplicate of backupid dag_1310792849 failed, database system error (220)".
The initial backup from Exchange works perfectly every time and this primary copy goes onto a DataDomain system. The secondary copy gets vaulted to a second DataDomain system. The tertiary copy is the one we're having the problems with. Our Exchange backups are split into four different images to cover the full alphabetic range of mailboxes. We usually get two or three of the images to duplicate correctly, but the others fail with the above message.
The problem seems to occur around the Granular Recovery, as the error occurs during or just after it catalogues all the elements of the mailbox store. Once an image has failed to be catalogued it will never vault to tape, no matter hoe many times I rerun the vault. Is there any way of forcing a re-catalogue of an exchange backup?
I have intentionally ommitted adding any log files here (or even excerpts) as there is a ridiculous amount of information in them and I wanted to get some ideas first.
Solved! Go to Solution.
10-03-2011 03:26 AM
Hi
The GRT cataloging information needs to access your Exchange Server during the process - it uses the nblbc process
If it cant get to your exchange server then you will need to allocate a GRT Proxy Host to use (in its client host properties - Exchange Section)
This must be a Windows Server and can be a Media Server or even a NBU client but will need NFS configuring in the same way as the original Media Server backing it up had.
07-27-2011 04:07 AM
I suppose its some other media server trying to do the duplication to tape, and not the one that was involved with the backup, or the first duplication?
It could be that the media server in question is not able to access the exchange server so it can do the cataloging. Maybe...
07-27-2011 05:48 AM
Although we have a media server as well as the master, both have access to all the exchange boxes and we have tested NFS connections between them all and they seem to be fine.
07-27-2011 06:11 AM
It sounds like there might be a communication issue between the master bpdbm process and the exchange server or it could be that the connection in timing out. It might help to increase the client read timeout on the master and the exchange server.
To find out what is going on you can create following log directories,
master
<install dir>\netbackup\logs\bprd
<install dir>\netbackup\logs\bpdbm
media
<install dir>\netbackup\logs\bpbrm
<install dir>\netbackup\logs\bptm
<install dir>\netbackup\logs\nbfsd
on the exchange DAG server.
<install dir>\netbackup\logs\bpcd
<install dir>\netbackup\logs\nbfsd
<install dir>\netbackup\logs\ncflbc
Look for the status 220 in the bpdbm log and check where this connection goes to. The bpdbm log might be big, so I would recommend to remove the folder after you have resolved the problem.
I hope this helps.
/Oddy
10-03-2011 03:26 AM
Hi
The GRT cataloging information needs to access your Exchange Server during the process - it uses the nblbc process
If it cant get to your exchange server then you will need to allocate a GRT Proxy Host to use (in its client host properties - Exchange Section)
This must be a Windows Server and can be a Media Server or even a NBU client but will need NFS configuring in the same way as the original Media Server backing it up had.