06-06-2014 06:48 AM
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
Solved! Go to Solution.
06-06-2014 02:38 PM
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.
06-06-2014 07:41 AM
06-06-2014 08:23 AM
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.
06-06-2014 02:22 PM
According to the manual :
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.
06-06-2014 02:38 PM
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.
06-06-2014 06:09 PM
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
06-06-2014 06:55 PM
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
06-06-2014 09:12 PM
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.