Lost or corrupted device configuration ?

[GHas]

Two robots attached to Master/Media server
OS Solaris 10
NBU 6.5.3

Problem began when the tape storage unit froze up and had to be powered cycled. POST runs without errors.

No faults on the tape storage unit.

The Quantum storage unit supports two configurations one with five tape drives and the other with four.

Media and Device Configuration wizard shows:

Configuration TLD(0) five drives
                    TLD(1) four drives

The new device scans shows:

TLD(0) fives drives listed as (attached to remote host)
Properties for the attached to remote host drives show as "Drive address already occupied by a drive"                                          

TLD(1) four drives and lists them as shared

- sgscan only shows the four drives on TLD(1) and nothing for TLD(0)

Documentation shows the original configuration as:
    TLD(0)     /dev/sg/c5t0|1
    TLD(1)     /dev/sg/c5t0|2
Now shows
    TLD(0)     /dev/sg/c4t0|6
    TLD(1)     /dev/sg/c4t0|1

Tried to change the paths. All paths are found but could not be changed.

Also the drives are configured as HCART instead of HCART2 and the drive type field is blank so even the drives it finds are non-operational.

Deleted all drives and reconfigured - no change
Deleted drives and robots and reconfigured - no change

Any ideas?

Thanks in advance

[Michael_G_Ander]

Could be a bad controller card as the controller have changed from controller 5 to controller 4 and you cannot see the drives for TLD(0).

[Will_Restore]

If sgscan not showing all the drives it's not NetBackup so go back to the hardware & OS level.

One possible cause/fix: http://www.symantec.com/business/support/index?page=content&id=TECH186443

[mph999]

True, unless in the case of Solaris (which this is) the SG driver needs rebuilding ...

[GHas]

UPDATE

After multiple NBU server reboots I am able to see most of the drives.

One twist - the drives now show swapped paths - the drives that were on  TLD0 are now attached to TLD1 and backup policies have to be changed for backup jobs to run.

Backups run OK on TLD1

Backups can also run on TLD0 but although the drives are seen when running config all but one drive is inaccessible with the following message:

"No shared storage option license installed"

The server is a master/media server and the driveson TLD0  are networked using DinoStor.

Any suggestions?

[Marianne]

First thing to check is if OS can see all the devices:
Use cfgadm -al. 

Next step is to ensure Persistent Binding is in place.
Download the utility/tool for hba in this server - e.g. SanSurfer for QLogic. Follow the steps in the documentation to config Persistent Binding.
This will prevent device name changes when server is rebooted.

Next:
Cleanup OS-level device entries:
# cd /dev/rmt
# rm *
# devfsadm - C -c tape
# ls -l *cbn

How many tape drives do you see in the output?
Does this correspond with cfgadm output?
If so, we can go over to NBU.

Use /usr/openv/volmgr/bin/sgscan to see if NBU can see all devices.
If not, rebuild the sg driver:

# cd /usr/openv/volmgr/bin/driver
# /usr/openv/volmgr/bin/sg.build all 

Install the new sg driver configuration:

# /usr/bin/rm -f /kernel/drv/sg.conf
# /usr/openv/volmgr/bin/driver/sg.install

Check/verify config:

# /usr/openv/volmgr/bin/sgscan

Only if all devices are seen here, reconfig NBU devices:
Delete all current tape drives and robots in NBU config, then run Device Config wizard.

Let us know how it goes.

[GHas]

Thanks everyone for your input.

Update: The OS can see the devices. The wizard was for some reason confused.

Through trial and error (and multiple attempts) I was successful re configuring with the Wizard selecting

only the DinoStor devices. All the tape drives have returned without the No shared storage option license installed message.

Running backups however, did not improve too much because only one drive with the DinoStor group would run.

Looking at:

NBU management - Storage - Storage Units

Info appeared OK but did notice several items the were inactive or repetative I assume due to past use or configuration attempts?

It showed a robotic arm TLD0 and 1 and a single robotic arm for NDMP. The limit of the NDMP robotic arm was set to one. I increased it to allow one per path and now three out of five jobs can run with the DinoStor group.

[GHas · Accepted solution]

The final resolution was to reconfigure the robots to match the new configuration.

Some fine tuning to match the configuration required for ndmp clients as well.

Resolved!

kodo