Best Practices for configuring NetBackup for Exchange over a backup network

Problem

How to backup and restore NetBackup for Exchange – standalone or clustered – over a backup/secondary/private network between the media server and client host.

Solution

This configuration will allow for successful backup and restore of mailboxes, Information Store, public folders, and individual databases that are initiated from either the master server, or any other NetBackup administrative server, or a standalone Exchange host.

This configuration is compatible with Granular Recovery Technology (GRT) which will require connectivity to the Client Access Server (CAS).

Background Information

Most applications typically access a host over a public network and identify the host by its hostname on that network.   This is also true of NetBackup and the hostnames configured within NetBackup for Client Name, Policy Client, Server, Storage Unit Residence, etc are always the public hostnames.

If a backup network exists, it is advantageous to move the backup traffic off the public network and onto the backup network.   To affect that change, NetBackup is then configured to use the hostnames associated with the backup network interface (NIC) on each host; Client Name, Policy Client, Server, Storage Unit Residence, etc.

By configuring NetBackup consistently with hostnames that are on either the public or the backup network, the default forward/reverse name resolution and default network routing will allow communication over the expected networks.

This default configuration will work well for Exchange backup/restore over the public network.   However, this configuration will not allow backup/restore of Exchange across the backup network because the Exchange backup Application Programming Interface (API) requires that NetBackup utilize the Exchange public server name, as registered with Active Directory, to identify the client.   If NetBackup is configured with the Exchange public hostname, then by default the network will then create the TCP sockets across the public network and not the backup network.

Default NetBackup Configuration – For Review and Confirmation

This section details the items that comprise a default configuration of the network and NetBackup.   The sections that follow this one will provide modifications to these defaults that allow Exchange backup/restore via the backup network.

• Default name resolution should be in place.
• • All hostnames on the public network should resolve to the expected IP addresses on the public network and the same is true of the reverse.
  • All hostnames on the backup network should resolve to the expected IP addresses on the backup network and the same is true of the reverse.
     
• Default network routing should be occurring based on the IP addresses assigned to the local NICs and the IP addresses to which the remote hostnames resolve.
   
• The NetBackup Required Interface settings (Host Properties) should not be specified on the master server, mediaserver or client hosts.   Clustered master servers should also have Any Cluster Interface enabled so that Cluster Name does not act as a Required Interface.   (See below for additional details.   Also review 100003136, in the Related Articles section, if the master is at NetBackup 7.0.1.)
   
• The NetBackup Client Database, if present for the client hostnames, should have only the default Current Host and IP address.

Example:

If clustered, also check the nodes in the cluster.

• BPCD Connect Back should be defaulting to use the VNETD port so that all TCP sockets for the backup and restore operations originate from the server hosts.   If Random Port is selected instead, then some of the connections are initiated from the client to the servers and may not use the correct outbound NIC.   Check these configuration settings.
• • The global Default Connect Options configuration on the master and media server; Host Properties > server type > server > Firewall.
  • The per server connect options on the master and media server for each other; Host Properties > server type > local server > Firewall > remote server. Note that Firewall settings should only be present for master, media, and administrative server hosts, not for client hosts; especially not for the Exchange client, or the nodes if clustered.
  • The client connect options stored on the master server for the Exchange client or the nodes in the cluster; Host Properties > Master Server > server > Client Attributes > client > Connect Options tab.
     
• Since standard server and client initiated backups should already be occurring on the backup network, the client host(s) should already have Server entries for the backup interfaces of the master and media servers.

Example:

• The master server should not have any Server entries for the client hostnames.

Any non-default setting related to the items above indicate a unusual configuration and should not be necessary for normal NetBackup configuration and operation.   If present, review and correct to ensure that they do not conflict with the solution options detailed below.

A) Configure an Exchange Cluster Virtual Hostname on the Backup Network

If Exchange is clustered, it will have a virtual IP address on the public network that is assigned to the active node in the cluster.   A similar virtual IP address and associated hostname is needed for the backup network and should be assigned to the active node in the cluster.   This IP address and failover assignment must be created if it does not already exist.

B) Configure the Exchange Backup Policy to Use the Public Exchange Hostname

Because Exchange will not allow the use of a hostname on the backup network, NetBackup must be configured to use the public hostname for Exchange as the client for the backup policy; e.g. Exchange

Note: In a cluster, this will be the Exchange virtual public hostname.

C) If Needed, Update the Client used for Windows File System Backups

