Feature Request: allow disabling dedup (re-)calculation on Move / Copy Job

[mfbu]

Case # 07568950 - Slow Move jobs (continuation of 07522453)

TL;DR

this is a feature request for

- allow disabling dedup (re-)calculation on Move / Copy Job


Long version

we have some multi-TB VMs with high change rates; weekly amount of
incremental backups exceeds the amount of a full backup. Some of them do move
just fine across Linux hardened repositories (with XFS fast cloning enabled).
For unknown reasons, two of them (meanwhile split into designated single-VM
jobs) don't. The move will actually finish at some point, but it takes between
36 and 84 HOURS to do so. Scheduled for daily execution, this leads to loss of
one or perhaps even multiple restore points. SLAs don't like this.
During the Move, there are (normal) intervals where the network (10Gbit) gets
almost saturated, and long hours of no network activity at all, with the
"veeamagent" process on the recipient repository running at 100% CPU. I guess
this has to do with (re-)calculating some dedup stuff - the CPU-bound
processing happens just before creating the next .vbk from a pre-existing .vbk
already sitting on the receiving repo and a week's worth of incrementals. As a
possible workaround (for a copy job), I tried ticking the "Read the entire
restore point from source backup instead of synthesizing it from increments"
and waiting a few weeks until there were no more shared blocks between the
files. This did not help.
While we might spend extra $$$ on additional repo servers with XFS fast clone
disabled just for these two VMs (multiply this by a number >= 2 to get the
benefits of a scaleout repo), I think it would be better if there was an option
to de-select dedup calculations for a Move and get the files moved just the way
they are.