Feature Request: Changes to job processing with 0 VMs

[micoolpaul]

Afternoon!

I just came across this with a customer's environment that caught me a bit by surprise.

Customer has a weekly replication job, one VM in the job only, a SQL Server.

Replication runs for months successfully. One day, I don't know why yet, the VM is no longer processed by the job.

The job is now processing 0 VMs, and completing successfully, so nobody is notified there's an issue. We then see a DR test whereby the VM is quite far out of date, this brings the issue to our attention.

I've raised a support case today (04133002) to be told this is expected behaviour.

I don't think this is how backup software should behave, as backup is risk mitigation, we should be risk aware, if a job is now processing no VMs, shouldn't it default have "failed" to protect any workloads? As opposed to having "successfully" protected no workloads?

Possible behavioural changes proposed:
Option One: First job run after a VM has been removed from a job, job finishes as a warning with a line listing the VM is no longer processed, ensure this is intentional.
Option Two: Jobs with no VMs default fail with registry key setting to revert to old behaviour / Registry key to flip jobs with no VMs to fail instead of succeed.

I'd be interested to hear what other users think of this behaviour and if it aligns with their expectations?

[veremin]

Replication runs for months successfully. One day, I don't know why yet, the VM is no longer processed by the job.
. The job is now processing 0 VMs

This can only happen as the result of permanent failover:

To protect the VM replica from corruption after performing a permanent failover, Veeam Backup & Replication removes the VM replica from the Replicas list. Additionally, Veeam Backup & Replication reconfigures the replication job and adds the original VM to the list of exclusions. When the replication job that processes the original VM starts, the VM will be skipped from processing, and no data will be written to the working VM replica.

Anything besides permanent failover that leads to the described situation is unexpected and should be investigated by support team.

Thanks!

[micoolpaul]

Hi,

Thanks for this, I can confirm it's not as a result of a permanent failover as it's a multi TB VM that has a replica in a different DC.

I'll get this followed up with support.

Thanks,
Michael

[PetrM]

Hi Michael,

I think you see this behavior because your customer added a container (folder, resource pool) having the SQL server into a job and then he moved away this VM from container.
I've just reproduced this behavior in my lab with replication job by processing the whole container and moving a VM away from it: next run is successful and 0 objects are processed.

Although, backup job behaves exactly as you described in the Option 1: says that VM is no longer processed and then gives a warning: "Nothing to process. All machines were excluded from task list".

Please ask our support team to check if my assumption about container was correct: the behavior must be the same for both backup and replication jobs.
This hint might be helpful for our support team and would probably simplify the investigation.

Thanks!

[micoolpaul]

I've reopened the case now and what's interesting is on the job run we don't see any mention of "this VM is no longer processed" the exact output is:

Job Started at 17/01/2020 21:00:13
Building list of machines to process
VM size: 0.0B
Changed block tracking is enabled
Job finished at 17/01/2020 20:00:46

No VMs listed in the processing column etc.

Ticket is now reopened under (04135327) and I'm about to start a remote session now with support.