Testing Replica (B&R 6.0 and later)

[foggy]

You do not need to do that. As Luca has explained above:

You do not need to stop the job or snapshot the VM. Simply isolate its network from the production network and power it up while the replica job is not running; you can create a isolated vswitch to test. After tests are ok, simply shutdown the replica VM.

The note in the user guide just warns you from powering on replica VMs manually in the production network and while replication job is running. If your replicas are isolated and the job is idle, you are safe to test.

[Daveyd]

The note in the user guide just warns you from powering on replica VMs manually in the production network and while replication job is running. If your replicas are isolated and the job is idle, you are safe to test.

So, if I have my VM replicas on my DR cluster and the VMs are attached to an isolated VLAN with no production connectivity, it is safe to power them on manually without having to initiate a Failover? I then can test and make changes to the replicas with no impact on the Replica job(s), correct? Any changes that would be made to the isoloated replicas, would remain until a new replication job is run?

[dellock6]

Exactly, the next run of the replica job would simply overwrite those changes you made during tests.

Luca.

[Gostev]

Actually, no - the changes will not be overwritten. This is due to how snapshot tree works in VMware - the changes you've made will be kept intact in the corresponding snapshot that VMware will automatically create once you start the VM on any existing restore point (to protect said restore point snapshot, since VMware wants you to be able to go back to it). You will be able to return to this state at any time later, until you remove this snapshot tree point manually - it is very important to remember to do this, since Veeam's retention will only manage its own restore point snapshots. If you don't remove the snapshot, it may eventually grow to the size of the corresponding VMDK file.

This is covered in the sticky FAQ topic, by the way

[rudyt]

High,

I want to start a replica on a certain restore point (back in time), but leave the production machine running as is. I would line to change the network adaptor of the replica, so the production and the replica 'don't 'see' each other. I could go into vsphere en revert the snapshots on the replica back in time, but I guess this is not the way to do this, so what are my options here ?

Rudy

[Vitaliy S.]

Hi Rudy,

Yes, feel free to use vSphere Client to test your replicas (the same procedure is covered in our F.A.Q.), but make sure you do not have two identical VMs running on the same network to avoid conflicts.

Thanks!

[geraldb]

Hello!

is there a possibility to test our replications ? (if they work fine and are not corrupted..)

thanks

gerald

[deebsr]

I'm looking for a way to test the replicas. From the documentation it seems that Surebackup is only for the backups and does not do the same thing with replicas.

Also the documentation on testing replicas that is available seems to only be for version 5.x and not 6.5.

thanks

[Vitaliy S.]

You can verify your replicas via procedures described in the sticky F.A.Q. topic, please check it out.

[zaphodepicurus]

Hopefully this will be an easy question - I am new to Veeam B&R and have read the documentation on failing over. I have a main site and a DR site. DR is connected via 30 Mbps link ethernet link and uses the same network address as my production LAN. Question is on failover. If I use the Veeam interface and failover a repplicated VM it powers on the replica but leaves the original VM on as well. So I have two VMs up simulataneously with the same IP address and name etc - so is the original VM supposed to stay on or do I need to manually turn it off? I understand that in this mode the failover is not committed and if I undo failover it powers off the replica and all goes back to normal replication cycle.

Another question is how to test my DR site. I've read some procedure where I need to disable the replciation job, take a snapshot of my replica VMs, change their Network to an isolated vswitch and then power them up to confirm they work then power them back down, revert/remove the snapshot and reset the networking to the proper vswitch and LAN. Is this the preferred way to test my DR replicas as opposed to using the built in Veeam "Failover" option?

[Pietmuis]

Hi Guys,

I need some advise please.

I am replicating VMWare 5 Windows member servers to my DR site with Veeam 6.5.

The DR site is part of our production network but in a remote site to our main data centre (Both sites have domain controllers and are connected via a 100meg link).

For arguments sake say I am replicating Server1 with an IP address of 172.30.17.10 to the DR site.

