cancel
Showing results for 
Search instead for 
Did you mean: 

Linux BMR: Can you use only one Boot Server for many subnets/VLANs?

Jim-90
Level 6

Can the creation of a RHE client iso images be done from a single RHE Linux BMR Boots Server if the other steps in creating a NBU 7.6 BMR solution are done correctly?  Recovery across the IP network is not required and all recoveries will be done via iso images. 
 

We have many VLANs and not able to put Boot Servers on every network segment.  Plus according to TECH161483 network recovery has the potential of interfering with the existing KickStart and Boot Relay servers.  With these limitations it appears that recovery via iso images is the way to go and looks simpler.

Creating iso images of the bootable SRT image seems to unique for each client restore - true?     
 

Methodology used for the network boot processing of a Linux Bare Metal Restore (BMR) client.
http://www.symantec.com/docs/TECH161483

1 ACCEPTED SOLUTION

Accepted Solutions

Jaime_Vazquez
Level 6
Employee

When restoring a client using a Media SRT, the media SRT itself becomes the Boot Server for the entire recovery process. The Boot Server that created it and hosts it is not contacted nor is it any part of the restore process. As such the client can be on any network segment that can contact the Master Server.

AIX client systems, using the SMS menu on the client, can network boot across sub nets. It is the only supported OS capable of this.

Ensure that when you do the "Prepare To Restore" a Media SRT is specified for the operation. And, as with the actual restore, the Boot Server is not part of this as well. All client specific restore files will be created and inserted into the BMRDB on the Master Server for use during the actual restore.

All media boot SRT restores will query the user for networking interface information to set it up on the network. The data will be client name, client IP address, sub net mask and default gateway. It will also ask for Master Server name and IP address. Windows client restores will only ask for the Master Server IP address. Because this is a full set of interface information, the client can route through gateways to contact the Master Server.

All BMR SRT images (network or media boot) are generic and do not contain client specific information. Well, actually, for Windows SRT client restores there is a small hidden file but that is for the "Automated Restore:" process. The hidden file is preloaded with client interface information that would otherwise be asked for at boot time. Let's not complicate this response by trying to explain all of that. Let's move on.

As the SRT is generic, it can be used to restore all BMR clients of the same OS type and major version level. A Windows SRT can restore any Windows client OS versions that BMR restores.  The architecture (32 versus 64 bit) must match the client.  Maintenance/kernel levels should be an exact match or as close there of to the maintenance/kernel version of the client'skup image.  Some examples:

RHEL 6.# clients should use a matching RHEL 6.# SRT.  

AIX SRT requirements are significantly stricter. A valid match down to the TL/ML level is required. An AIX 7.1 TL1 SRT should not be used to restore an AIX 7.1 TL3 client and vice versa.

Solaris, on the other hand, is much looser.  Solaris 10 Update 6 and higher SRT can restore any client that is Solaris 10 Update 6 or higher.  Solaris 11 clients require a Solaris 11 SRT.

So, to completely answer your questions:

When doing media boot a single boot server of proper OS can be used to create the media SRT which in turn can be used restore any configured and backed up BMR client, regardless of network segment.

Except for AIX clients, network boots require a boot server on the same network segment. That is pretty much what the native network boot methodology requires for each OS.

All ISO images (network or media) are totally generic. As part of the BMR recovery process, client specific information is pulled down from the Master Server.  

The SRT boot image operates from a RAMDISK and not from the local disk. The SRT support files are either NFS mounted from the Boot Server for network boots or CDFS mounted from the media.

Except for some small set of temporary files created and used by BMR, nothing is copied from the SRT to the recovered client. Those files are removed/deleted from the recovered client using a 'bmrcleanup' program or script initiated on the client as part of the first boot. 

The following article I wrote explains much of what I stated above.

Requirements for Bare Metal Restore (BMR) Boot Servers 
http://www.symantec.com/docs/TECH87607

I am going to have to take a peek at TECH161483 to make sure it is accurate. 

I hope this was helpful.

View solution in original post

7 REPLIES 7

Mark_Solutions
Level 6
Partner Accredited Certified
The ISO image is just a boot CD that loads the environment for the BMR recovery The client will still need to be able to access the Master and Media Servers for the restore themselves to actually take place - BMR is not an imaging solution Hope this helps

Nicolai
Moderator
Moderator
Partner    VIP   

There are limitation regarding different Red Hat versions - but assuming the boot server and server doing BMR roughly the same one boot server should be enough.E.g:  You can't create ISO images for SUSE on a Red Hat.

  • Create the ISO image
  • Move it to the down server
  • Mount it as a virtual CD Drive
  • Boot the server off the ISO image

 

Jim-90
Level 6

According to the manual :

  • Recovery is a two stage process. The first phase is not routable  
  • The iso image is only a minimal bootable image once installed on the target system and used to recover the rest of the system from NBU.
  • Use iso images where recovery is to a different subnet/VLAN or use a Boot Relay server.  

 What I need to know:

Is single Boot Server is sufficient for all the clients BMR backups on different network segments?

This is not mentioned in any technote or the manual.  From what I see the issue of the Linux client having to be on the same subnet only becomes important at recovery time where the first phase of the recovery doesn't rely upon a machine with a routable IP address.

