Small Feature Request: Per-VM Schedule Respect

[ekisner]

Not sure how much of a mess it would make on the backend to code something like this (I suspect a lot), but in the event of a VM with an abnormally long runtime within a job, it'd be cool if the rest of the VMs in that job could respect their schedule and start normally within the already-running job, instead of waiting for the problematic VM to finish, then the whole job completes, then be ready for the next scheduled run time.

For example if you were to decide to add a few TB of new data and you had a fairly high frequency (eg every hour), you end up missing on your SLA because the recovery points that would have been created were not created while the job was catching up on that VM. While the problematic VM is going to be short on recovery points, it was going to be no matter what... the rest, however, don't really have any excuses beyond "the job blocked itself".

Within the UI it could be as simple as a checkbox to allow the VMs within the job to start into an already-running instance of the job when the schedule says they're due to be backed up.

[Gostev]

The use case is clear, thanks for the detailed explanation. Unfortunately, this is not even remotely possible with the current architecture - but I will keep that in mind since it goes along some of the planned architecture changes.

However, there's a workaround today, which is to put each important VMs into its own dedicated job. This is actually fairly common approach of handling those super important tier-1 VMs, as it provides for more granular control.

Thanks!

[DonZoomik]

Sounds like my request from a while ago: veeam-backup-replication-f2/feature-req ... 47210.html