Given you have missing devices, I suspect this is the cause of your issues. Though the post aboves points out there could be other casues, and there can, lots ... but most of these a OS / Hardware related. bptm log is a good place to start, as is Activity Monitor. More complex issues may require volmgr logs and other more involved troubleshooting. Step one for you is to determine, that when a drive goes down, is it visible at the same path to the OS.
Also, when a drive is down, what do you do to get it back up.
NBU tracks drives by serial number. If, for example a drive with SN 1234 disappears from the OS (or the path changes) then NBU will list this as a missing device.
The way to stop this is to configure persistent binding, which is done via the HBA utility (sansurfer or HBAnywhere, depnding on the brand of the HBA).
If you really are losing the paths to the drives, then you have a SAN issue between the OS and the drive.
So, if you have 10 drives, then one goes down and the OS still sees 10 drives in total, then it is likely the path changed. tpautoconf -report_disc would then show the missing device (because it can't find the drive with serial number xxx at drive path yyy). If report_disc also shows a 'new device' with serial number xxx but at a new path zzz, then the path changed and persistent binding should resolve the issue.
In summary, given what I see, you don't have a NBU problem, you have a SAN problem which in turn is affecting NBU.
Once all the drives are vsible to the OS, you could use tpautoconf -replace_drive option to tell NBU that the drive with drivename abc is now at path xxx. This should clear, I think, the drives reported as missing. Other option is just to delete everything (nbemmcmd -deletealldevices -allrecords (this will delete ALL robots and drives from every server)), make sure the OS can see everything, set up persistent binding and then reconfigure.