If all Windows policy backup and restore operations are server-directed, then the policies can continue to use either the hostname on the public network or the hostname on the backup network.   No change is necessary.

If user-direct backup or restore operations occur for Windows policies, then changes may be needed to avoiding conflict with step D.  

If the client host is currently configured with the public hostname and the Windows policies are already using the public hostname, then no change is necessary.

If the client host and Windows policies are currently configured for the hostname on the backup network, then three additional steps must be taken so that the file system backups begin utilizing the public hostname for the client. These steps must be taken when backups of the client host are not occurring.

1)      On the master server, change the client name in the Windows policies from the backup hostname to the public hostname.   Step F will associate this hostname with the IP address on the backup network so the backups will continue to use the backup network.

2)      On the master server, rename the db/images/<clientname> directory from the backup hostname to the public hostname.

3)      On the client host, change the Client Name from the backup hostname to the public hostname to match the policy.

Note: The next scheduled backup will be a full backup due to the change in client name.

Note: In a cluster, perform steps 1-3 for each node; e.g. Node1 and Node2.

D) Configure the Client to Use the Public Hostname

The Client Name on the Exchange host must also be associated with the public network; e.g. Exchange.

Note: In a cluster, the client name on each node should be the public hostname; e.g. Node1 or Node2.   It would be invalid for more than one host to use the same Exchange virtual name as its client name.

E) Configure the Client Host to Accept Connections From the Public Hostnames of the Servers

The client must be configured to accept connections from the server hostnames.   Add hostnames for the servers to the Servers List on the client.   The backup hostnames should have higher priority.

Example:

Use ‘bpclntcmd -hn <hostname>’ on the client host to ensure that all hostnames for the servers can be resolved to the expected IP addresses.

F) Configure the Public Hostnames to Use the Backup Network

There are two possible methods, the second is not applicable to all network configurations.

Hostname Resolution Modification Method

On the master and media servers, adjust the name resolution so that all connections to the public hostnames for the client resolve to IP address on the backup network.  

If the default name resolution (typically DNS) contains this configuration:

To utilize the backup network, add this hosts file entry to the master and media servers.   This entry must appear above/before any other entries so that the public hostname resolves to the backup IP address.   Also ensure that the servers are configured to resolve using hosts file entries before DNS or other resolution services:

Test the configuration to confirm the resolution is working as expected.   If this is NetBackup 7.0.1 or above, it may be necessary to flush the host cache on disk before running the bpclntcmd successfully and it may be an hour before persistent/daemon server processes pick up the change.

If Exchange is clustered, make similar changes to the hosts file on the master and media servers so that the public hostnames for the nodes in the cluster resolve to their backup IP addresses.   E.g.

On the Exchange client host, adjust the name resolution so that all connections from the servers appear to have originated from public hostnames even though the servers should be connecting to the backup interface on the client from the backup interfaces on the servers.

Example:

Use ‘bpclntcmd -ip <ip>’ on the client host to confirm that all IP addresses in use can be resolved to the expected hostnames.

Making these changes in the hosts files on the NetBackup hosts isolates this non-standard hostname to IP mapping from affecting applications on other hosts.   If this change was made in DNS, it would affect the Exchange users whose traffic should not be on the backup network.

Required Interface Method

This method has four considerations that make it impractical for most NetBackup domains.

1)      This configuration can only be used at sites where the media server and all clients are on the backup network.   Clients that are not on the backup network will not be able to communicate reliably with the master and media servers.

2)      The Required Interface may not force all NetBackup traffic onto the desired network segment.   This setting allows NetBackup to provide a hint to the operating system regarding which outbound interface to use for the connections to remote NetBackup hosts.   The operating system may ignore the hint and use the routing table instead.   If the hint is ignored, the backup image will traverse the backup network, but meta data and the restore images from the mediaserver to the client will traverse the public network.

3)      If the hint is ignored then the inbound connection will arrive on the public network but have a source IP associated with the backup network.   This may conflict with the weak host model setting on Windows 2008 or Windows 2003 client hosts.   See 100019161 in the Related Articles section for more details.

4)      This can have an adverse affect on client/user-directed operations.   See the related section below for additional details.

If the considerations above are not of concern, proceed as follows.

On the media server, set the Required Interface to the hostname that resolves to the IP address assigned to the backup NIC.   All outbound connections to the client and other server hosts will have that source IP address so those hosts will return packets to that NIC.

On UNIX media servers, add the appropriate entry to the netbackup/bp.conf file.

Example:

