Replica back sync?

[Zew]

If you have a host with replicated VM's, and the primary VMs go down and you spin up the replicas....

Then the primary hosts come back, how do you get the changed data on the replica back to the primary VMs without breaking chains or other stuff?

I'm at a loss at this part of a DRP....

[Andreas Neufert]

Can you please have a look at this and come back here if you have additional questions...
https://helpcenter.veeam.com/docs/backu ... ml?ver=100

[Zew]

OK... but what if the Veeam server itself is Down at the primary site? And I have to spin up the replicas manually at the "target site", then it's used for a while, Then I bring back my "source VM's" including the main Veeam server, can I still "failback" without Veeam knowing about the original "failover"?

[PetrM]

Hello,

but what if the Veeam server itself is Down at the primary site?

I'd recommend to deploy Veeam server on DR site to allow failover plans to work seamlessly and without any manual complex operations, please refer to our best practices guide for more information.

Then I bring back my "source VM's" including the main Veeam server, can I still "failback" without Veeam knowing about the original "failover"?

It would be possible if you restored configuration database on the primary site so that Veeam is aware of VMs in failover state.
However, you won't face an issue when Veeam does not know about failover of some VMs if it's deployed on DR site.

Thanks!

[Andreas Neufert]

If you set your B&R Server to an older stage because of restore, then you need to Rescan the replicas. B&R will detect the status of the Failover/failback.

[Zew]

Thanks for thank info Petr. I didn't see that infrastructure design change coming... But if there was an issue at the DR site doesn't that mean backups wouldn't run? AFAIK proxies themselves don't run jobs they simply handle the transporting of the data usually CBT data. Sorry for my ignorance, restore configuration from what? When? if the primary site went down, and I manually spin up the replicas, what config needs to be restored on Veeam?

Thanks Andreas, in this case there be no changes to the state of Veeam I guess... so you're saying if I only powered up Veeam, which I couldn't I'd need at least AD up n running too, so not sure how'd I failback those ones, guess could leave them not replicated as unlikely that would change as no users to be created, but computer relationships in AD though, ugh... yeah I can see why the alternative is a decent idea, but in order to have Veeam at he DR site wouldn't I need to have AD working across sites then too? Oi ve... also, is a failover/failback plan need to be defined in Veeam to work, or can you still failback if you simply spin up the replicas?

[Andreas Neufert]

You can implement Veeam without Active Directory and let the backup speak with other components without AD.
However DNS is a critical service that we relay on.
Usually customers implement AD domain servers on both sites to continue work when one site is down.
Or customer use hosts entries for the Veeam infrastructure (Veeam and VMware Server).
Authentication to the vcenter can be local one as well.

[Zew]

I like my Veeam integrated with our AD for exchange purposes....

Would a RODC work at the DR site?

[foggy]

If you start the replicas manually, you will not be able to failback via Veeam B&R even after your restore it from backup. To get the changes occurred while replica VMs were running back to the source site, you will need to create replication jobs in the opposite direction and map them to the original VMs - Veean B&R will calculate the changes and replicate them to the source side.

[Zew]

Thanks Alexander I will test this in a test setup. Much appreciated. Is this assumption still correct? "But if there was an issue at the DR site doesn't that mean backups wouldn't run?"

[foggy]

Yes, to address this you can set up two instances, the local one responsible for backups and the remote instance reposnsible for replication. Alternatively, you could fire up a new Veeam B&R instance, restore configuration and proceed with the backups normally.

[Zew]

I kinda figured, but that requires additional licenses, correct?

[foggy]

Not actually. Provided you're protecting the same VMs, you can use the same license for both.

[Zew]

Nice.. however I just replicated a VM, powered off the source, powered on the replica, but cause I gave the replica a suffix when I create the job for the replica back it'll just create another vm with another suffix.. I don't see any way to point a replication job to a target V, just a target host... how do I "create replication jobs in the opposite direction and map them to the original VMs"?

[foggy]

Mapping settings are available at the Seeding step of the job wizard.

[Zew]

Oh interesting, I didn't expect to have to pick that top checkbox at the start of the wizard to do that, felt a bit unintuitive. I tried it out and right now I noticed there was no traffic flow for a good while...
checking the job I forgot replicas have snapshots so the jobs stated the following warning.
"CBT can not be enabled one or more snapshot are present."
which it then goes on to "calculate the digests" and this part is unreal slow. even for this small test VM this part took: 20 minutes.
After that though it did appear to work, just going to test my original back job. Thanks so much for all your replies. Great as always!

