It is generally good practice to persistent bind your target/scsi number against a device's WWN.
It is not really a matter of whether BUExec or Netbackup recommends it or not, it is an OS thing. If either the OS itself or the device on the other side (e.g., a robot or tape drive) is rebooted, the device's target number on the OS might change, unless you binded it against the device's WWN.
The reason why BUExec doesn't really talk about this issue in its documents is probably because, to some extend, it doesn't really need it as much as Netbackup does. (Reason explained further down) Does it make BUExec better? Not really, because you sacrifice some level of "control" for this convenience.
Since you are a seasoned Netbackup admin, you should know that in Netbackup, you have to go through the device configuration wizard (or use the tpconfig/tpautoconfig commands) to "officially register" the robot/tape drives on the host with Netbackup, before Netbackup will use them. This has the benefit that if you choose to, you can fine tune exactly which robot/tape drive you would let Netbackup use, or not use. With this level of control, however, comes the problem of changing target numbers when things reboot. Without persistent binding, you have to modify existing "bad paths" inside Netbackup to "update" it about the news. In short, Netbackup doesn't automatically query the OS of target number changes.
With BUExec, everytime you reboot, BUExec rescans everything. Every drive, every path. Conveniently, that also means BUExec always gets the latest target numbers by querying the OS automatically everytime its services [re]start. The only downside is, you can't really do the Netbackup thing where you get to choose exactly which drive you want it to use or not. BUExec will ALWAYS use (and claims ownership of) every single drive it sees on the OS. (On Windows, that means every robot/tape drive BUExec sees inside Device Manager, BUExec owns. No exception, no escape).
In the end, this isn't a big deal. You don't usually zone a robot/drive to a host unless you want BUExec on the host to actually use it. It is just that with Netbackup, you can tell it not to touch the robot/drive even when the thing is right there inside Device Manager. With this level of control, comes the problem of not-automatically updating the target number, and therefore the need for persistent binding to prevent the target number from changing in the first place.
The only reason I could think of for zoning, say, for example, 2 drives to a host but only wanting Netbackup to use one, would be that the other drive is supposed to be used by a different application on the same host. Example: Netbackup uses one drive, NTBackup uses the other, conflict free.
With BUExec, if you zone 2 drives to its host OS, BAM! BUExec claims them both. Neither one will be available to another application anymore, and you can't tell BUExec to "let go" of either one. It won't.
If you are just looking for a simple yes/no answer (and skipped all of the above), then yes, always use persistent binding regardless of your backup application, it's good practice.
RLeon
