Forum Discussion

Nick_Morris's avatar
12 years ago

Netbackup Catalog Backups Slow Whilst NBAC Is Enabled

Hiya,

 

I was wondering if there's anyone out there who uses NBAC (Netbackup Access Control) with Netbackup and currently experiences a slow catalog backup with it enabled? Here's a little bit of info on the environment:

 

Windows 2008 R2 Enterprise x64

Netbackup 7.5.0.4

 

Before we enabled NBAC, a catalog backup was taking around 30 mins. This has increased to anything between 3-5 hours now. From looking at the catalog backup, it appears to have added a further job which looks to generate between 30-60 files in the /db/NBU_VSSDB_IMAGE/<POLICY NAME>/ folder. These files look to contain registry and security based settings. This is the only part of the backup that has increased in time (it takes around 5 minutes to generate each file). The time to backup the images folder etc is as expected.

 

An option to disable NBAC is unfortunately not an option, as the client requires this to be part of the environment so we can limit access to some users for certain roles. Would there be any particular logs that would be worth looking in to troubleshoot this? I'm struggling to find anything obvious at the moment.

 

I've logged this with support and i am trying to get help that way, but i was just putting it out to the community to see if anyone else has had the "pleasure" of using NBAC and had any ways to get over this issue.

 

Cheers,

 

Nick

  • I've finally got to the bottom of this with the help of Business Critical Support. This relates to this technote http://www.symantec.com/business/support/index?page=content&id=TECH206308 . Basically it's an obscure issue with IBM hardware (x3650 M3 in this case) and the fact it was making bad calls to the EFI system partition and this was slowing down the Catalog DBM queries. Applying EEB 3217366 fixed it for us, as we are on 7.5.0.4

    Regards,

    Nick

  • Haven't seen this before but if you have Anti Virus on the server do ensure that all NetBackup paths have been excluded just in case AV is holding on to those files as they are being produced (or the processes creating them)

  • In general, backups performance will get delayed for 30-45 minutes time for every backup job after VXSS is enabled, when compared to normal backup job. It is due to the authentication made by the AT/AZ server when every netbackup process is queried.

    There are two criteria's of elapsed time
    1) Backup job start/end time - This is the backup job start and end time
    2) Backup write start/end time - This is the exact backup start and end time as it doesn't include the queued/wait time for the job to run.


    Ensure you are taking the elapsed time period for the backup job write time and not the window time. because backup job window time might have delay in waiting for drives/media's to mount which cannot be assumed to be performance issue consideration.

    The bpbrm,bptm logs on the media server with verbose = 5 set on both the logs will be needed to further diagnose the issue.

  • Mark - On access scanning is not enabled on the servers and no signs it's an AV issue

     

    Dyneshia - This is not to do with queue wait time issues or even slow performance of writing the data. It has exclusive access to the library at this time, it is backing up its own data (no other media server involved for this) and the slowness is in the DBM query part of the job, which is prior to it even going to tape. I think you might be onto something with mentioning it needs to authenticate every process. I think this could be what it is doing, but why it would take so long when it is the AT/AZ server and doesn't have very far to authenticate.

  • I've finally got to the bottom of this with the help of Business Critical Support. This relates to this technote http://www.symantec.com/business/support/index?page=content&id=TECH206308 . Basically it's an obscure issue with IBM hardware (x3650 M3 in this case) and the fact it was making bad calls to the EFI system partition and this was slowing down the Catalog DBM queries. Applying EEB 3217366 fixed it for us, as we are on 7.5.0.4

    Regards,

    Nick