[foggy]

Digests calculation can take a while as Veeam B&R needs to read the entire VM and compare the blocks to define the changes to transfer.

[Zew]

Yes "take a while" is a generous term for this process.

1) I tried to delete the snaps on the replicated VM, before creating the back replication job. Even doing this the back replication job still took 20 Min to do a digest calculation. Is there any way to create a failback job in which it won't require to do a digest calculation and just rely on regular CBT data? This is a detrimental step to the RTO's in the DRP....

2) If this can't be helped is there anyway to speed up the process? I find even with high speed storage and a solid Veeam server this is a painfully slow process.

[foggy]

Veeam B&R cannot know if you're mapping the VM to the its replica and not to some third VM, there's no CBT to rely on yet at that moment, so it needs to calculate the differences anyway.

Digest calculation speed depends on the size of the virtual disks, the underline storage data read speed and the link between the proxy and repository with replica metadata. You could expect a digests calculation to take as long as an active full backup of the VM to some fast repository.

[Zew]

Mhmm indeed, I also test a failover/failback using Veeam directly as to actually know these things, and I noticed there was a step "Calculating original Hard Disk" which I thought was going to be the same thing but it only took 3 minutes vs the manual digest calculations. I'm assuming this is indeed different? Funny Searching the digest thing up I see old posts from 2012 with people asking the same thing .

Thanks for all the help so far foggy!

[foggy]

In case of failover/failback to the original VM Veeam B&R already has the digests so doesn't need to calculate them for the entire VM.

[Zew]

I see, this is probably why you(Veeam) suggests, in the infrastructure design to put a Veeam B&R server at the DR site...

[foggy]

This recommendation is mainly to allow for automatic failover via Veeam B&R console, while faster failback is more a consequence.

[Zew]

Wait a second... if I have a second Veeam server at the DR site, but it uses the vCenter at the primary site, and the primary site goes down.. how would Veeam be able to failover? Wouldn't it need the ESXi hypervisor host directly added? or is like some crazy load balanced vCenter required?

[Zew]

I also came across another issue, I got the Veeam a the DR site up and configured, but after creating the replication job I first got no restore points found, due to me pointing everything at the DR site repos.
Whoops forgot to scan it. After scanning I get the same error as this guy "Restore point is located in backup file that is not mapped to any backup job"vmware-vsphere-f24/replication-to-dr-si ... 36145.html
Which they stated rescan, I did that, or have job at primary site, which I wanted to move due to the exact discussion in this thread.... what gives?

[foggy]

Wait a second... if I have a second Veeam server at the DR site, but it uses the vCenter at the primary site, and the primary site goes down.. how would Veeam be able to failover? Wouldn't it need the ESXi hypervisor host directly added? or is like some crazy load balanced vCenter required?

You're correct, in that kind of setup, you would need the target ESXi host to be added directly and replication jobs pointed to that host for automatic failover to work.

As for the mapping issue, then it is expected as the backups are created by another Veeam B&R instance. You can create a 'dummy' disabled backup job on your DR Veeam B&R instance that would be mapped to these backups so that they can be used for seeding.

[Zew]

Excellent, will test that out and report my results. Great as always Alexander.

[Zew]

Just one follow up question... Do I leave vCenter added to the Veeam at the DR site, or do I remove it and just add the standalone host?

How exactly do I create this Dummy backup job? I'd need to leave vCenter added on the Veeam at the DR site, add source VM from production side point to the backup job data... I'm a bit confused here...

[foggy]

You can have both vCenter and a standalone host added to Veeam B&R to select the source VMs via vCenter and point the job to the target ESXi host directly.

[Zew]

Thanks for the additional info Foggy. Just an update, I wasn't able to get the replication job to work when mapping to the existing VM's on the DR host, even after creating a "dummy" backup job for that VM, and having both the vCenter server at primary site, and ESXi host standalone added to the DR Veeam's system inventory. It just kept erroring with the same result "Restore point is located in backup file that is not mapped to any backup job."

However, If I built the replication job exactly the same leaving the mapping to a current VM out of the job (creating a whole new VM) the job worked and succeeded without issue besides a warning that no newer point exist then seed. It would be nice to figure out how to get that to work, you know with my previous form post on seeding on site. So I guess that type of seeding doesn't work with this issue, and the recommended the seems to be better for sure.