cancel
Showing results for 
Search instead for 
Did you mean: 

Database system error vaulting exchange images

Graham_McCann
Level 3

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.

1 ACCEPTED SOLUTION

Accepted Solutions

Mark_Solutions
Level 6
Partner Accredited Certified

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.

View solution in original post

4 REPLIES 4

RiaanBadenhorst
Level 6
Partner    VIP    Accredited Certified

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...

Graham_McCann
Level 3

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.

Oddy
Level 5
Employee

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

Mark_Solutions
Level 6
Partner Accredited Certified

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.