Forum Discussion

goose325's avatar
goose325
Level 3
4 years ago

Drives disappeared in NetBackup

I'm running Solaris 11 and NetBackup 7.7.2 and have recently had my robots and drives stop working.  When i go to "UP" the drives they appear to come up and then immediately fail.  The drives themselves are Storagetek SL150s and they are not showing any errors and are at 3.74 firmware version. On the servers, when i run the scan command this is the output on both systems:  ****************SDT_TAPE*************************

      ********************************SDT_CHANGER********************

and no devices are displayed.  I ran tpautoconf -a and got no feedback.  When I opened the GUI and tried to reconfigure the storage devices it founf the robot and tape drive but I still can't bring them UP in the gui.  

Due to the nature of the servers I can't upload logs.

Thanks

 

  • Here is a TN showing how scan works (tpautoconf -t is pretty much the same, just that the output is formatted differently)

    https://isearch.veritas.com/internal-search/en_US/article.100047749.html

    It shows that when you run scan, the scsi commands received by the library look like this:

    Sep 22 04:30:48 vtl-v3 vtllibrary[1568]: CDB (225) (delay 120405): 12 00 00 00 60 00
    Sep 22 04:30:48 vtl-v3 vtllibrary[1568]: CDB (226) (delay 805): 12 01 80 00 84 00
    Sep 22 04:30:48 vtl-v3 vtllibrary[1568]: CDB (227) (delay 2405): 12 01 83 00 84 00
    <snip>

    ... this is all it does - CDB 0x12 is just scsi inquiry

    The numbers after the '12' are just slight variations on what is being queried, for example '12 01 80 00 84 00' would return the serial number of the drive.

    You could run these same commands from another utility (sgscan as Marianne mentioned) and you would get teh same issue - no output.

  • You must likely have a problem between the OS and the devices, not NetBackup.

    scan / tpautoconf only send the scsi inquiry command, and displays the response sent from the drive/ robot.

    Solaris can be a bit of a pain with the sg driver, but if nothing has changed, this shouldn’t be an issue.

    Can you see the devices from the OS ?

    cfgadm -al -o show_FCP_dev I think ...

  • sgscan and scan commands perform a scan at OS-level.

    It seems that the OS lost connectivity to the devices.
    We often say this:
    NBU has no direct connectivity to devices. It relies on the OS for access to devices.

    Please check /var/adm/messages file for hardware errors.
    (If this happened more than 3 days ago, look at messages.*)
    If ALL devices disappeared, my suspicion will be with the HBA.

    • goose325's avatar
      goose325
      Level 3

      I'm seeing the following error repeated on both the media and master servers:

      ID702911 daemon error TLD(1) unavailable initizalition failed, unable to open robotic path

      daemon error, robotic path /dev/sg/c0tw5xxxxx does not exist

      • Marianne's avatar
        Marianne
        Level 6

        goose325 

        Please show us output of this command as per mph999 's request:

        cfgadm -al -o show_FCP_dev

        This error:
        robotic path /dev/sg/c0tw5xxxxx does not exist
        ... means one of 2 things:
        1. The OS has lost connectivity to the device. You need to check physical connections and switch logs.
        2. The device path has changed due to lack of persistent binding.

        Running OS command 'cfgadm' will show you what the OS sees.