after reboot master server my robotic path missed
Configured robots with local control supporting test utilities:
TLD(0) robotic path = /dev/sg76
TLD(1) robotic path = /dev/sg23
TLD(2) robotic path = MISSING_PATH:QUANTUM275102349_LL0
When I run scan command changer not listed,
output of /var/log/messeges
Jun 5 17:43:10 mstr-nbkp-srv last message repeated 17 times
Jun 5 17:43:10 mstr-nbkp-srv tldd: TLD(2) unavailable: initialization failed: Unable to open robotic path
Jun 5 17:43:10 mstr-nbkp-srv tldcd: TLD(2)  robotic path MISSING_PATH:QUANTUM275102349_LL0 does not exist
Jun 5 17:45:09 mstr-nbkp-srv last message repeated 20 times
Jun 5 17:45:12 mstr-nbkp-srv last message repeated 15 times
Jun 5 17:45:12 mstr-nbkp-srv tldd: TLD(2) unavailable: initialization failed: Unable to open robotic path
Jun 5 17:45:12 mstr-nbkp-srv tldcd: TLD(2)  robotic path MISSING_PATH:QUANTUM275102349_LL0 does not exist
Jun 5 17:45:15 mstr-nbkp-srv last message repeated 21 times
Jun 5 17:45:37 mstr-nbkp-srv SQLAnywhere(nb_mstr-nbkp-srv): Starting checkpoint of "NBAZDB" (NBAZDB.db) at Sun Jun 05 2016 17:45
Jun 5 17:45:37 mstr-nbkp-srv SQLAnywhere(nb_mstr-nbkp-srv): Finished checkpoint of "NBAZDB" (NBAZDB.db) at Sun Jun 05 2016 17:45
Solved! Go to Solution.
and see if it has moved to another device; What about the drive, does it still exist ?
If both is missing at all, it seems to be a hardware issue.
Otherwise it could be a kernal module that is not loaded anymore.
So, if your drive is still found *and* just the library is missing *and* there is only one cable that connects to just the drive, than i would check if some kernal module is not loaded.
For example, my HP proliant gets connected to just the drive of the library and the OS must be able to scan multiple lun's to find the robot. The module i need is provided by HP and is called
Hi, I have not sscsi command/script on this server.
Tape drives are still available, Accourding other posts and document I deleted the robotic with missed path and restarted media manager proccess, but now drives known as standalone devices but robotics still not available.
The command is called lsscsi, not sscsi.
I suggest you install it if it is really missing.
Your problem started after rebooting, so you are not interested in what netbackup thinks what devices are available.
You need to find out what the OS thinks about that.
If you delete the robot, i mean what do you expect for the drive ?
It would not have another choice then being listed as standalone.
After checking that the hardware is available and seen by the OS,
1. recreate the robot with the same name it had ( i have not enough knowledge to tell how to find out )
2. Modifiy drive by drive to be contained by that robot again.
3. probably more tasks do do i do not know about.
The OS has lost the robot, either the path has changed on reboot due to lack of persistent binding, or there is a fault. Given it happened after a reboot, I would normally suspect that the path has changed as opposed to fault, but it should still appear in scan, just with a different path.
That said, if you are on Solaris it may not, as the sg drivers might need rebuilding.
So first step, what version of unix are you using, and can the changer be seen from the OS - eg.
HP - ioscan -fn
Solaris - cfgadm -al -o show_FCP_dev
Linux - cat /proc/scsi/scsi
Until the OS sees the device, forget anything to do with NetBackup.