Skip Calculating Digests and Just Redo thee Replication Job?

[RPTan]

We noticed that whenever Veeam encounters an error with their replication job it automatically does digest recalculation. Is there a way to skip this an just redo the replication job from the last good replica? Usually it takes longer to recalculate digests, especially on big VMs (almost a day to recalculate vs. replication job of couple of hours).

[Vitaliy S.]

Hi Ryan,

If you want to redo (run active full), then you can force it via Veeam backup console by right clicking on the VM. Digest calculation is required to do an incremental pass and detect what data is missing in the target location.

On a side note, can you please tell me what's your destination site? What connection do you have to the target host?

Thanks!

[RPTan]

Hi Vitaly,

As we are talking about replication, what I meant is that can we redo the job from the last good replication point before the error occurred, and not the full incremental again?
Destination site at the moment is just hosts on an isolated network connected via gigabit, as this is testing before moving from Production to DR site.

On a side note, what causes slow performance for digest calculation, especially for large VMs (multi-disks of mutli-TBs each)? What performance can we expect anyway?
We use hot-add mode, with a source and target proxy, and have placed the metadata repository at the production side.

Thanks,
Ryan

[Vitaliy S.]

what I meant is that can we redo the job from the last good replication point before the error occurred, and not the full incremental again?

When digest calculation takes place, your replication job tries to do exactly this. Currently there is no way to skip this process.

On a side note, what causes slow performance for digest calculation, especially for large VMs (multi-disks of mutli-TBs each)? What performance can we expect anyway?
We use hot-add mode, with a source and target proxy, and have placed the metadata repository at the production side.

Hmm...that's a good question. I would suggest to take a look at digest calculation log file to see if there is anything suspicious or not. Our support team would be glad to assist you with task.

[foggy]

Digests calculation speed directly depends on the size of the virtual disks and can take considerable time for larger VMs.

[RPTan]

Is it safe to say that there is something definitely wrong when doing a VMWare clone (from one datastore to another) is faster than replicating via replica mapping for a large VM? or is this still expected? I'm assuming digest calculation does mainly a read on the storage and should definitely be faster right?

[Vitaliy S.]

It's almost correct, but digest calculation and then transferring data might take more time (in some cases) compared to just running active full replication job run.

[mcz]

Hi!

From time to time I have to increase the disk size of a particular vm which is part of a replication job. Of course, changing the disk size will cause veeam to merge all restore points (=snapshots) of the replica and to calculate the digests for just transfering the deltas between source and target vm. The thing is that this digests calculation is taking quite a lot of time and this will block other jobs (because veeam locks this machine and some proxies until replication is finished) and cpu usage is much higher.

My production and dr-site is within the same network and connected via a 1 GBit Ethernet. Therefore, creating a replica from scratch wouldn't take that much time than calculating the digests and just transfer the deltas to the target. I know that this wouldn't be the case if my dr-site wouldn't have this fast connection in between(e.g. over a wan connection), calculating the digests would then be the faster way.

So the questions are:

• why does veeam calulate the digests if production and dr-site have a fast connection to each other?

• is there a way to suppress the calculation of digests for specific jobs and replication the whole disks instead?

• are there other pro's for calculating digests over other actions?

Thank you for your help!

[DGrinev]

Hi Michael,

why does veeam calulate the digests if production and dr-site have a fast connection to each other?

Digest calculation speed depends on the size of the virtual disks. After the process changed data blocks should be transferred to the replica VM, so the traffic between sites is minimized.

is there a way to suppress the calculation of digests for specific jobs and replication the whole disks instead?

You can manually run Active Full through UI by right clicking on the VM, this could be much faster than digest calculation.

Please review this thread above for additional information. Thanks!

[mcz]

You can manually run Active Full through UI by right clicking on the VM, this could be much faster than digest calculation.

Thank you for your answer, Dmitry, but I am not able to find "active full" if I right click on the vm. The Replication job (it's a job for a containter, not a single vm) doesn't show the option in the context menu and under "virtual machines" I just got the options "veeamzip", "add to replication job", "quick backup" and so on. Where should I find this option?

Thank you in advance!

[DGrinev]

Sorry if it was not clear, but in order to run active full, you should delete the target replica VM.
That's why it's not recommended way due to potential risk of losing replicas.

[mcz]

OK, so there is currently no other way to run active full. This would be a nice feature for future updates... Running active full for a specific vm (or maybe the whole job) would be something that won't take too much time for the veeam engineers to implement

[Delo123]

Maybe, but the risk is quite big. With "run active full" one would possibly not be aware that the replica on the target side would be completely lost, in case of a really big VM i'm pretty sure some people would quickly start looking for a "undo" button....

[zmedgyesi]

I agree with mcz. In my case, I have backup copies on the secondary site, and replicas are created from backup copies. For example, our file server's replication failed this weekend, because of a planned electric maintenance. Veeam started to calculate digests for a 1.1 TB disk, which lasted for more than 8 hours. We have a proxy on the secondary site, and my guess is, reading backup copies from its locally attached disks and writing them through FC to the storage must be much faster than calculating digests endlessly. And, in the meantime, it seems we have a few "Veeam working" snapshots under VMware - I don't know yet, how to treat them, I'm afraid they are stuck, and at the end of the day, I'll have to manually delete the VM and restart its replication. So, the end result is the same: delete affected VMs and re-replicate, and during the process, we don't have a working replica - not for a few hours but for days! Why not have a checkbox which does the same for me?

[antipolis]

+1 on this

after resizing disks on a large VM I just delete the target replica cause it's way faster to start from scratch in our environment, in this context having the extra checkbox in the rep job would save the extra step of manually deleting replica

[DominikM]

The same here, I have a 4TB Fileserver that is replicated to a remote site. The calculating of the digest takes forever. So every time the disk gets expanded I have to delete the replica and resync again. It's still faster than waiting for the end of the calculation.