Incase of a real DR it would be simple to bring up the replica in the DR site as i would just start it up and change it`s IP to the DR sites network (lets say 172.30.15.10) and users will be able to connect.

The problem is how do I test the replicated Server1 in a DR test? I need to bring the replicated Server1 online in the DR site while Server1 is running in the production site. Users at the DR site then need to test the services hosted on the replicated Server1.

Thanks for the advise!

[mrmicp]

Hi,

I have a replica of a DC running and wondered if there is any way to verify the replica in a Virtual Lab or maybe another way to verify the replica ?

Thanks in advance

Mic P

[freddieleatham]

Hi,

In a DR test scenario, we will start up up our replica infrastructure at our DR site, and all users will work from that site.

After the test, how can I push changes on the DR site back to the Production site?

I think it is in the Failback Wizard, however there are no replicas in this page.

Thanks

[kjc3303]

Take your pick

Kev

To launch the Failback wizard, do one of the following:

•On the Home tab, click Restore and select VMware. In the Restore from replica section, select Failback to production.

•Open the Backup & Replication view and select the Replicas node. In the working area, expand the necessary replication job, select the VM and click Failback to production on the toolbar.

•Open the Backup & Replication view and click the Replicas node. In the working area, expand the necessary replication job, right-click the VM and select Failback to production.

•Open the Backup & Replication view and select Active under the Replicas node. In the working area, select the necessary replica and click Failback to production on the toolbar or right-click the replica and select Failback to production

[freddieleatham]

Thanks for the quick reply!

What happens if I failover manually. I would like my tests to not depend on the Veeam infrastructure so I ssh onto the DR esx, create snapshots of all the machines, then power them on. If this is a basic DR test I will stop the machines and revert the snapshots, but if users are involved I will need to failback the VMs.

Is this possible? Or is it perhaps sensible to use the Veeam infrastructure for tests where I need to failback and only do manual ones where I can discard the delta?

Thanks

In all

[freddieleatham]

Another question, during the DR Test - assuming it is a full test with users etc, should I power off the production VMs?
We don't have vmotion, so will the DR site be powered down, the shapshots moved back and merged with production, then production powered up?

[foggy]

Freddie, please review this topic on replica testing considerations. Should additional questions arise, feel free to ask here.

Besides, I would also note that the upcoming Veeam B&R v7 will provide the SureReplica finctionality for automated replica verification.

Thanks!

[kjc3303]

Thanks for the quick reply!

What happens if I failover manually. I would like my tests to not depend on the Veeam infrastructure so I ssh onto the DR esx, create snapshots of all the machines, then power them on. If this is a basic DR test I will stop the machines and revert the snapshots, but if users are involved I will need to failback the VMs.

Is this possible? Or is it perhaps sensible to use the Veeam infrastructure for tests where I need to failback and only do manual ones where I can discard the delta?

Thanks

In all

Freddie, no need to take snapshots in a manual test, just power up you DR vm's and test (in an isolated network if Prod VM's are still powered on). Shut them down when you finish and you Replica schedule will resume.

[Vitaliy S.]

Is this possible? Or is it perhaps sensible to use the Veeam infrastructure for tests where I need to failback and only do manual ones where I can discard the delta?

If you failover manually (not using backup console), then failback operation will not be available for you, since your backup server will not be aware about failover operation. If you want to transfer all the changes back, then you need to configure new replication jobs, choose VM replicas as source and point these replicas to production VMs. Hope this helps!

[Guido]

I am testing my replica. I took a snapshot within VI client and changed the NIC settings of the replica. After power on there is a message from the Boot manager.
"Windows failed to start. Ar recent hardware or software change might be the cause. To fix the problem:......
File: \windows\system32\winload.exe
Status: 0xc000000e
Info: Yhe selected entry could not be loaded because the application is missing or corrupt."

I did have more not bootable replica's in the past. I do this testing according to the recomendations.

Please help

[foggy]

Guido, what recommendations are you referring to? Since each replica restore point is a common snapshot, you can simply power it on with vSphere Client, no need to create additional snapshot. Please review this topic for recommendations on testing replica VMs in vSphere. Thanks.

[Guido]

see KB1073

[foggy]

What Veeam B&R version are you using? The procedure described in this article refers to versions prior to v6.

[Guido]

v6.5
But can this be the cause of the error? Do I need veeam to test the replica? Or is my manual snapshot ruining the vm?

[foggy]

Most likely change of the NIC settings caused the above-mentioned error. What changes have you performed?

[Guido]

I changed the "Connect at power on".

[veremin]

Hi, Guido. Can you just revert settings back to the previously used values and follow up-to-date procedure that is pretty good covered in these sticky FAQs?

And don't forget that new feature called SureReplica that provides you with automatic replica testing functionality will be available in the upcoming release. So, stay tuned.

Thanks.

[james575]

Actually, no - the changes will not be overwritten. This is due to how snapshot tree works in VMware - the changes you've made will be kept intact in the corresponding snapshot that VMware will automatically create once you start the VM on any existing restore point (to protect said restore point snapshot, since VMware wants you to be able to go back to it). You will be able to return to this state at any time later, until you remove this snapshot tree point manually - it is very important to remember to do this, since Veeam's retention will only manage its own restore point snapshots. If you don't remove the snapshot, it may eventually grow to the size of the corresponding VMDK file.

I just read this entire thread and the FAQ, but want to make sure I am understanding this correctly. I have a replica at my DR site that is currently powered off. I want to test it, so I separate it from the production network and power it on manually with vSphere. Once it is running, I test it. So my point of confusion...

I do not want/care about changes made to the replica during the testing phase. When I am done testing it, I want to power it down and have the replication job continue as normal. Should I then go into vSphere and delete the most recent snapshot on the replica?

(Thank you--great thread here BTW.)

[foggy]

I do not want/care about changes made to the replica during the testing phase. When I am done testing it, I want to power it down and have the replication job continue as normal. Should I then go into vSphere and delete the most recent snapshot on the replica?

No, you do not need to do anything after powering the replica VM off. The job will continue to run normally, the changes made during the testing phase will be discarded.

[terrance101]

Hey guys,

my boss keeps pestering me for an answer on this but truthfully I don't know and was hoping someone could explain. When I replicate a server, then down the original and bring up the replicated server, change all sorts of files on it and work on it for a while. Then I can prove to him that on the next replication from the original all the changes that are made on the replicated server are erased (and the original server is again cleanly replicated) even though only the differential data is going across to the replicated server. He keeps pestering asking me how this is and I don't have an answer... can anyone shed light on what witchcraft is going on here?