cancel
Showing results for 
Search instead for 
Did you mean: 

Drive/Robot Down after Library Reboot

Liew_WK
Level 4
Hi All:
We having problem to bring up the drives/robot after ADIC library been reboot. The only way is to reboot the server rather the netbackup services...

:)
20 REPLIES 20

Jeffrey_Redingt
Level 5
That would be correct. Especially if you are using Windows. Once the library is rebooted, it drops off the scsi chain and Windows loses communication with it, you will not be able to re-establish communication until you reboot and the scsi bus is rescanned.

Stuart_Whittet
Level 2
I am having a similar issue, whereby Windows 2003 does not see the robot and drives until a Manual Scan is performed in Device Manager. Once all the devices are visible again we have then tried to perform a backup with mixed results.

Of course a reboot does solve the problem, however this needs to be done across all media/SAN media servers in the environment...a little concerning...and disruptive...

Any ideas???

:(

Liew_WK
Level 4
I found a Microsoft hotfixe... some how I just can't apply it to my enviroment, It involve too much of site.
Anyone one want to have a try ?


http://support.microsoft.com/default.aspx?scid=kb;en-us;873337

Let me know any good news. Thanks.

Terrance_LB
Not applicable
I'm having the same problem
My topology is a ADIC Scalar 100 w/6 LTO drives an I'm using emulex LP952 NIC in my 3 media servers (1win 2003 and 2 win 2000) and 1 master sever (Win 2000) all connected to a Brocade switch. So I used the hotfix you suggested and unfortunately it does not work. But note the Win 2003 server never need to be rebooted when the library goes down.

Jeffrey_Redingt
Level 5
If you are using Emulex cards you want to make sure they are at the latest driver and firmware. The earlier drivers and firmwares had issues with devices dropping off the SAN. Also with Windows 2003 you want to make sure to turn off the Test Unit Ready portion of Windows plug and play or use the Veritas drivers that do not respond to that command. That also caused devices to drop off the SAN. The technotes that explain this issue are in the technote links below:

http://seer.support.veritas.com/docs/270183.htm
http://seer.support.veritas.com/docs/268245.htm

Hope this helps.

Stuart_Whittet
Level 2
Well, we implemented the hotfix and retested with the following results...

Windows 2003 does not require a reboot to see the drives, however when we ran a test backup across our 4 media servers we got very different results...basically most jobs just hung and reuqired a reboot...

We are logging a call with Veritas Tech Support...I will update this when I have more info...

By the way, we are now using the Veritas drivers (with the plug and play option selected) and the most recent device mapping file...

One suggestion is that the problem may be caused by having both disk and tape resources allocated to the same HBA???

Comments please...

Jeffrey_Redingt
Level 5
That absolutely could be a problem. All of the HBA manufacturers recommend that tape and disk drives be on different HBA's due to the effect that different HBA settings have the different devices. I would absolutely advise you to move the tape off to its' own HBA.

Liew_WK
Level 4
We having different HBA for DATA & for BACKUP.

Still work on the solution.

Scott_Murray
Level 3
As an update (to Suart Whittet's info above, since I work with Stuart) - the current situation is that we have applied the noted Microsoft hotfix (TechNote #873337), and also installed the Veritas plug-n-play tape device drivers.
We can now happily "see" tape drives from all SAN Windows servers, but NetBackup had intermittent problems using these drives.
So the next step was to delete the complete tape drive and robot config across all Master/Media Servers from theAdmin Console. Then redetect/re-create this device configuration across all Master/Media Servers from the Admin Console.
NetBackup then appears to work fine !!
All this without rebooting any SAN Windows Servers.
However, in a large environment, that's a fairly drastic step to have to take.
Anyway, we're working on this with Veritas tech support at this stage.

Liew_WK
Level 4
I have tested on firmware/drivers on Emulex, it seem not much different.
I will try to install the hotfixe to DR systems.

patrickkuah
Level 6
Do persistent binding :)

Liew_WK
Level 4
I had try for Persistent Binding, but it seem still the same problem. :)

patrickkuah
Level 6
post the syslog or the event viwer error here.

Basically, ensure you using VERTIAS latest driver with PnP enabled, HBA firmware and driver are the latest, persistent binding are done

Also check if your hardware is in the VERITAS HCL list.

patrick :)

Liew_WK
Level 4
we have some restricetion of firmware/drivers support while we have hba connection from SFW4.1 - XP12000.

P_Kim
Level 2
I'm so pleased that I am not the only one with this problem. Is anyone using EMC's SAN? If so, I had some success by disabling powerpath. Has anyone else tried this? Thanks.

Tommy_Wu
Level 3
I would never install and using PNP driver for SSO tape drives. You may use PNP drive for direct attached tape drives but not for SSO tape drives. If you guys using the Veritas tape driver, read before click on next, it has a warning text readme file during the driver installation.
T.Wu

Tommy_Wu
Level 3
We have about 40 SSO media servers connected to the EMC SAN. All mix OS, Win2k,Win2k3, HP_UX and IBM Aix. Do not use EMC Power Path. EMC uses AutoNegotiate for all SAN Ports, you may need to have them hard set the Fibre port speed (1GB or 2GB). The hosts will drop the tape drives if the SAN Ports set to use Autonegotiate(Windows)

P_Kim
Level 2
Thanks for the info Tommy. So in your environment, there is no failover on your HBAs since you are not using powerpath? Thanks.

Tommy_Wu
Level 3
We do use powerpath In our SAN environment, but we only zone the SAN tape drives to one HBA(single path), not both HBA. We hard set the HBA speed and the tape drive problem disappear.