On Windows media servers, add the appropriate entry to the registry.

• Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\VERITAS\NetBackup\CurrentVersion\Config
• Add a key of type " String " called " REQUIRED_INTERFACE ".
• Set the value to the backup hostname of the media server, e.g. MM-bk

If the master server needs to communicate with the client host for file system backups (i.e. ALL_LOCAL_DRIVES, etc), a small amount of information will be exchanged on the public network.   If this is a concern and if the master server can communicate to all other media servers and all other client hosts via the backup network, then a similar configuration can be put in place on the master server.

Example:

See the Client/User-Directed section below for details about setting Required Interface on the client host.

What if the Master Server is Only on the Public Network?

The configurations above will still work as described with respect to transfer of the backup image or restore image between the mediaserver and client host.

Depending on the type of operation, there may be a small amount of meta data exchanged between the master server and the client host.   Depending on the network configuration, two scenarios are possible.

If a route exists between the public and backup networks

Connections from the master to the client will flow through the router to reach the backup interface on the client.   Because the connection originates from the public (only) IP address of the master server, returned packets may be on the public network.

If a route does not exist between the public and backup networks

Communication between the master server and client must be over the public network, but the amount of information exchanged is minimal so the impact is minor.   Two exceptions must be made to the configuration detailed above.

1)      On the master server, the hosts file must not be modified to resolve the Exchange and node public names to IP addresses on the backup network.   The previously existing public hostname to public IP address mapping is sufficient.    The media server should still map the public hostname of the client to the backup IP address.

2)      On the client host, the hosts file will not need to be modified with respect to the master server.   The previously existing public hostname to public IP address mapping is sufficient.

Note: Setting Required Interface on the master server has no purpose if only the public interface is present.

Note: Setting Required Interface on the client host to the backup hostname will prevent user-directed flat file backup and restore requests from reaching the master server unless the client operating system does not takes the hint to use the backup interface.

What Effect Does This Have on User/Client-Directed Restore?

Windows Restore

The Hostname Resolution method is compatible with user-directed operations.   Those operations will use the backup hostname for the master server per the first Server entry, resolve hostname to the backup IP of the master server, and should connect outbound from the backup interface on the client per default routing.   The master server host will resolve the inbound source IP to the public hostname of the client which will match the Client Name in the request and authenticate successfully.

If Required Interface is configured on the client host, that value becomes the Requesting Client.   If the Requesting Client does not match the Destination Client, the master server will reject the restore request unless there is a Server entry for the Requesting Client.   Only Servers are allowed to initiate restores to a destination client other than the requesting client.   See 100005572, in the Related Articles section, for additional details.

Standalone Exchange Restore

These should operate the same as Windows Restore.

Clustered Exchange Restore

In a clustered environment, the backup images will be stored under the Exchange public hostname within the NetBackup image database.   Because the Exchange hostname is not the same as the Client Name of the node, NetBackup consider these to be redirected restores.   These images can be restored when initiated from the master server, media server, or other administrative console as detailed in the NetBackup for Exchange Administration Guide.

A client-initiated restore from a node in the cluster is not supported!   If operational needs require client-initiated restore, then NetBackup must be configured to treat the requesting node as a valid NetBackup server.

1)      By default, the Destination Client field is disabled in the Backup, Archive, and Restore (BAR) GUI and cannot be changed to the Exchange public hostname.   To enable the field, add a Server entry for the local Client Name to each node in the cluster.

2)      Then set the Destination Client to the Exchange public name to match Active Directory.

3)      Add a Server entry on the master server for each node in the cluster.   Be aware that this will give full NetBackup administrative privileges to the nodes.

4)      Configure the NetBackup Altnames directory on the master to allow the requesting client to browse the Exchange images.

Example:

...OR...

5)      See the Related Articles section for additional details, especially if Required Interface is configured on the client host.

Additional Opportunity for Improving Cluster Performance

The backup does not depend on the binding order of the network interface cards (NICs) on the nodes. However, if the backup NICs have higher precedence than the public NICs, the Exchange MAPI Server Transport messages will be placed onto the backup network which may improve the Exchange user experience if the public network is heavily congested.

Applies To

Exchange 2003/2007/2010 Standalone,

Exchange 2003 Cluster and Exchange 2007 Single Copy Cluster (SCC)

                on either VERITAS Cluster Server or Microsoft Cluster Server

Exchange 2007 Cluster Continuous Replication (CCR),

Exchange 2010 Database Availability Group (DAG) servers.