SLP duplication of Granular recovery AD backup causes100% CPU on DC

Hi Riaan,

Interesting, I didn't think of that setting.  I'll give it a go and report back. 

Cheers

I found this in the guide. <<<<Exchange Guide

Configuring the granular restore proxy host

When you browse for or restore individual items using Granular Recovery Technology (GRT), NetBackup uses the destination client to stage a virtual copy of the database that you want to restore. However, NetBackup uses the source client of the backup to stage the database in the following situations: when you duplicate a GRT-enabled backup image or when you use the bplist command.

Alternatively, you can specify a different Windows system to act as a proxy for the client. Use a proxy if you do not want to affect the source client or if the source client is not available. To specify a proxy, configure the Exchange granular proxy host in the Exchange properties for the client.
When you use the bplist command and the bpduplicate command, you can override the Exchange granular proxy host setting with the -granular_proxy option.

NetBackup determines the granular restore proxy host in the following order:
■ The host that is specified with the -granular_proxy option on the command line
■ The granular restore proxy host that you specify in the host properties for the source client
■ The source client
 

Excellent, thanks Riaan.  This did the trick and the process nblbc.exe didn’t start.

My understanding is that without this option selected it means that we can still do a granular restore from the disk copy, but once the image has gone to tape and if the disk copy had expired then we wouldn’t be able to do a granular restore, even if we restore the image to disk first.

Whereas previously once the image had gone to tape we would have been able to restore to disk first then do a granular restore. 

Am I correct here?

Hi,

Yes, that is correct. If you still want the catalog'd version you could use the proxy option so its catalog'd on another server.

Great, thanks Riann, you have been very helpful.

 Just one more thing, although I think I’ll need to start a new post for this one. 

Shortly after this backup policy was setup we have been experiencing a really strange issue.  Random restore jobs keep appearing in the activity monitor.  These jobs refer to the Advanced disk pool (we only have one).  They last about a second or two and complete successfully.  They occur every minute or so and then periodically stop for about 40 minutes.  This have been going on now for around two weeks.  It’s been logged with Symantec and so far they haven’t found a solution. 

This is all we get in the detailed status of the job (I’ve replaced the media server name with “MS00000”)

11/07/2011 11:50:30 - requesting resource @aaaak

11/07/2011 11:50:30 - granted resource MediaID=@aaaak;DiskVolume=E:\;DiskPool=RDR-Adv-MS00000-1;Path=E:\;StorageServer=MS00000;MediaServer=MS00000

Thanks again,

Al

Hi,

This usually happens when you browse a GRT backup, exchange, AD, etc. As you go deeper into the Storage Group, User Mailbox, Mailbox structure it kicks of a quick "restore". You can check this out by browsing the a backup in BAR, you'll see it hangs while the "restore" is busy, and as soon as its done you're able to browse the next level.

I assume this is normal behaviour as I've seen it do that at a lot of customers. Unless I've lost the plot :P

Ok, I see. 

The problem is that no one is using BAR to do a restore.  They just keep appearing on their own accord.  I've rebooted both media and master server but the jobs continue to appear.  I've attached a screenshot.

I appreciate your help on this as it's driving us crazy.

Have a look at bprd logs to see where they're being initiated from.

Nothing is logged in the master server’s BPRD log to tell me what’s going on (logging level is set at maximum).  Here’s a section from it at the time when one of the restore jobs started and completed. 

Any more ideas?

Job overview Client = MasterServerName

Master Server= MasterServerName

Detailed status

1/07/2011 13:50:32 - requesting resource @aaaak

11/07/2011 13:50:32 - granted resource MediaID=@aaaak;DiskVolume=E:\;DiskPool=RDR-Adv-MS0000-1;Path=E:\;StorageServer=MS0000;MediaServer=MS0000

BPRD LOG

13:50:08.088 [3868.4032] <4> msgbackup: waiting for response from nbpem

13:50:08.447 [6000.3480] <2> vnet_cached_getaddrinfo_and_update: ../../libvlibs/vnet_addrinfo.c.1370: 0: found in cache name: MasterServerIPAddress

13:50:08.447 [6000.3480] <2> vnet_cached_getaddrinfo_and_update: ../../libvlibs/vnet_addrinfo.c.1371: 0: found in cache service: NULL

13:50:08.447 [6000.3480] <2> vnet_cached_getaddrinfo_and_update: ../../libvlibs/vnet_addrinfo.c.1370: 0: found in cache name: 127.0.0.1

13:50:08.447 [6000.3480] <2> vnet_cached_getaddrinfo_and_update: ../../libvlibs/vnet_addrinfo.c.1371: 0: found in cache service: NULL

13:50:21.088 [3868.4032] <4> pingpem: pinging nbpem

13:50:21.088 [3868.4032] <4> pingpem: waiting for pem to reply to ping

13:50:23.088 [3868.4032] <4> pingpem: ping of nbpem succeeded

13:50:40.088 [3868.4032] <4> msgbackup: waiting for response from nbpem

13:50:51.089 [3868.4032] <4> pingpem: pinging nbpem

13:50:51.089 [3868.4032] <4> pingpem: waiting for pem to reply to ping

13:50:53.089 [3868.4032] <4> pingpem: ping of nbpem succeeded

13:51:09.448 [6000.3480] <2> vnet_cached_getaddrinfo_and_update: ../../libvlibs/vnet_addrinfo.c.1370: 0: found in cache name: MasterServerIPAddress

13:51:09.448 [6000.3480] <2> vnet_cached_getaddrinfo_and_update: ../../libvlibs/vnet_addrinfo.c.1371: 0: found in cache service: NULL

13:51:09.448 [6000.3480] <2> vnet_cached_getaddrinfo_and_update: ../../libvlibs/vnet_addrinfo.c.1370: 0: found in cache name: 127.0.0.1

13:51:09.448 [6000.3480] <2> vnet_cached_getaddrinfo_and_update: ../../libvlibs/vnet_addrinfo.c.1371: 0: found in cache service: NULL

13:51:12.089 [3868.4032] <4> msgbackup: waiting for response from nbpem

13:51:21.089 [3868.4032] <4> pingpem: pinging nbpem

13:51:21.089 [3868.4032] <4> pingpem: waiting for pem to reply to ping

13:51:23.089 [3868.4032] <4> pingpem: ping of nbpem succeeded

13:51:44.090 [3868.4032] <4> msgbackup: waiting for response from nbpem

13:51:51.090 [3868.4032] <4> pingpem: pinging nbpem

13:51:51.090 [3868.4032] <4> pingpem: waiting for pem to reply to ping

13:51:53.090 [3868.4032] <4> pingpem: ping of nbpem succeeded

13:52:10.449 [6000.3480] <2> vnet_cached_getaddrinfo_and_update: ../../libvlibs/vnet_addrinfo.c.1370: 0: found in cache name: MasterServerIPAddress

13:52:10.449 [6000.3480] <2> vnet_cached_getaddrinfo_and_update: ../../libvlibs/vnet_addrinfo.c.1371: 0: found in cache service: NULL

13:52:10.449 [6000.3480] <2> vnet_cached_getaddrinfo_and_update: ../../libvlibs/vnet_addrinfo.c.1370: 0: found in cache name: 127.0.0.1

13:52:10.449 [6000.3480] <2> vnet_cached_getaddrinfo_and_update: ../../libvlibs/vnet_addrinfo.c.1371: 0: found in cache service: NULL

13:52:16.090 [3868.4032] <4> msgbackup: waiting for response from nbpem

13:52:21.090 [3868.4032] <4> pingpem: pinging nbpem