cancel
Showing results for 
Search instead for 
Did you mean: 

BMR not support on Windows 2012 with SFHAW

pgm10s
Level 5
Partner Accredited Certified

I have check the compatibility list. I wonder why Windows 2012 with SFW installed is not support BMR backup.

How can we protect the system disk of  VCS nodes.

1 ACCEPTED SOLUTION

Accepted Solutions

Jaime_Vazquez
Level 6
Employee

My apologies, as I failed to do spell checks on the entry. Here it is, spelling checked.

BMR integration with SFW has always been a problem. The only SRT build that would work was the "Legacy SRT" process, itself a much longer and distinctly complicated restore process.

Most clients making use of SFW have it to manage non-local drives/file systems.  Those tend to be backed up by a separate policy and not part of the backup of the OS image itself. So the reality is that BMR is not in play for those data disks but BMR, by default, see all of the attached drives and tries to work with them in a general overall manner.

That being the case, there is a small easy work around for this that allows for recovery of such clients a the OS drive level. The mechanism is show in this article:

http://www.symantec.com/docs/HOWTO88823

When SFW software is installed, the OS drive, although not directly managed by SFW, has its volume manager key set to SFW for the entire system. The OS drive is not modified and works quite well using the normal Windows LDM service.  The registry key entry that is described "tells" BMR to work against only the non-SFW drives and do so as if they were normal LDM drives. The SFW drives are recognized as such by the bmrsavecfg process and are tagged as such and marked as "Restricted" by BMR.  As such, they are not seen or manipulated in any manner during the recovery process.  And, as the BMR configuration file has been set up as normal LDM drives, normal 'bmrrst.exe' processing occurs at restore time. There is a special tag in the configuration file that has BMR keep the normal SFW software key in the restored registry.  It also keeps the drive path  definitions of the data drives in there as well.  On reboot, this information has the client re-attach to them as a normal process.  This is equivalent to dong a "Prepare To Restore" and choosing the options "System Disk/Volumes only" and "make available non-restored volumes on non-restored disks after reboot". Basically do not remove any non-restored volumes from the 'fstab' file (or its equivalent).

Now, as I see that this is a VCS cluster situation, I want to add some additional information. A little extra credit you might say.  BMR is "cluster aware" of MSCS and VCS cluster for 'bmrsavecfg' purposes. It captures both the client's cluster identity and it's physical non-cluster identity (what it would look like of cluster services were disabled). BMR will restrict any resource on the  client that is shared by the cluster. During recovery, it will only recover all local (non-shared) resources. This is all discussed in my article:

BMR and cluster node restores
http://www.symantec.com/docs/HOWTO84852

OK, baseline, use the registry mod to allow for easy BMR client configuration capture and allow for restore using the much more efficient 'Fast Boot/Fast Restore SRT" method.

View solution in original post

8 REPLIES 8

sdo
Moderator
Moderator
Partner    VIP    Certified

Apologies, but IMO, there's not enought detail/scope in your post to help us understand the question/scenario.  Would you be able to post a copy of the text which you regard as discounting support for the given conditions?  Thx.

pgm10s
Level 5
Partner Accredited Certified

I test doing BMR on the following environment.

Master Server : NBU 7612

Client : windows 2012 R2 x64   with  SFHAW 6.1 , NBU client 7.6.1.2

When I toook a backup.

 Error bpbrm(pid=3600) BMRERR: Received BMR error: Errors were encountered while discovering disk configuration. 

 

 

Nicolai
Moderator
Moderator
Partner    VIP   

BMR support for Storage Foundation has been removed in 7.6.1.x

Don't ask me why - I find it strange Veritas doesn't support its own products. However BMR is primarily intended to recover boot disks - VCS uses shared disks that can be restored the normal ways. 

The error you are seeing can have other reasons that Storage Foundation. Take a look at the bmrsavecfg debug log - OID 121 using vxlogview.

pgm10s
Level 5
Partner Accredited Certified

Hello

    I cannot see the specific client in the BMR client view. So we cannot use BMR to recover the Boot disk.

Nicolai
Moderator
Moderator
Partner    VIP   

Is the client at version 7.5.0.6 or higer ?

https://symwisedownload.symantec.com/resources/sites/SYMWISE/content/live/SOLUTIONS/76000/TECH76648/en_US/nbu_76_scl.html?__gda__=1440105646_913461957aa56581ca8f04e99dee64b5#operating_systems-microsoft_windows_server_2012

pgm10s
Level 5
Partner Accredited Certified

nbubmr.jpg

Jaime_Vazquez
Level 6
Employee

BMR integration with SFW has always been a problem. The only SRT build that would work was the "Legacy SRT" process, itself a much longwer and distinctly complicated restore process.

