cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
Veritas.com
Support

BMR Prepare to Restore initiation twice is mandatory?

Go to solution
Sowjanya
Level 4

‎05-12-2015 06:38 AM

Hi,

Can you please let us know the "Prepare to restore" dependency on BMR cleanup. In our environment we are observing two different
behaviours. Some times BMR cleanup is working without initiating "Prepare to restore" any clues on this.

NBU Server : 7.6.0.4 ( Solaris )
NBU Client : 7.6.0.4 Windows 2008 Enterprise.

The Prepare to Restore is being initiated once after the SRT alone is created . And after cancelling this task ,we need to initiate a prepare to restore again after DVD based SRT is creation . This is the recommended procedure and is working fine.This is working for both BIS and WAS server.

But when initiated prepare to restore only once,the BMR cleanup is not being done for WAS automatically ,while it is being done automatically in BIS server.

Any clues on this please?

Regards

Sowjanya

0 Kudos
1 ACCEPTED SOLUTION

Accepted Solutions

Go to solution
Jaime_Vazquez
Level 6
Employee

‎05-12-2015 09:33 AM

There is no need to do a PTR of a newly created SRT. Why are you doing this at your location?

The Prepare to Restore is being initiated once after the SRT alone is created . And after cancelling this task ,we need to initiate a prepare to restore again after DVD based SRT is creation . This is the recommended procedure and is working fine.This is working for both BIS and WAS server.

How did this becomes the "recommended" procedure at your location? It is not any procedure that I would have recommended to any customer. What client is being specified for the PTR?

However, to focus on your specific question:  A Prepare To Restore has NO effect on the post-restore first boot bmrcleanup activity initiation.  The setup of the bmrcleanup that is run at first boot, is completely a function of the restore script used for Unix/Linux clients or the 'bmrrst.exe' program for Windows clients. If you review the "bmrrst" debug log on the Master Server for the client recovery, you can see debug output information that shows the setup being performed there. For Windows clients, the cleanup code is placed in the folder "C:\Windows\temp\BMR1" and a registry key is added to the client registry to execute the cleanup on first boot.  Part of the cleanup function is to delete this key and to delete the temporary work folder of "C:\BMR" which was used during the recovery.  For Solaris it is placed in a sub-directory of "init.d" for execution at boot time.  It is also deleted as part of its work. Again, you can view all of the setup in the debug log.

A Prepare To Restore (PTR) is required ahead of the recovery of any Unix/Linux client. The process does not affect the SRT itself. If the SRT is a NFS version, all of the needed steps for the recovery of a client over a network are performed both on the Master and the Boot Server.  If using a media (ISO/CD/DVD) based SRT, all of the actions occur on the Master and all needed files are placed in the BMRDB.  The Boot Server is never contacted and is not a requirement for a recovery. The media becomes the boot server for the recovery.

For recovery of a Windows client a PTR is only required under three circumstances:

1.  The restore is over a network using the NFS based SRT.  The Boot Server needs to perform the PXE boot setup locally and export the SRT file system to the client.

2. You need to make use of non-default options available for the recovery like  "restore Systems/Disks volumes only" or use of any external procedures. This is available for both network and media SRT boots.

3.  If the SRT in use needs to have new device driver support added for new hardware introduced to the environment. The insertion process only occurs when a network based SRT is specified on the PTR panel. During processing, BMR will check the client configuration and insert any needed device drivers into the SRT. This is shown in better detail with this article:

Windows Device Driver Requirements for Bare Metal Restore (BMR) 
http://www.symantec.com/docs/TECH181674

Device driver support can also be done manually. See this article on how to insert them:

How to update a BMR Windows Shared Resource Tree (SRT) on BMR 7.X Boot Servers
http://www.symantec.com/docs/TECH160457

Once a network based SRT has been modified for additional device driver support, a new media based SRT based on it is required.  BMR has no functions that internally modify an existing ISO image SRT. All SRT instances for BMR are generic.  Client specific information is not kept inside of the SRT (with one minor exception for Windows clients - not germane to this discussion).  At BMR recovery time, the only thing copied from the SRT to the client is the cleanup code to be executed on first reboot. For Windows DSR recoveries, any new device drivers installation makes use of files downloaded from the BMRDB on the Master, not from the SRT. Windows device drivers in the SRT are for use by the WinPE environment used by BMR for recovery. On reboot, the initial login to the restored client needs to have local administrator or root authority login in order for this to happen. Domain login credentials will not work. It must be local id credentials.

