12-28-2012 08:17 AM
Hello, I currently get this error on all tape backups. This started after I was having a problem with a downed drive so I deleted all drives and robot and ran device config to re-add them. All looks good to me otherwise...I'm able to run inventory, robtest detects robot ok, no other errors in gui.
I've done so far:
- Restart nb services
- Restarted nb server
- Seeing these errors in app log:
TLD(0) [4020] Lock of B:\VERITAS\Volmgr\misc\tldcd.lock failed with LOCK_OP_FAILED: Error: -3
Unknown robot number 0, from host us010017.na.ina.com
TLD(0) unavailable: initialization failed: Robot number does not exist
Thanks,
Jamie
Solved! Go to Solution.
12-28-2012 02:56 PM
From my experience if you re-start Netbackup services (all of them) without restarting the (java) gui - some information may be invalid until the GUI is restarted as well.
12-28-2012 10:43 AM
In the GUI under robots - Do you have both TLD0 and TLD1 defined ?. You should be able to delete TLD0 as I believe TLD1 is the active with tape drives defined.
12-28-2012 10:47 AM
I agree with Nicolai.
If you did not restart NBU device management services after deleting devices, new robot was probably added as TLD(1).
Please double-check current device config.
Also check STU properties - if robot is now no. 1, update STU properties or create a new STU and update all policies.
12-28-2012 11:33 AM
12-28-2012 11:57 AM
Please show output of these commands (in <install-path>\veritas\volmgr\bin):
tpconfig -l
vmoprcmd -d
as well as this one (in <install-path>\veritas\netbackup\bin\admincmd)
bpstulist -L
12-28-2012 12:44 PM
12-28-2012 01:01 PM
12-28-2012 02:56 PM
From my experience if you re-start Netbackup services (all of them) without restarting the (java) gui - some information may be invalid until the GUI is restarted as well.
12-28-2012 07:40 PM
This is what I thought from the beginning - that STU was the culprit.
My initial thought was that device config would show robot 1 and STU robot 0.
I have very early in my troubleshooting with NBU learned to rely on cmd output - while collecting output in order to log a Support call with Symantec, I was actually able to pinpoint the problem and fix it without logging the call.