Most clients making use of SFW have it to manage non-local drives/file systems.  Those tend to be backed up by a separate policy and not part of the backup of the OS image itself. So the reality is that BMR is not in play for those data disks but BMR, by default, see all of the attached dirves and tries to work with them in a geeral overall manner.

That being the case, there is a small easy work around for this that alows for recovery of such cleints a the OS drive level. The mechanism is show in this article:

http://www.symantec.com/docs/HOWTO88823

When SFW software is installed, the OS drive, although not directly managed by SFW, has its volume manager key set to SFW for the entire system. The OS drive is not modified and works quite well using the normal Windows LDM service.  The registry key entry that is described "tells" BMR to work against only the non-SFW drives and do so as if they were normal LDM drives. The SFW drives are recognzed as such by the bmrsavecfg process and are tagged as such and marked as "Restricted" by BMR.  As such, they are not seen or manipulated in any manner during the recovery process.  And, as the BMR confifguration file has been set up as normal LDM drives, normal 'bmrrst.exe' processing occurs at restore time. There is a special tag in the configuration file that has BMR keep the normal SFW software key in the restored registry.  It also keeps teh drivepath  definitons of the data drives in there as well.  On reboot, this information has the client re-attach to them as a normal process.  This is equivalent to dong a "Prepare To Restore" and choosing teh options "System Disk/Volumes only" and "make available non-restored volumes on non-restored disks after reboot". Basically do not remove any non-restored volumes from the 'fstab' file (or its equivalent).

Now, as I see thatthis is a VCS cluster situation, I want to add some additonal information. A little extra credit you might say.  BMR is "cluster aware" of MSCS and VCS cluster for 'bmrsavecfg' purposes. It captures both the client's cluster identity and it's physical non-cluster identity (what it wouild look like of cluster servces were disabled). BMR will restrict any resource on the  client that is shared by the cluster. During recovery, it will only recover all local (non-shared) resources. This is all discussed in my article:

BMR and cluster node restores
http://www.symantec.com/docs/HOWTO84852

OK, baseline, use the registry mod to allow for easy BMR client configuration capture and allow for restore usng the much more eficient 'Fast Boot/Fast Restore SRT" method.

 

Jaime_Vazquez
Level 6
Employee

My apologies, as I failed to do spell checks on the entry. Here it is, spelling checked.

BMR integration with SFW has always been a problem. The only SRT build that would work was the "Legacy SRT" process, itself a much longer and distinctly complicated restore process.

Most clients making use of SFW have it to manage non-local drives/file systems.  Those tend to be backed up by a separate policy and not part of the backup of the OS image itself. So the reality is that BMR is not in play for those data disks but BMR, by default, see all of the attached drives and tries to work with them in a general overall manner.

That being the case, there is a small easy work around for this that allows for recovery of such clients a the OS drive level. The mechanism is show in this article:

http://www.symantec.com/docs/HOWTO88823

When SFW software is installed, the OS drive, although not directly managed by SFW, has its volume manager key set to SFW for the entire system. The OS drive is not modified and works quite well using the normal Windows LDM service.  The registry key entry that is described "tells" BMR to work against only the non-SFW drives and do so as if they were normal LDM drives. The SFW drives are recognized as such by the bmrsavecfg process and are tagged as such and marked as "Restricted" by BMR.  As such, they are not seen or manipulated in any manner during the recovery process.  And, as the BMR configuration file has been set up as normal LDM drives, normal 'bmrrst.exe' processing occurs at restore time. There is a special tag in the configuration file that has BMR keep the normal SFW software key in the restored registry.  It also keeps the drive path  definitions of the data drives in there as well.  On reboot, this information has the client re-attach to them as a normal process.  This is equivalent to dong a "Prepare To Restore" and choosing the options "System Disk/Volumes only" and "make available non-restored volumes on non-restored disks after reboot". Basically do not remove any non-restored volumes from the 'fstab' file (or its equivalent).

Now, as I see that this is a VCS cluster situation, I want to add some additional information. A little extra credit you might say.  BMR is "cluster aware" of MSCS and VCS cluster for 'bmrsavecfg' purposes. It captures both the client's cluster identity and it's physical non-cluster identity (what it would look like of cluster services were disabled). BMR will restrict any resource on the  client that is shared by the cluster. During recovery, it will only recover all local (non-shared) resources. This is all discussed in my article:

BMR and cluster node restores
http://www.symantec.com/docs/HOWTO84852

OK, baseline, use the registry mod to allow for easy BMR client configuration capture and allow for restore using the much more efficient 'Fast Boot/Fast Restore SRT" method.