Because a BMR SRT is generic in nature multiple SRT versions are NOT required for any given OS release.

For Windows clients you need, at most, four SRT entries. You need two network based SRT: one for 32 bit backup images, one for 64 bit backup images. You can create media boot (ISO) based versions of them. Any Windows SRT will recover any client Windows OS versions of the same hardware architecture supported by BMR.  Almost any Windows Boot Server (32 or 64 bit)  can be used to create an SRT (32 or 64 bit).  See the NBU OSCL for supported client OS releases.

For Unix/Linux clients, depending on the OS version being supported, you only need the network (NFS based) and media (ISO/CD/DVD) based SRT. For Solaris environments, one SRT version  can support recovery of different OS update release versions. As an example,for Solaris 10 update 6 and higher clients, any SRT created using Solaris 10  Update 6 and higher install media can be used for the PTR and client recovery. Disregard any informational messages about the OS level mismatch.. The version used can be higher (recommended) or lower than the version of the backed up client. The installed OS version of the Boot Server should be as high or higher than any supported clients.  The OS version of the Boot Server (Unix/Linux only) is the default highest OS version of SRT that it can create. As an example, a Solaris 10 Update 11 Boot Server cannot create Solaris 11 SRT versions.  A Solaris 11 Boot Server can create Solaris 11 and  Solaris 10 SRT at any release level.   Although the following  article is a bit old (and in need of some updating by me)  you can get a general sense of this information:

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

 

The PTR is always initiated on the Master..It can be via Administration console or via command line.  The command line program is "bmrprep". Use "bmrprep -?" to get command syntax, if needed.

Again, I must emphasize that Prepare To Restore actions have no impact on the creation and initiation of the 'bmrcleanup' process on the recovered client.  It should always be initiated on first reboot.  What is the state of the recovered client after a BMR recovery and reboot?

 

View solution in original post

0 Kudos
2 REPLIES 2

Go to solution
Jaime_Vazquez
Level 6
Employee

‎05-12-2015 09:33 AM

There is no need to do a PTR of a newly created SRT. Why are you doing this at your location?

The Prepare to Restore is being initiated once after the SRT alone is created . And after cancelling this task ,we need to initiate a prepare to restore again after DVD based SRT is creation . This is the recommended procedure and is working fine.This is working for both BIS and WAS server.

How did this becomes the "recommended" procedure at your location? It is not any procedure that I would have recommended to any customer. What client is being specified for the PTR?

However, to focus on your specific question:  A Prepare To Restore has NO effect on the post-restore first boot bmrcleanup activity initiation.  The setup of the bmrcleanup that is run at first boot, is completely a function of the restore script used for Unix/Linux clients or the 'bmrrst.exe' program for Windows clients. If you review the "bmrrst" debug log on the Master Server for the client recovery, you can see debug output information that shows the setup being performed there. For Windows clients, the cleanup code is placed in the folder "C:\Windows\temp\BMR1" and a registry key is added to the client registry to execute the cleanup on first boot.  Part of the cleanup function is to delete this key and to delete the temporary work folder of "C:\BMR" which was used during the recovery.  For Solaris it is placed in a sub-directory of "init.d" for execution at boot time.  It is also deleted as part of its work. Again, you can view all of the setup in the debug log.

A Prepare To Restore (PTR) is required ahead of the recovery of any Unix/Linux client. The process does not affect the SRT itself. If the SRT is a NFS version, all of the needed steps for the recovery of a client over a network are performed both on the Master and the Boot Server.  If using a media (ISO/CD/DVD) based SRT, all of the actions occur on the Master and all needed files are placed in the BMRDB.  The Boot Server is never contacted and is not a requirement for a recovery. The media becomes the boot server for the recovery.

For recovery of a Windows client a PTR is only required under three circumstances:

1.  The restore is over a network using the NFS based SRT.  The Boot Server needs to perform the PXE boot setup locally and export the SRT file system to the client.