Is the minimal bootable iso image unique to each client?

I suspect it is because when the machine is booted up it has the minimal configuration for NBU to do a regular recovery that is network routed.    If network routable then it has to contain the information that identifies as being the client of the BMR restoration.

This Symantec video NetBackup BMR Network based recovery prerequisites and configuration https://www-secure.symantec.com/connect/videos/netbackup-bmr-network-based-recovery-prerequisites-and-configuration is good for network recovery but the presentation of the last slide hints at KickStart & Relay server conflicts and says that you can do network recovery to other subnets/VLANs but doesn't mention how.  This alos probably messes with existing relay server.  

Jaime_Vazquez
Level 6
Employee

When restoring a client using a Media SRT, the media SRT itself becomes the Boot Server for the entire recovery process. The Boot Server that created it and hosts it is not contacted nor is it any part of the restore process. As such the client can be on any network segment that can contact the Master Server.

AIX client systems, using the SMS menu on the client, can network boot across sub nets. It is the only supported OS capable of this.

Ensure that when you do the "Prepare To Restore" a Media SRT is specified for the operation. And, as with the actual restore, the Boot Server is not part of this as well. All client specific restore files will be created and inserted into the BMRDB on the Master Server for use during the actual restore.

All media boot SRT restores will query the user for networking interface information to set it up on the network. The data will be client name, client IP address, sub net mask and default gateway. It will also ask for Master Server name and IP address. Windows client restores will only ask for the Master Server IP address. Because this is a full set of interface information, the client can route through gateways to contact the Master Server.

All BMR SRT images (network or media boot) are generic and do not contain client specific information. Well, actually, for Windows SRT client restores there is a small hidden file but that is for the "Automated Restore:" process. The hidden file is preloaded with client interface information that would otherwise be asked for at boot time. Let's not complicate this response by trying to explain all of that. Let's move on.

As the SRT is generic, it can be used to restore all BMR clients of the same OS type and major version level. A Windows SRT can restore any Windows client OS versions that BMR restores.  The architecture (32 versus 64 bit) must match the client.  Maintenance/kernel levels should be an exact match or as close there of to the maintenance/kernel version of the client'skup image.  Some examples:

RHEL 6.# clients should use a matching RHEL 6.# SRT.  

AIX SRT requirements are significantly stricter. A valid match down to the TL/ML level is required. An AIX 7.1 TL1 SRT should not be used to restore an AIX 7.1 TL3 client and vice versa.

Solaris, on the other hand, is much looser.  Solaris 10 Update 6 and higher SRT can restore any client that is Solaris 10 Update 6 or higher.  Solaris 11 clients require a Solaris 11 SRT.

So, to completely answer your questions:

When doing media boot a single boot server of proper OS can be used to create the media SRT which in turn can be used restore any configured and backed up BMR client, regardless of network segment.

Except for AIX clients, network boots require a boot server on the same network segment. That is pretty much what the native network boot methodology requires for each OS.

All ISO images (network or media) are totally generic. As part of the BMR recovery process, client specific information is pulled down from the Master Server.  

The SRT boot image operates from a RAMDISK and not from the local disk. The SRT support files are either NFS mounted from the Boot Server for network boots or CDFS mounted from the media.

Except for some small set of temporary files created and used by BMR, nothing is copied from the SRT to the recovered client. Those files are removed/deleted from the recovered client using a 'bmrcleanup' program or script initiated on the client as part of the first boot. 

The following article I wrote explains much of what I stated above.

Requirements for Bare Metal Restore (BMR) Boot Servers 
http://www.symantec.com/docs/TECH87607

I am going to have to take a peek at TECH161483 to make sure it is accurate. 

I hope this was helpful.

Jim-90
Level 6

Thanks for that it makes sense,  I needed confirmation of what is happening under the hood.  I have played with the proprietry BMR solutions of Solaris Jumpstart, HP-UX Ignite and NIM (AIX) in a previous life.  Unfortunately Linux seems to rely upon third party solutions for BMR.  

Using iso images seems to be a lot simpler when you can suck them into the box via ILO or its VMware console. I'll test it the coming weeks 

Jim-90
Level 6

Thanks for that, it makes sense, I have worked with most proprietary Unix BMR solutions, Linux has to rely upon third party solutions.


Using iso images do not appear that difficult when you can suck them into box via ILO or VMware consoles.  I'll test it in coming weeks and post results

Jaime_Vazquez
Level 6
Employee

My last post is probably the largst I have entered in this community.

The NBU/BMR solution works very well, be it network or media boot. All Unix/Linux boot images in the SRT come from the OEM vendor's own install media and we strictly emulate the natie boot mthods of each OS. Windows of course is a bit different as we use a WinPE image as the base running kernel..

If doing a restore to a guest instance on a VMWare server, this technical article will be of help.  It covers Windows and Linux.

Performing Physical to Virtual (P2V) restores using BMR
http://www.symantec.com/docs/TECH211500 

I would caution that using ILO to be the transport mechanism of the ISO image is rather slow. I mean, slooooow. This is especially true if the source CD/DVD drive is a physical drive. On the other hand, loading the ISO image to a VMware datastore and making use of a virtual CD-ROM drive is wicked fast. Be it Windows or Linux, it is by far the best way to go.

I would think you are good to go now.