Remote replica from backup still uses source VM's

[mkaaden]

Hi,

I have a setup with a physical backup server on the production site running 4 esx hosts attached to iscsi storage
The backup server also hosts the repository.
On a remote DR site I have 2 esx hosts and secondary iscsi storage.
It is just good enough to recover from in the event of a total disaster.

So I setup several back jobs to the repository and a couple replication jobs.
The replication jobs are set to only keep 1 restore point.
All VM's from the replication jobs are seeded to the DR site and I already have several incremental seeds.
Hence, on the Seeding tab we checked 'Initial seeding' and we checked 'Replica mapping' and all VM's are mapped to their counterpart

However I notice sometimes a replication job does not use the backup from the repository to replicate, but uses snapshots on the production.
This is not desirable because some VM's are very busy during production and the snapshot/consolidation proces is notable in performance.

How and where can I check why the replica job uses the source instead of the backup from the repository ?

regards,
Martijn

[veremin]

I'm wondering whether source options are configured as needed. Replication job -> Virtual Machines -> Source -> From backup files -> Repository.

If so, the described behaviour looks unexpected, and logging support ticket is needed.

Thanks.

[mkaaden]

Hmmm, now that you mention source options I checked the configuration again and noticed it was still on "From production storage (actual VM state)"
That explains a lot !

However I am still puzzled with the 2 options at "Seeding"

So the first option states: Initial seeding -> Get seed from the following repository
Does this mean only the initial seed or also any subsequent incremental seed ?
And if Replica Mapping is also set and all VM's are mapped, does that mean that the replica is done from the production VM ?

I changed the source in a test job to "From backup files (..)" and unchecked Replica Mapping.
Now the job log starts with: "replicating restore point from backup repository" (Yeah !!!) but also it starts calculation digests on the target VM.
Is that the difference ? When mapping is set, it will calculate digests on the source and when not set it will calculate digests on the target ?

[veremin]

Does this mean only the initial seed

This.

And if Replica Mapping is also set and all VM's are mapped, does that mean that the replica is done from the production VM ? Is that the difference?

Not sure whether I totally got those question, Replica Mapping is one-time operation useful when you plan to replicate VM that already exists in the DR site.

With Replica Mapping in place, during an initial run a replication job will calculate the difference between the original and mapped VM (digest calculation).

Thanks.

[mkaaden]

But is it still useful to set on a replication job when all the VM's are already present on the replica side ?

Because I'm a little confused about the statement at the bottom of this page: https://helpcenter.veeam.com/docs/backu ... tml?ver=95

There it says:

If replica seeding is enabled in the job settings, all VMs in the job must be covered with seeding or mapping.
If a VM is neither available in the seed, nor mapped to an existing VM replica, it will be skipped from processing.
And, on the contrary, if the same VM is available in the seed and mapped to an existing replica, replication will be performed using replica mapping as mapping has precedence over seeding.

So is Best Practice to set both options or only one ?

I have seen different behaviors during the execution of replication job: one time it was calculating digest on the source VM and now it calculates digests on the destination VM
I just want to understand the process so I know what impact it has on VM's/storage

[veremin]

But is it still useful to set on a replication job when all the VM's are already present on the replica side?

It's useful during initial run, because it reduces the amount of traffic sent over the network. Subsequent incremental cycles will be performed in the regular manner.

So is Best Practice to set both options or only one ?

There is no such thing as best practice for those options, because it all comes down to what you're trying achieve. Seeding might address one use case, mapping - the other.

I have seen different behaviors during the execution of replication job: one time it was calculating digest on the source VM and now it calculates digests on the destination VM

You seem to have tried variety of options, so, I'm not sure what behaviour you experienced in what particular case. Typically, the digest calculation should happen only during initial synchronization, if replica mapping is setup, or after some infrastructure changes.

I still strongly encourage you to take a second look at Replication section of our Help Center, all of those questions are covered there in details.

Thanks.