Start a Conversation

Unsolved

GL

1 Rookie

 • 

27 Posts

649

February 28th, 2023 12:00

Networker BMR questions

Hi,

I have the task to dry run a Networker BMR of a physical server to another machine for testing. I am encountering a few issues and I would love to get Networker's admins opinion on this.

I am running Networker 19.7.0.1 under Windows and I am using the BMR ISO NetWorker_19.7.0.54, which is the ISO corresponding to the 19.7.0.1 release­.

Immediately after booting the BMR ISO, I ran into some issues. After some Googling, I was able to find the wonderful bingo.1's Workaround to run a Windows BMR with Networker 19.6.x & 19.7.x . bingo.1's document helped me to disable the firewall on the BMR client, delete the nsr peer information and manually create the nwservers.txt. Once I implemented these workarounds, the BMR wizard would be much happier and would allow me to continue.

However, I do have some questions because I am running into issues still.

 

BMR restore with multiple physical disks

My understanding is that Networker BMR only restore critical volume(s), which is my case is only the C:\ volume. I backup the entire server (all volumes and DISASTER_RECOVERY) in the backup job, but I understand that BMR will only recover critical volume(s) and I must use Networker User later to restore files on the D:\ drive.

My machine has 2 physical disks (500GB and 2TB). Networker BMR task was only restore critical volume(s), which is the C:\ volume which takes the entire 500GB disk. However, my first restore was unsuccessful, because BMR decided to create the volume on the 2TB disk instead of using the 500GB disk. I am pretty sure this is by design since VSS is not aware of the disk it backed up. I would expect Networker BMR however to ask me where to restore the recovery. I couldn't find a way in the Wizard to select the physical disk as a destination. I see both drives in the wizard, but there is no selection possible. The only workaround I have found is to physically unplug the 2TB disk, let BMR restore on the only available disk and then plug the 2TB back after the restore is complete. Is there a way into BMR to select the destination disk ?

 

Testing BMR to a test machine while the production is still running

I have not yet found a documentation that could help me to test BMR to a physical machine while the original machine is still running in production. In the wizard, if I do not input the correct machine name associated with the backup, Networker BMR fails to find the machine's backups. Not to mention that I must delete the nsr peer when testing BMR and deleting the peer after testing so that nightly backups can be successful. Anyway, I was able to successfully restore the critical volume using BMR Wizard and then boot into Windows (without network) and not impacting the production machine. However, now I must run Networker User program in order to restore files on the 2TB disk...but I cannot achieve that without network. I have thought about changing the hostname and IP of the recovered machine, but if the hostname does not match anymore, Networker User will not be able to find the desired client resource on the NW server and will fail.. Should I instead restore using the Networker UI and push the files to a different destination, which would be the recovered machine with a different hostname and IP ?

My point is, is there a proper way to test BMR restores without impacting production systems that are running ?

Thank you,

Guillaume.

 

4 Operator

 • 

1.3K Posts

February 28th, 2023 21:00

@guillaume.leonard ! Great questions, I haven't encountered the 1st issue that you have mentioned so I will not attempt to answer that.
As for BMR, NetWorker treats this as a DR option and for that matter not only BMR the NetWorker DR does not have a straight forward DR Drill support build in. NetWorker just assumes that the original servers are not available and that we are doing the restore to replace them.
This said the general recommendation for DR drills is to have an isolated environment with all the settings and configuration very similar if not same as the prod environment.
Your scenario for BMR however constitutes to a good use  case and NetWorker should not treat a BMR like a DR. You could raise a Request for Enhancement with your DELL Sales rep or support, may be with enough requests they might just add that support.

March 6th, 2023 07:00

Adressing a conflicting nsr peer info will always be the case as the original system has a different certificate than the BMR client which will create its own one. So up until now it will always require one to delete the client's certificate (or more as there can be more than one entry) on the NW server (and on the involved NW storage node(s) if you use that).

That might change in the future as there might be some improvements on that end, possibly giving you some keys to be used to overrule the existing nsr peer information existing for the client, without needing the backup admin involvement to do that on the NW server.

As BMR expects not only that the original NW client is down, but it also expects exactly the same amount and order of devices as the original client. So I assume that the two disks might be in another order that on the original client. So disk layout should be the exactly the same (or larger drives but still it will not use all space and would require resizing the volume as BMR will use the same size as from the backup, will not perform any automatic resizing) There is no option to choose what saveset should be restored where, as it bluntly stated simply expects everything to be the same...

You can have a client restore data from another client, however after reboot it would assume the identity of the original system and its name and IP address(es), which would lead to duplicate IP address and who knows what more if you have 2 the same systems running in the same subnet...