2. You need to make use of non-default options available for the recovery like  "restore Systems/Disks volumes only" or use of any external procedures. This is available for both network and media SRT boots.

3.  If the SRT in use needs to have new device driver support added for new hardware introduced to the environment. The insertion process only occurs when a network based SRT is specified on the PTR panel. During processing, BMR will check the client configuration and insert any needed device drivers into the SRT. This is shown in better detail with this article:

Windows Device Driver Requirements for Bare Metal Restore (BMR) 
http://www.symantec.com/docs/TECH181674

Device driver support can also be done manually. See this article on how to insert them:

How to update a BMR Windows Shared Resource Tree (SRT) on BMR 7.X Boot Servers
http://www.symantec.com/docs/TECH160457

Once a network based SRT has been modified for additional device driver support, a new media based SRT based on it is required.  BMR has no functions that internally modify an existing ISO image SRT. All SRT instances for BMR are generic.  Client specific information is not kept inside of the SRT (with one minor exception for Windows clients - not germane to this discussion).  At BMR recovery time, the only thing copied from the SRT to the client is the cleanup code to be executed on first reboot. For Windows DSR recoveries, any new device drivers installation makes use of files downloaded from the BMRDB on the Master, not from the SRT. Windows device drivers in the SRT are for use by the WinPE environment used by BMR for recovery. On reboot, the initial login to the restored client needs to have local administrator or root authority login in order for this to happen. Domain login credentials will not work. It must be local id credentials.

Because a BMR SRT is generic in nature multiple SRT versions are NOT required for any given OS release.

For Windows clients you need, at most, four SRT entries. You need two network based SRT: one for 32 bit backup images, one for 64 bit backup images. You can create media boot (ISO) based versions of them. Any Windows SRT will recover any client Windows OS versions of the same hardware architecture supported by BMR.  Almost any Windows Boot Server (32 or 64 bit)  can be used to create an SRT (32 or 64 bit).  See the NBU OSCL for supported client OS releases.

For Unix/Linux clients, depending on the OS version being supported, you only need the network (NFS based) and media (ISO/CD/DVD) based SRT. For Solaris environments, one SRT version  can support recovery of different OS update release versions. As an example,for Solaris 10 update 6 and higher clients, any SRT created using Solaris 10  Update 6 and higher install media can be used for the PTR and client recovery. Disregard any informational messages about the OS level mismatch.. The version used can be higher (recommended) or lower than the version of the backed up client. The installed OS version of the Boot Server should be as high or higher than any supported clients.  The OS version of the Boot Server (Unix/Linux only) is the default highest OS version of SRT that it can create. As an example, a Solaris 10 Update 11 Boot Server cannot create Solaris 11 SRT versions.  A Solaris 11 Boot Server can create Solaris 11 and  Solaris 10 SRT at any release level.   Although the following  article is a bit old (and in need of some updating by me)  you can get a general sense of this information:

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

 

The PTR is always initiated on the Master..It can be via Administration console or via command line.  The command line program is "bmrprep". Use "bmrprep -?" to get command syntax, if needed.

Again, I must emphasize that Prepare To Restore actions have no impact on the creation and initiation of the 'bmrcleanup' process on the recovered client.  It should always be initiated on first reboot.  What is the state of the recovered client after a BMR recovery and reboot?

 

0 Kudos

Go to solution
Sowjanya
Level 4

‎05-12-2015 11:49 PM

Hi Jaime,

    Thanks for the response!!! Windows client is being specified for the PTR.

As conveyed by you "For recovery of a Windows client a PTR is only required under three circumstances"

We are using the second circumstance which is mentioned

2. You need to make use of non-default options available for the recovery like  "restore Systems/Disks volumes only" or use of any external procedures. This is available for both network and media SRT boots.

And also sometimes the third scenario for WinPE drivers issue

3.  If the SRT in use needs to have new device driver support added for new hardware introduced to the environment. The insertion process only occurs when a network based SRT is specified on the PTR panel. During processing, BMR will check the client configuration and insert any needed device drivers into the SRT

 The PTR is initialised on the Master server only through the Netbackup GUI

 The recovered client state is healthy and proper after the recovery and reboot.So we would like to know ,what could be the possible reason for the cleanup not being done automatically for WAS server?

 

Regards

Sowjanya

0 Kudos