Backup Network Example Configuration

From World History Wiki
Jump to: navigation, search
World History Wiki is Brought to you by:
S.J.'s Adventures

In order for Backups and Client side (User Directed) functionality to work within a NetBackup environment requires communication between the Master server and Client as well as the Media Server(s) and client. This document gives examples of network and client configurations to insure communication in allowed while still protecting and segregating the clients from each other.

Ensuring all clients can communicate with all media servers, and the master server enables backup servers to be load-balanced and allow for fail-over between media servers, as well as ensuring all client side functionality works properly; however it also poses security challenges.

This technote my also be helpful in understanding why we these communications are needed:

The NetBackup 7.1 release notes also say that future versions my require the client to access the Master Server in order to complete the software installation. Most advanced client features also require communication with the Master Server.

Network Requirements

Subnet Routing

The Master Server, Media Servers, and Clients all have a dedicated network connection into segregated networks interface depending on the type of system it is. A vitalized, or high performance physical router(s) are placed in the middle to allow communications.

For example, The Backup Networks could be as follows:

Corp Clients - VLAN 201 -
Ship Clients - VLAN 202 -
WebE Clients - VLAN 203 -
Othr Clients - VLAN 204 -
NBU  Servers - VLAN 205 -

The router(s) allow the four client networks to talk to the NBU Server network, and vis-versa, but the client networks are not allowed to talk to each other.

This also requires static routes to be placed on all nodes involved.

This allows for physically diverse LANs to be interconnected, such as were servers are psychically separated. Multiple NBU server VLANs can also be implemented for physically diverse locations.


All servers and clients live within the same sub-net, but with separate VLANs.

NBU Server VLAN is in promiscuous mode allowing it to talk to any and all nodes on the subnet.

Clients are set in a different VLAN that only allows communication with servers in the promiscuous VLAN.

This removes a need for any static routes, but requires all nodes to be on the same LAN.


The two above examples can also be combined so that physically local servers are on the same Subnet, but physically diverse servers are connected via a router.

Checking Network Connectivity

  • On Windows run
    ipconfig /all
  • On Unix run
    ifconfig -a

Check to see that you have an IP address on the appropriate network(s). It is also useful to note the MAC address for the respective NIC.

Network Security and Ports

TCP Ports

Individual port requirements are not necessary in most cases, unless for some reason backups cannot be performed via the Backup network. These exceptions should be justified, and will likely require require firewall ports be open between the NetBackup servers and the client over an alternate or "public" network.

Communication must be allowed between these interfaces via PBX (1556) and VNETD (13724). These are the two most basic network communications processes (ports) used by NetBackup.

RDP (3389) and SSH (22) are also required to enable remote management and troubleshooting from the NetBackup Servers to the clients. NDMP is also used for advanced features used with de-duplication appliances. Other ports are also required for allowing NFS and CIFS to be used from de-duplication appliances to servers that require direct access to these systems. Client side functionality can require random TCP High Ports (newer versions of NetBackup can be configured to avoid this).

Other ports will be used outside of the Backup networks, from the Master Server and appliances to allow for use of HTTP, CIFS, SSH, to provide informational and management consoles primarily used on desktops and laptops. These usually cannot traverse the backup network, but often require firewall ports be opened to "public" networks.

ACLs & Routers

A virtual router is used between each backup network along with ACL's to prevent unauthorized communication between networks, but still allow full communication necessary between NetBackup servers and clients.

Static Routes

Static Routes on Servers and Clients are also required in some models.

Static Routs must be persistent threw reboots, which on some systems will require having them re-applied at start-up.

NBU client side routes

Each NBU client in the backup network will need one of the following routes depending on which network it is in:

Route dest: gateway
Route dest: gateway
Route dest: gateway
Route dest: gateway

To view routes currently on a Window system, from a command-line run the following

route PRINT

In the Persistent Route section of the output, make note of the route statement for the appropriate network listed above.

Click here for more information on Verifying routes on Windows

  • To add a new persistent route on Windows:
    route -p ADD <destination-network> MASK <destination-subnet-mask> <gateway> METRIC ## IF <interface number>
    For an example of UNIX/Linux routes see the "NBU server side routes" section below.
The appropriate gateway to use will depend on the network to witch the system is connected.
Double check the list of IP addresses on the system against the above list of routes for the appropriate gateway.
The interface number to use for Windows shows up in the Interface List when you do the "route PRINT" command, and associate the MAC address to the "ipconfig /all" output.
  • To remove a stale or inappropriate route on Windows use this command:
    route delete <destination-network>

NBU server side routes

All NetBackup Servers will need all of the following routes (one for each client subnet):

Route dest: gateway
Route dest: gateway
Route dest: gateway
Route dest: gateway
Route dest: gateway

Each OS is different, but as a last resort for UNIX you can usually set these routes with a startup script:

vi /etc/init.d/
## Static routes for Nexus clients
route add -net -netmask -gateway
route add -net -netmask -gateway
route add -net -netmask -gateway
route add -net -netmask -gateway
chmod +x /etc/init.d/
cd /etc/rc3.d && ln -s ../init.d/ ./
echo "" > /etc/hostname.nxgeN (Where NNN is the IP for the server, and N is the Interface number)

Testing Routes

To test that routes are properly inputted, you can ping the NetBackup servers Backup NICs by DNS name and/or IP.

If you can’t ping the NetBackup server or the interface won’t come back online in the failover cluster administrator. Look to see if there is an active route for the gateway network address.