What we have done however is, as we have a separate backup lan by design, to disconnect the backup lan nic from the original system and have the BMR client only have the backup nic connected and have any customer facing nics disconnected from it. That means that you would temporary have no backup of the original client, until the restored client is powered down again or has its backup lan nic disconnected again.

But once the restore is done, you can have the recovered client reconfigured using different ip's, maybe even in a completely different shielded of subnet to prevent causing issues.

With vm's and vmware image level backups using NW vproxy appliances, creating copies is easier to arrange as you can then assign different ip's before powering on the recovered vm copy.

But NW, unlike some competitors, does not have an easy option to recover systems into a shielded off environment for simple or automated testing or validation.

1 Rookie

 • 

27 Posts

March 7th, 2023 05:00

Thanks both of you for your replies.

I have not found a way, other than unplugging the second hard drive to force BMR to restore on a specific disk. However, I did confirm in Windows, in the BIOS and physically that both machines are identical (same components models) and the disks are plugged exactly the same in the motherboards. So the "order" of the disks should be exactly the same between the source and destination machines.

 

I did however was able to use BMR Wizard and restore without having to delete the nsr peer of the source. Following the official documentation, there is a way to restore using BMR to another machine's name. Of course, once the restore is done, Windows has the source's IP and hostname so there is a network conflict that can happen. But still, it is possible to do this inside BMR Wizard. You must have a Networker resource created for the destination machine and that machine must have Remote Access permissions on the source machine NW resource. The destination machine must also be in the DNS or the hosts file...honestly it feels complicated and not flexible compared to other backups software. The only benefit I have found is to not mess with the nsr peer certificate of the source machine.

Here are the prerequisites to do a BMR restore to a destination machine with a different name (inside BMR only).

  • Ensure that the NetWorker server has a client resource for both the source host and the target host.
  • Ensure that the Remote Access attribute of the source client resource contains the account SYSTEM@target_client. This attribute enables the recovery process to perform a directed recovery.
  • Add user=system,host=target_client to the Users attribute of Application Administrators user group.

This is only the BMR part. Once in Windows, I'm still missing all files on the secondary hard drive and I can't use NW User to restore it, since I must change the hostname+IP of the machine in order to be able to be on the same network. The only workaround I have found is to use NW Console to initiate a FLR to another destination.

Let's just say that our current network does not support really well testing DR drills with Networker.

March 7th, 2023 07:00

I know the option to setup the BMR client with a different IP and name and giving it access to be able to restore data from another client, but as soon as you'd be done and boot the client again, it would have the original client's name and IP, not that of the settings used when performing the BMR while booted from the iso.

As already said we also needed to prevent the backup interface of the original client to be enabled and all the other interfaces disabled but the backup interface from the recovered client, to be able to have both running at the same time. This as the whole premise of the NW BMR approach is to have a client back exactly as it was before, while the original is unavailable.

I hope also that Dell will add some functionality to make these kinda recoveries easier for pure testing/validation purposes by being able to maybe specifying completely different IP/subnet but we have to work with how the NW software has been for years for now... might maybe never be introduced as Dell PPDM might be getting more new features than NW might get.

So once you booted the BMR client, you then can change - at least - the IP, so that you would not have an IP conflict anymore, to be also able to restore data from the original client (by giving the new client remote access to the backup data of the original client). Then both could be running actively on the same subnet, but it still depends what further is supposed to be running on the client as you might not want to have a system trying to do things to and with other systems or data, if the other production system is also active... hence moving it to a shielded of subnet, might make sense if it is mainly for test purposes and validation of the backup/restore procedure.

In our case backup/recovery is often validated by actually shutting down the production system and performing the restore unto another system which from that moment onward acts as the original system, which still can be in a controlled fashion depending on what is required to be tested. So no conflict. Also easily undone by powering down the new system and booting the old one again.

BTW you can use a procedure to simplify activities so that you don't need to alter the BMR client hosts file each and every time by making sure you customize the hosts file from the BMR iso itself by putting all backup infra components in them like NW server, NW storage nodes and Datadomain systems.

So with the iso tool of choice extract the boot.wim file from the sources directory of the NW BMR iso. mount boot.wim on a windows system usign dism.

dism /mount-wim /wimfile:boot.wim /index:1 /mountdir:mount

Then edit \mount\windows\system32\drivers\etc\hosts to your liking and unmount the boot.wim file:

dism /unmount-wim /mountdir:mount /commit

Next add the altered boot.wim back into the NW BMR iso with the iso tool of choice.

You would have to perform that same exercise for each new NW BMR iso that you want to use or whenever backup infra components are added or altered.

No Events found!

Top