Video Screencast Help

NetBackup SSO - issues writing to tape library across the domain

Created: 20 Jan 2013 • Updated: 25 Feb 2013 | 4 comments
This issue has been solved. See solution.

I am having some issues in writing to a shared (SSO) library from across the AD domain. We have capacity based licensing model using NetBackup version 7.1.0.4

There are 2 x AD domains A.local & B.com: There is a firewall between the two AD domains. However, upon request all the ports for AD and NBU across the firewall have been allowed. The name resolution has been tested.

The A.local domain has 1 x NBU Master and 2 x Media servers (on seperate physical boxes) running on Windows 2008 R2.  The shared tape library (4 drives) is zoned to one of the Media server in A.local domain. The 4 drives are also shared for NDMP backups.

Issue:

Now, a new Media server on Windows 2008 R2 in B.com domain has been introduced connected to the NetBackup Master server in A.local. The new Media server is able to communicate with the Master server and completing successful backups (of some B.com domain clients, some failing with handshaking issues) to the storage disk pool attached to this Media server. I managed to add the library and all 4 x drives through the storage configuration wizard and it allows me to create storage pool.

When I try to duplicate the backups from B.com Media server using the tape library connected to A.local Media server, the duplicate job hungs with error "the drives are down". When I look at the device status, the drive showing the new media server name against it shows AVR mode.

On the new media server i ran "vmoprcmd -d -h", the output is as follows;

PENDING REQUESTS

                                     <NONE>

                                  DRIVE STATUS

Drv Type   Control  User      Label  RecMID  ExtMID  Ready   Wr.Enbl.  ReqId
  0 hcart2   AVR                -                     No       -         0
  1 hcart2   AVR                -                     No       -         0
  2 hcart2   AVR                -                     No       -         0
  3 hcart2   AVR                -                     No       -         0

                             ADDITIONAL DRIVE STATUS

Drv DriveName            Shared    Assigned        Comment
  0 SL500-P2_LTO5_D1      Yes      -
  1 SL500-P2_LTO5_D2      Yes      -
  2 SL500-P2_LTO5_D4      Yes      -
  3 SL500-P2_LTO5_D3      Yes      -

 

Comments 4 CommentsJump to latest comment

Marianne's picture

Is port 1556 open in both directions between new media server and robot control host?

Do both media servers (new and robot control host) have SERVER entries for one another?
Forward and reverse lookup fine beween these 2 servers?

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

SOLUTION
Itegral's picture

Is there a way (command) that I could confirm that port 1556 is open in both directions between new media server and robot control host?

Forward and reverse lookup are successful between the existing media server ( robot control host) and new media server.

I shall check tomorrow whether both media servers (new and robot control host) have SERVER entries for one another.

Does it have to be short name or FQDN or BOTH?

Marianne's picture

A quick test would be to telnet on port 1556 from both media servers to one another.

There are no rules as far as short name or FQDN are concerned, just as long as forward and reverse lookup is working properly.
If you are using DNS, test 'nslookup <hostname>' and 'nslookup <IP address>'
If reverse lookup of IP address only resolves FQDN, best to use FQDN as SERVER entries.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

Itegral's picture

Apologies - It helped, matter resolved by carefully putting Master server hostname entry in the remote client's host files and registry (under Server).

Also, I must admit that the NEW media server didnt have local host entry for the existing media server (did have entry for existing Master server/media but not for the 2nd Media server). Once added, restarted the media server services and now able to see the Drive Control in New media server as TLD.