Forum Discussion

Lonray's avatar
Lonray
Level 2
13 years ago
Solved

Waiting in NetBackup scheduler work queue

Hi,

I'm using Netbackup 7.1 on a windows 2008 server, and have setup and used a disk staging unit for the first time.  In Activity Monitor I can see that my scheduled policies ran and backed themselves up to the disk, and now a DSSU_POLICY job is writing them to our tape drive tld-1, as programmed...  but I also see that a critical database backup that was not modified to write to disk and that should be writing directly to a different tape drive (tld-0) is queued and not writing.  Checking the job details I see the message " Info nbjm(pid=3204) Waiting in NetBackup scheduler work queue".  Please help me figure out why this job is waiting and how to get it going.

 

Thanks

Backup and Recovery
NetBackup
Windows Server (2003-2008)
  • Dyneshia's avatar
    Dyneshia
    13 years ago

    You should not have a nbrb.conf in 7.x , this was a file in 6.x.  I had found one issue were this file was still left over after the upgrade and caused the issue.

    You really should not be on the base install of 7.1. Please review all "known issues " in 7.x : http://www.symantec.com/docs/TECH153422

    You could patch up to 7.1.0.2 and apply the eeb just to keep this from occurring in the future, however you should be at 7.1.0.4 especially if you use any database products ( exchange , sharepoint and GRT )

    I would check the 7.1.0.4 release notes to see if this etrack is included.

    Here is a hand patchset list : http://www.symantec.com/docs/TECH65429

     

9 Replies

  • Dyneshia's avatar
    Dyneshia
    Level 6
    13 years ago

    What version of NBU are you running ?  http://www.symantec.com/docs/TECH182401

     

  • Dyneshia's avatar
    Dyneshia
    Level 6
    13 years ago

    If the tech note does not apply...

    You can try running the following comand to release all aloociations.  ( this will cause all currnet backps to fail ) 

    bin\admincmd\nbrbutil -resetAll

    Can you also check to see if you have :

    Windows: <install_path>\Veritas\NetBackup\var\global\nbrb.conf

     

  • Lonray's avatar
    Lonray
    Level 2
    13 years ago

    Thanks for replying.  I'm using Netbackup 7.1.  I don't have a global directory under <install_path>\Veritas\NetBackup\, or anywhere in that path. 

    Indecently, when the duplicate to tape job finished, my database backup started and has already completed.  I would like to avoid the delay in the future, though.

    The article might apply to me.  I'm not sure how to tell if I have "large EMM_Image, EMM_ImageCopy and EMM_ImageFragment tables" or what to do about it if I do.  Any ideas on how I can check?

  • Dyneshia's avatar
    Dyneshia
    Level 6
    13 years ago

    You should not have a nbrb.conf in 7.x , this was a file in 6.x.  I had found one issue were this file was still left over after the upgrade and caused the issue.

    You really should not be on the base install of 7.1. Please review all "known issues " in 7.x : http://www.symantec.com/docs/TECH153422

    You could patch up to 7.1.0.2 and apply the eeb just to keep this from occurring in the future, however you should be at 7.1.0.4 especially if you use any database products ( exchange , sharepoint and GRT )

    I would check the 7.1.0.4 release notes to see if this etrack is included.

    Here is a hand patchset list : http://www.symantec.com/docs/TECH65429

     

  • Lonray's avatar
    Lonray
    Level 2
    13 years ago

    I will try applying 7.1.0.4 and see if that fixes it.  Thanks again.

  • Dyneshia's avatar
    Dyneshia
    Level 6
    13 years ago

    No problem, let me know how it goes.  If it resolves the issue, be sure to mark it as solution :)

  • Lonray's avatar
    Lonray
    Level 2
    13 years ago

    I haven't seen this behavior again since installing the patch, so I guess it's fixed!  Thanks so much for your help and advice.

  • mph999's avatar
    mph999
    Level 6
    13 years ago

    As a note.

    nbrb.conf is fine at 7.x  

    It is a perfectly valid file and is used as it was at 6.x to tune and control the behavior of nbrb.

    However, it would be reasonable to suggest that after an upgrade between versions the tuning settings for nbrb are reviewed.

    As mentioned, a change inbehavior caused an issue in one example after an upgrade, this is not a reason to state that the file should not be there 'ever'.  Just suddenly deleting this file couls quite possible break things, that had previously been set for a given system.

    There can be no golden rule, the tuning/ conf files set on one system may completely break another.

    Martin