"VM123 is no longer processed by this job. Make sure this change is intentional " on a backup copy Job

[HansMeiser]

Veeam Version: 12.1.2.172
Hello,

today i got above-noted message in Veeam. I wonder, because it happens on a copy job which depends on a backup job where concerning VM was succesful backed up.
The setup is as follows:
- Job a is a backup Job which backups our VMs from VCenter to a local Storage. This Jobs runs daily and also my missing VM VM123 was backed up every day.
- Job b is a copy Job. It runs every 7 days and copies latest restore point to a remote location. Source of this job are backups from job a. This job was throwing the message.

The message "xxx is no longer processed by this job. Make sure this change is intentional " on a backup copy Job" occurs from time to time but i never took a deeper look, because names and circumstance were plausible. But in this case i have no explanation.
What could be the reason for this? I can not find a difference to other working VMs within these jobs. In my opinion there is no reason to not copy my missing VMs.

Thank you,
Hans

[david.domask]

Hi Hans,

Any chance that the machine in question was perhaps restored and re-added to the primary backup job? This would mean the VM has a new morefID in VMware, which means Veeam would see it as a "new" VM and start a new backup chain for that machine. While the Backup Copy should get the new backup chain and copy it, it's possible you will see "duplicates" for this VM in the Backups > Disk (Copy) section for this VM, and that would explain what you're seeing here.

I think it's best to open a Support Case as noted when creating a topic, and include logs for Veeam Support to review. (Select the 1st radio button, and ctrl+click to select both the source Primary job and the Backup Copy job to export logs for). Support will be able to review the logs and explain the behavior in more detail if my guess above does not apply.

Please share the case number here once created.

Thanks!

[HansMeiser]

Hello,

thanks for your reply. I checked your advices and can say that machine was not restored by veeam or any other manually way. This machine is part of an EXChangeSystem and has high uptime.
In my opinion an copy Job could never throw such a message, because it is just copying the backups a previous job has created and i cant find any gap of backups for this maschine like any others in this job.
We will discuss internally, but i thin it should be escalated to Veeam Support. i know people of Veeam Support are reading this messages, i hoped it is solvable in short term.

Thanks,
Hans

[HansMeiser]

Hello,

my workmate found the solution.
Affected VMs reside on our secondary VCenter and he found a logline that Veeam could not do an login to this VCenter with Message "Failed to log in "at this specific time. I dont know what happend last week in this case, because i did not notice any login problems, seems to be a temporary problem. Todays copy Jobs are working fine.

But alltogether in my opinion this is a strange behaviour of a copy Job. One is expecting that all backups of base-job are copied, but copy job itself did a kind of validity check and decided to not copy Backups of different VMs. In my opinion this should raise an error or warning within the job, especially if existence of VMs could not confirmed by serious problem like "Failed to log in ".

Thanks,
Hans

[david.domask]

Hi Hans,

Thank you for the follow up and glad to hear that you were able to identify the root cause. However, I would still suggest if you're in a position to review the behavior, please open a case and provide logs as suggested for Veeam Support to review. I'm not quite sure I can visualize the context around the failed logins you're discussing just from the above, so it would be best to let Support review why it didn't warn about the failed connection -- the connection makes sense, it's fast way to confirm the machine still exists and needs to be protected by the Backup Copy as well, but the error should be more clear if it didn't tell about the failed connections in the UI.