Feature request re: replica retention

[sbumpas254]

When running large replication jobs, we have a few customers wherein the replica retention policy commit takes as long or longer than the actual replication job. While much of this could easily be attributed to storage (3 node 1Gb hybrid vSAN clusters, for example) it seems like Veeam could easily change this behavior so that the retention policy is committed as part of the VM process rather than waiting until all VMs have been completed, and then running in groups?

Right now it's:

VM1 replicates
VM2 replicates
VM3 replicates
....
VM1 retention applies
VM2 retention applies
VM3 retention applies

I do see that roughly 4 VMs are processed in parallel during retention commit, but I think it would be better if:

VM1 replicates
VM1 retention applied
VM2 replicates
VM2 retention applied
etc.

This method would also allow replicas to continue running while retention is applied, if the proxy had available resources.

I'm sure I'm not the first person to suggest/think of this - maybe htere's a erason it hasn't been done yet?

[mkaaden]

Not sure if this is already been asked, it would take me most of the day to read ALL the articles about parallel processing.

But I was wondering this:

I notice in both backup and replication jobs that post vm processing only starts when the last vm in the job has done its 'thing'
Like in a backup job, even when it is set to backup per vm, restore point consolidation only starts when the last vm has finished backup processing and all snaps are deleted.
And in a replication job removing old restore points only start when the last vm finished replicating data.
The latter is quite annoying on a low bandwidth replication link when one VM's has temporarily more data to replicate or when a vmdk has grown.

Why can't these processes start immediately when that particular vm finished writing its data ?

Also with a replication job when it set to start after a backup job finished, hWhy can't the job start when a vm in the backup job has finished writing data ?
One vm with a lot of changes in a job can hog the replication.

Regards,
Martijn

[foggy]

Hi Martijn, some time ago this was intentionally changed to the way it works now, since previously the snapshot removal task for one large VM could block other VMs from being processed. However, I agree, there are still certain ways of improvement here.

[mkaaden]

Why not add an option in the job settings to enable or disable this behavior ?
Than people can choose to set it if it suits the job.

Martijn

[foggy]

It might be a good idea that would require support of two different mechanisms in the code though. Currently it doesn't seem it is of great demand - just a couple of requests since the change was made five years ago.

[nesj11]

+1 for this feature request

replication job with more VMs take much more time as it could... please, add an option to apply retention policy right after processing each VM.