For example, if the route statement gateway is we should have a route to the network listed in the persistent routes or routing table. If it is missing you will need to add it using the commands/procedures listed above.

DNS Requirements

  • Forward and Reverse DNS must match
    From both the server and the client, a look-up on the IP should return the backup interface FQDN DNS name, with no additional entries.
  • A static entry for the backup interface name must be configured within the server's default/primary domain.
    This requires that the backup NIC be set to NOT automatically register it’s IP in DNS.
  • It is also important to note that the client name in NetBackup and DNS are case sensitive and must also match (lower case is usually preferred for a UNIX/Linux Master).
  • Due to the complex nature of DNS in many environments the use of FQDN's for all server and client names is advisable.

Client Software Configuration

Server List

The Client's server list must be configured such that it ONLY uses the NetBackup Server's interfaces that it can access over the backup network. Additional server listings may not cause negative effects, but can create confusion and sometimes create issues with client initiated functionality.

I.E.: nbu01bkup works, but nbu01 does not work because the client doesn't have the ability to communicate with nbu01's public interface. It could end up trying to go threw a firewall and get blocked.

Windows Clients Server List

On Windows, the server list can be fixed/updated by editing the configuration from the "NetBackup Client Properties" within the Backup, Archive, and Restore console.

However an easier and more consistent way is via the registry, or remotely from the Master Server (The master must be able to reach the client and a restart of the client service is often necessary after changing, thus doing it from the client is the only guarantee for updates to work).

The Windows Registry entry for server lists is:

My Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Veritas\NetBackup\CurrentVersion\Config\
Name                   Type               Data/Value
Server                 REG_MULTI_SZ ...

The best option for windows is to have the NetBackup Client install script updated appropriately to populate the correct server list at install.

Client Name

The client name must specify the backup interface Fully Qualified Domain Name (FQDN) within the client software configuration.

I.E. "" works, but "sql6bkup" and "sql6" doesn't because the client will either report back the wrong name to the NetBackup Servers, the NetBackup server will not be able to find the client in DNS, and/or the client will try to use the wrong network interface to contact the NetBackup servers.

This can be updated from the "NetBackup Client Properties" within the Backup, Archive, and Restore console.

This can be easily checked by running the command [INSTALLPATH]\NetBackup\bin\bpclntcmd.exe -self which should return a single line for the client name and FQDN.

The Windows Registry entry for Client Name is:

My Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Veritas\NetBackup\CurrentVersion\Config\
Name                   Type               Data/Value
Client_Name            REG_SZ   

Registry Edits for Windows Clients

Registry entries for the NetBackup software can be updated to insure the NetBackup Client software reflects the correct network interfaces

It is expected that modifying these entries will be the easiest way to incorporate them into the install script (or SCCM).

The following is a list of example registry entries that need to be modified after the client software is installed (note the "bk" that was added to the end of each entry):

My Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Veritas\NetBackup\CurrentVersion\Config\
Name                   Type               Data/Value
Browser                REG_SZ   

Client_Name            REG_SZ   

Clients                REG_MULIT_SZ
                                 (cluster resources)

The Server list is found under:

Name                   Type               Data/Value
Server                 REG_MULTI_SZ ...

Many of these setting can be changed from within the Backup, Archive, and Restore console (but not all). It's best if the NetBackup Services are restarted after making any of these changes.

Helps with Cluster Restores

There's an optional windows registry entry that can be added to help improve performance on some clients (but not all - will cause problems for "Active" "Active" clusters in a failed-over state or servers with multiple virtual client names), especially with doing restores in cluster environments for a client name that relates to a clustered resource interface:

Name                   Type               Data/Value
Required_Interface     REG_SZ   

(on UNIX this entry is found in the bp.conf file)

WARNING: If this entry is left in place when the cluster resource is failed over, it will cause backups to start failing, as the node this entry was placed on will no longer contain the interface that NetBackup is being required to use.

UNIX client name and Server lists

The server list for UNIX clients is configured within this file:


This is a text file that can easily be edited. No services have to be re-started, but any currently running backups may not pick up the new settings.

The same entries described above (in the Registry Entries Section) could be configured as follows in this example of a bp.conf file:


On UNIX, individual user accounts (such as Oracle) can have there own bp.conf file. This can be particularly helpful when using VIPs for RMAN backups to insure all communications go over a specific VIP and use the correct client name.

Cluster Requirements

Clustered servers have the exact same requirements listed above for each individual node; as if each node were to be backed up separately on it's own.
While full functionality can potentially be done without configuring each node separately, those types of configurations cannot be guaranteed to work under all situations (see note about "Required_Interface" above).

After the above configuration is done for each node, an additional virtualized cluster interface must be configured for backups as a cluster resource.
This cluster resource MUST be setup to follow the resources to be backed up as they are moved between nodes.

The clustered/virtualized backup NIC has the same connectivity, DNS, and naming requirements as the individual node configurations listed above.

Further configuration within NetBackup for "altnames" is also needed to allow clients to restore data backed up under their virtual client name (or to an alternate server).
Also see note about "Required_Interface" setting that can be used to circumvent the need for altnames if the required NIC is present.

Problem symptoms

Improper configurations can cause many problems including:

  1. Inability to communicate causing error 25 (socket read error).
  2. Server doesn't recognize the client as it is configured with in NetBackup resulting in access denied errors.
  3. Server tries to access the the client on an interface it cannot access due to a firewall.
  4. Client side functions may or may not work, with an error messages about a timeouts after initiating the restore or that access is denied.
  5. Also see Reasons why Client side restores might not work in NetBackup.

Back to NetBackup