Restoring a BMR client image to alternate hardware while the original server is online.

The Bare Metal Restore (BMR) architecture is intended to do Disaster Recovery (DR) of a downed system. It also recognizes the potential need to restore a production server image to new hardware while still maintaining the original server active on the network.  Some reasons would be the upgrade of a server to newer hardware or the migration to alternate hardware in the anticipation of a potential hardware failure of the currently running server.

The following instruction steps allow for this to occur.  They were originally written for Windows client restores and modified for Unix/Linux client restores.

 

1. On the NetBackup (NBU) Administration Console, create or make use of an editable restore configuration for the BMR restore process.
 

2. Make changes to the " Network Interfaces" section of the configuration and change the hardware MAC address to be the interface on the restoring hardware.  Change the IP-address to be one that is not in use on the network.  An address that is not on the same sub-net as the original server is optimal as it avoids potential host name conflicts in later processing. Do not use DHCP for this section. Please note that the host name portion of the BMR restore configuration can not be modified. For environments that have dynamic DNS updates, this method can cause a disruption of network access for Unix/Linux servers that make use of DNS to resolve to the running production server.
 

3. Make sufficient other changes in the restore configuration to handle the Dissimilar System Restore operations that will be performed.  For Windows clients, see related article 000088659 for details on how this is performed.  For Unix/Linux cleints see related article 000034868.
 

4. On the NBU Master Server and Media Server(as required), create a temporary hosts entry that allows the servers to do reverse lookup of the new IP-address to the host name of the original server.   This is required. Do not use DNS for this operation. For NetBackup releases that support it, run the command "bpclntcmd -clear_host_cache" in order to ensure that the proper IP address information gets used for the restore.  To verify this run the command "bpclntcmd -hn <client-host-name>" on both the Master Server and Media Server.  The response to the command needs to reflect the updated IP address. Errors with IP address resolution will cause RC=23 or RC=24 status codes at restore time.

 

5. If required, perform a Prepare To Restore operation for the restoring client image. One such reason would be to include any new device driver information into the Windows Fast Restore Shared Resource Tree (SRT). If this is the case, a new ISO image will also need to be created. For Unix Servers, a Prepare to Restore operation is mandatory.

6. Using normal BMR restore methods, restore the client as if restoring the original server.
 

During the BMR restore process, the restoring client, with the new IP-address, will be seen by the NBU Servers as if it were the original server.  The original server will not have NetBackup access during this time frame. NetBackup actions to or from the original server will not be possible.

Once the initial BMR processing has completed the restored client will reboot normally.

During the reboot, the restored client must not be allowed to attempt to join the network if the new IP-address used is on the same sub-net as the original server. The restored client will still have the same host name of the client that created the image and can cause network problems if allowed to attempt to enter the network improperly.  This is especially true of Windows client restores. The best method for this is to unplug the network cable from the server. If the client is on a different sub-net as the original server, this should not be required.

On Windows Client restores, the default first action of all BMR restores is to reset the configured network interfaces and to cleanup any temporary files and folders.  After the restore completes and the client reboots, the last action of the "bmrcleanup" process is to contact the NBU Master Server to update the process status of the restoring client. If the restored client is not on the network, this portion of the process will fail with RC=200.  This is not an error in BMR processing.  The state of the restore, as seen in the Tasks section of the Administration Console, will be set to Finalizing. This must be manually cleaned up. For further detailed information, see related article

 During Bare Metal Restore (BMR) Final Cleanup, the error message "Unable to update client state on the Netbackup server, error =200" is displayed.
 Article: 000039742
 Article URL: https://www.veritas.com/docs/000039742

For Unix Client, there are some First Boot actions that are run, similar to the activity performed on a Windows client. All actions are command line based and no GUI based actions are displayed.  A failure during this process will cause the boot to go to a shell prompt. When this occurs, exit from the shell and allow the server to reboot.  If this does not clear the problem, contact support for assistance.

Once BMR restore activity has completed, the restored client can be accessed as normal and any changes to its networking can be performed as the OS allows.


IMPORTANT : BMR was not designed or intended to be used as a provisioning/cloning tool.  The primary role of the BMR Feature is for Disaster Recovery of failed systems. The client name cannot be modified by BMR and the restored client will always reflect the original client name once the restore activity completes and the system reboots automatically.  The creation of exact system duplicates can be a violation of software licensing agreements in place for any given server. Also, any CPU based or locked licensing for restored applications must be accounted for after the BMR restore completes. BMR can not perform such activities.