Common configuration issues with Shared Storage Option
If you cannot obtain full functionality after you configure SSO, consider the following:
Verify that the SAN hardware uses current firmware or drivers. Hardware includes hubs, switches, HBAs, and bridges.
Verify that the JNI HBA failover value was set to zero to avoid I/O hangs. This value applies to bridges and HBAs.
Verify that the HBAs with the SCSI-3 protocols are compatible with the operating system drivers.
Verify that your cluster configuration is supported.
For more information about cluster configuration, see the NetBackup Release Notes, available at the following URL:
Verify that all of your Fibre Channel devices support your Fibre Channel topology. For example, in a switched fabric topology, ensure that all devices supported switched fabric.
Verify that Shared Storage Option is licensed on each server. To do so, select Help > License keys from the NetBackup Administration Console on each server. To enable the Shared Storage Option, enter the Shared Storage Option license on each server.
Verify that you configured Shared Storage Option from the master server. You must configure SSO from the master server not from a media server (or SAN media server).
Verify that you configured the same robot control host on every host. Remember that except for ACS robot types, only one host controls the robot.
Verify that you used the Device Configuration Wizard rather than the tpconfig utility to configure Shared Storage Option. The wizard coordinates configuration with all hosts that share the drives. The tpconfig utility may create inconsistent configurations.
Verify that you selected the appropriate device hosts in the Device Configuration Wizard , including the host with robotic control.
Fibre Channel connections to the drives and the robots cause increased complexity in a NetBackup device configuration. On some operating systems, SCSI-to-fibre bridges may result in inconsistencies in the device paths when you restart a host. After a restart of the host, the device configuration should be verified.
Verify that names across all systems that share the drives are consistent.
Test the drive paths on every media server.
Define NetBackup storage units for each media server. Do not select any available media server in the storage units.
Verify that you did not interrupt a data path during a backup. If you do, the NetBackup job fails. It can fail with media write errors or it may hang and have to be terminated manually.
Verify that you do not use Berkeley-style close on the tape path (UNIX or Linux servers only).
On Solaris systems, verify the following:
That you added tape configuration list entries in /kernel/drv/st.conf (if needed).
That you defined configuration entries for expanded targets and LUNs in sg.links and sg.conf files. If you see problems with the entries in the /etc/devlink.tab file (created from sg.links), verify the following:
The first entry uses hexadecimal notation for the target and LUN. The second entry uses decimal notation for the target and LUN.
Use a single tab character between the entries; do not use a space or a space and a tab character.
That you configured the operating system to force load the sg/st/fcaw drivers.
For more information, see the Solaris chapter of the NetBackup Device Configuration Guide, available at the following URL: