Forum Discussion

BrianinWI1's avatar
BrianinWI1
Level 2
13 years ago

Restores queuing for 60+ minutes before beginning execution, Netbackup 7.5.0.3

We have just upgraded from 7.0 to 7.5.0.3 on our master and media servers. They are running on Sun Solaris version 10. Previously we had no issues with restores, but now it seems that most of our restores are remaining in a queued state after being submited from anywhere from 30 to 60 or minutes before they begin execution. Once they begin running, they restore fine with normal transfer rates and complete successfully.

Has anyone every come across this issue before and do you have any suggestions on where to look to reduce the "queued" time ? The backups seem to run as they did prior to the upgrade, it seems to only be a problem with the restores.

 

Backup and Recovery
NetBackup
System Recovery (core)
System Recovery File and Folder Backup

6 Replies

Replies have been turned off for this discussion
  • robzim's avatar
    robzim
    Level 2
    5 years ago

    seeing this with netbackup 8.0 on a new rhel linux server with 1TB RAM and 32 cores.  bprd process stays at 100% CPU while the job is queued.  some jobs do not queue and start restoring almost instantly, but when the jobs queue for more than a minute, they are staying queued for > 5 hours.

    • Nicolai's avatar
      Nicolai
      Moderator
      5 years ago

      robzim This is a thread from 2012. Please start a new thread to discuss current issues.

  • mph999's avatar
    mph999
    Level 6
    13 years ago

    Well done MKT, I had completely forgotten about that, you could be onto something there.

    What is really annoying is that I have seen thaat exact issue a few times, and still forgot about it ... and thus, got the logs a bit wrong  - still the IRM logs would narrow it down.

    Looking at the etrack, there are EEBs available for :

    7.1

    7.1.0.1

    7.1.0.3

    7.1.0.4

    7.5.0.3

    ... so it looks like an EEB could be the answer, and you'll need to look in the bpdbm log as per the TN.

    If it is not this, then I think the logs as I suggested, but include bpdbm and bprd as well ...

    Martin

     

  • Douglas_A's avatar
    Douglas_A
    Level 6
    13 years ago

    You might want to check the Multiplexed restore delay and see if someone set it to some other value..

    Obviously this depends on the type of restore but its default of 30 seconds if someone put something like 360000 or some rediculous number it might cause the delay.

  • mph999's avatar
    mph999
    Level 6
    13 years ago

    nbrb / nbjm / nbemm / nbpem log.

    Log call with Symantec

    Ask that the logs are put through IRMA.  If enginner not aware of this, ask them to ping a UK engineer who will be.

    This may not give a exact answer, but it is the quickest way to spot where the selay is.  May need 167 and 137 logs enabling (these go into the above logs).

    vxlogview can be run by the TSE, but must be run with -d all option

    Martin