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

[BrianinWI1]

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.

[mph999]

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

[Douglas_A]

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.

[MKT]

This issue started at 7.1, partially fixed in a later release but still an outstanding issue in the 7.5 line.

http://www.symantec.com/docs/TECH164518

[mph999]

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

[robzim]

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]

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