Requirements for Bare Metal Restore (BMR) Boot Servers

Problem

Requirements for Bare Metal Restore (BMR) Boot Servers

Solution

 For Bare Metal restore (BMR) Boot Servers the following are the requirements:
 
1.   The Boot Server services are considered client services.

As such a BMR Boot Server does not have to reside on a Master Server.

Any NBU client can be a registered BMR Boot Server.

The Master and Boot Server can reside on the same server without issue.

The Boot Server must be of the same OS as the clients that are being recovered. 

A Windows OS based Boot Server of any supported platform can support recovery of all BMR supported Windows based clients.

A Solaris X86 Boot Server only supports Solaris X86 clients.  It does not support SPARC hardware systems and vice-versa. 

2.    You can have multiple Boot Servers of the same OS registered to the Master Server.

You can have multiple Boot Servers of any supported OS registered to the Master Server. 

It is recommended, but not required, to have a single Boot Server of any given OS variant per subnet. 
 
3.    For Unix/Linux, the Boot Server OS release/maintenance level must be as high or higher than the clients being supported. For Windows Boot Servers, any supported Windows OS (32 or 64 bit) can be a Boot Server and can create an SRT to restore any supported client regardless of the OS level or hardware architecture.

Examples are:

Solaris 11 Boot Server can do ONLY Solaris 11.  Back-level SRTs (versions lower than Solaris 11) from Solaris 11 boot server is not supported. 
Solaris 10 Boot serves can do Solaris 10 and 9 clients.
A Solaris 11 (SPARC) Boot Server can support all currently supported versions of Solaris clients (Sparc hardware only). 
Red Hat version 6.X Boot Servers can restore RH 6.X and 5.X clients.
The Red Hat update level must be as high or higher than the clients it supports and the SRT versions it can create. A RHEL 6.3 Boot Server cannot create RHEL 6.4 SRT images.
Suse Linux Version 11 supports restoring Version 10 and supported lower versions clients. SRT creation rules are the same. The update (MP) level restrictions also apply.

4.  All Linux/Unix Boot Servers can create an SRT at it's OS release/maintenance (kernel) version or lower.

A RHEL 6.X server can create a RHEL 6.X SRT and lower, such as RHEL 5.X. The lone exception is Solaris, where a Solaris 10 server at any update level can create an SRT at any Solaris 10 update level.

Special consideration is required for clients at Solaris 10 Update 6 or higher. See related article 329993 for further information.

The major release version of an SRT must match the major release version of the client image. The maintenance release should be as high or higher than the maintenance release of the client image. 

A RHEL 6.X SRT cannot be used to restore a RHEL 5.X client image. A RHEL 6.4 SRT can be used to restore a RHEL 6.2 client, but a RHEL 6.2 SRT should not be used to restore a RHEL 6.4 client image.
 
5.  Netbackup 7.0.1 introduced the support for Windows 2008/2008 R2 Boot servers and clients. 

Support exists for both 32 and 64 bit Windows 2008/2008R2 clients.  On Netbackup 7.0.1, a Windows 2003 Boot Server (both 32 and 64 bit) supports restoration of all supported Windows client versions (Windows XP, 2003, Vista, Windows 7, Windows 2008 / 2008 R2). The Windows WinPE SRT images are generic and will work with ANY version of supported Windows clients. The SRT used for client restores must match the architecture (32 or 64 bit) of the client backup image. A 32 bit SRT must be used to restore a 32 bit Windows OS backup image and a 64 bit SRT must be used for 64 bit images. 

Support for Windows 2000 is dropped in Netbackup 7.0.  A Windows 2000 client needs to remain at release 6.5.X and will require a 6.5.X Boot Server in order to be restored using BMR. They must be recovered using a 6.5.X SRT.
   
6.  Not all OEM vendor released maintenance levels are supported by BMR.  See the OS Compatibility List, 000040842, for a listing of clients that can be BMR Boot Servers and clients. In the "NetBackup Client" sections of each OS, look under the specific column "BMR Client/Boot Server" for supported releases. 
 
7.  Boot Server should be updated to the same NBU patch level as the Master Server.

It can not be at a patch level higher than what the BMRDB is initialized to.

The Boot Server must be at the same NBU patch level or higher than the clients it supports. 

From NBU 7.X, Boot Server software is installed with client software installs. As such, any patch updates will automatically update both the client and Boot Server software.
 
8.  AIX network booting is the only OS that can cross subnets.  All other OS variants supported by BMR require a Boot Server in the subnet of the client in order to do network boot. If one is not available, the use of BMR Bootable Media is required. BMR network boot processing emulates the native network boot protocols of the OS itself. 
 
9.  You must have a BMR Boot Server to create BMR bootable restore media. 

The ISO image created is always based on an existing NFS (unix) or Network (windows)  based SRT which must be created first.

However, when using a media SRT for BMR recoveries, a Boot Server is not required and is not part of the restore process.

To make use of the boot media, the BMR process Prepare To Restore must specify the CDFS based Shared Resource Tree (SRT) in order to have the correct restore files created in the BMR database (BMRDB). Failure to do so will cause restore time errors.
 
10. Boot Server software is automatically installed with client software installs.  The software is updated along with client software updates. Boot Servers register to the Master Server using "bmrsetupboot -register".  The Boot Server name will always be the NBU client name. The BMR Master Server will always be the NBU Master Server for that client. A Boot Server can be removed by running "bmrsetupboot -deregister" from the server command line or by using the 'delete' option of the Administration Console.

In some rare instances, the NBU version of the Boot Server will not be accurately reflected in the BMRDB.  To refresh this, simply run the same 'bmrsetup' boot command used to initially register the client.  This will only update the key value in the BMRDB and has no other side-effects. If this fails to properly update on the Master Server, please contact Veritas NetBackup Support for assistance.

A complete output of registered Boot Servers can be displayed by running, on the Master Server, either of these commands:

          #  bmrs -o list -res BootServer

          #  bmrs -o query -res database -table BootServer
 
Boot Servers can be displayed on the Administration Console under the BMR Management node "Hosts -> Boot Servers".
 

Applies To

All supported versions of BMR on all supported Operating system releases.