VMware migration -- effect on Veeam backup/replication

[averylarry]

I briefly mentioned this in the following topic: v6 initial incremental massive
but it was more of a tangent.

Anyway -- I'd like to understand what affect VMware migration has on Veeam backup jobs and Veeam replication jobs. This has nothing to do with Veeam's Quick Migration.

I have VMware Essentials Plus. This means I do NOT have Storage vMotion. This weekend, I shut down several of my virtual machines and ran a VMware migration to change the datastore. To be clear -- I used the VMware client and did a right click on the powered off virtual machine and selected "Migrate...". This brought up VMware "Migrate Virtual Machine" wizard where I changed the datastore for the virtual machines. The processes ran successfully.

The replication jobs for these machines all show that it read AND transfered all of the used disk space in the migrated virtual disks. They all show that CBT was used (Hmm . . maybe that's the problem). One of the replication jobs is still running (almost 40 hours but it's got 400Gb left to go over a 10Mb WAN).

So I want to know if that's the way it's supposed to be. It clearly sees the VM as the same VM. It used hotadd and CBT without complaining. The "Transferred" data shows that it's transferring all of that data. If I forced "network mode", would it possibly do better? What if I removed the VM from the replication job, and then added it back and mapped it to the existing replica for seeding?

The same thing appears to have happened with the backup jobs on these VMs. However, deduplication and local access just made the jobs take quite a bit longer without actually causing problems.

[Andreas Neufert]

Hi Averylarry,

maybe I can not fix your problem in a short explanation.

Let me say some words about our software (version 6)

CBT:
We use CBT to detect the changed data blocks on the vmware datastores. This gabe use the possibillity to only read out these blocks. (No Full).
So it is good that this is enabled.

Direct SAN Access / Virtual Appliance Mode (Hot Add) / Network mode:
If you use FibreChannel or iSCSI and share the datastores with a Hardware Veeam proxy Server, we are able to read out the data direct from the storage system.
If you have a virtual Veeam Proxy Server and the Datastores are connected to the same VMware host we can use Ho Add (Virtual Appliance Mode) to map the datastores to our proxy and read out the data directly.
If this two options are not available we use network mode to read out the changed data over the network (slow).
Normaly the Proxy is configured as Automatic mode which picks the best mode for you.

The proxy uses compression and deduplication to reduce the amount of data.

In case of replication, the data will be transfered to another proxy, who uncompress and undedup the data and write it to a datastore as a virtual machine.

In case of backup, the data will be tranfered to one of our repository server.
These repository server builds sysntetic full backup files and incremental or reverse incremental backup files.

So in any way veeam reads only one full and then only changed blocks.
In some cases this will break and a new full will be transfered to the other side.
1. The VMware ID of a virtual machine was changed. (But same VMware VM Name). Maybe this happens if you use your way of migrate VM.
2. The target is delete.
3. In case of backup you perform an "Active Full"

CU Andy

[dellock6]

I've seen many times storage vmotion, if done while the VM is powered off like in your case, resets the CBT data and the next backup copies all the blocks and not only the newly modified ones. I wrote about it in another thread on these forums.

Luca.

[averylarry]

What's the best way to recover from CBT that gets messed up? Transferring 2Tb across a 10Mb WAN is not reasonable, and should not be necessary, but that is what my system appears to be trying to do.

[dellock6]

well, there is no real "recovery", CBT can be reset and started from scratch.
Can't you create a replica seed and move it on the other side of the wan link?

Luca.

[tsightler]

At a bare minimum you should be able to seed with the existing replica using replica mapping. Assuming you have a proxy on both ends then each side will read their own disk locally, calculate the hashes, and only transfer what is different. This has no bearing on CBT or anything else.

Honestly, even if CBT is not being used, assuming you have two proxies it should never transfer the data over the WAN link. The local proxy will scan the 2TB looking for changes rather than using CBT information.

[averylarry]

That's why I'm trying to figure this out. Instead of recovering nicely someway, it seems like it's just going to transfer everything over the WAN. I've already tried doing a new replication job using the existing replica as a seed, but I'm getting an error. I'll probably just have to follow up with tech support.

dellock6 -- Well sure. There are plenty of ways to start over. I don't want to have to do that every time I need to migrate a VM to another datastore so I'd like to understand what's going on both for now and for the future.

[dellock6]

Right, but if it depends on CBT, is a VMware issue, and maybe Veeam can do little about it.
But as per Tom post, CBT is not involved at all, so the issue may be in some other element. Sadly for you I cannot imagine where to start looking...

Luca.