Feature Request: Ability to run Active Full for single machines on Copy Jobs

[danilo.brambilla]

Hello,

when a Copy Job fails for several machines only, you can only run an Active Full for the whole job to restart the chain.

If the job contains many machines it is very time and resource waste.

I.e. imagine that your destination is an immutable cloud storage: you'll need to upload again all your machines, instead of upload only the corrupted ones.

So, I am requesting to be able to run an Active Full Copy for specific machines only, not for the whole job.

Thank You and Best regards

[vnikiforov]

Hello, Danilo,

Active full for individual workloads already exists for regular backup jobs, while on a backup copy job active full is still job-wide.
Can you please share what scenario you are trying to avoid or resolve?

So, if we are concerned about source backup vbk\vib files deliberate corruption (on binary level) backup copy will not even copy these files to the immutable object storage repository, as CRC check will fail, while the other machines in the job keep copying normally.
And on the immutable repository itself, it is already impossible to change anything by design.
If, for some reason, you need to redo per machine active full, do that on the source side, remove the corrupted chain, and the copy job forwards only that machine's new restore points onward.
Backup copy moves just the changed blocks per workload, so you send one machine's data to the immutable repository rather than the whole job.

[irosinsk]

I run into a similar situation to the above occasionally: the primary backup job completes fine, with no corruption, but due to network or system issues on Veeam's side, the backup copy to the secondary target becomes corrupted and fails to complete. Then I receive various errors as the backup copy job retries and retries, but cannot complete due to the corrupted incremental restore point in the secondary target.

Before we had immutability set up, I was able to delete the corrupted restore point on the secondary target to let the job finish. On immutability-enabled repositories, the corrupted restore point cannot be deleted; lately, my solution has been to switch the copy job to periodic mode with "synthesize from increments" disabled, and either run an active full on the primary job or wait for the next synthetic full, both of which work inconsistently (and, if I can't get the copy to work right away, any primary restore points between the break and the fix never get copied over).

Since the corrupted restore point is on the secondary target's side, the simple solution based on my reading would be to take a new active full of the backup copy job, but as Danilo mentions, we cannot take an active full copy of only the failed machines, instead being required to re-copy all the good restore points and wasting even more space.

Consider this a +1 to the feature request.