Live servers 'no longer being backed up'.

[readie]

I have backup jobs defined by folders, with an occasional exception. Recently two VMs are being reported as 'no longer processed by this job'.
However, they are still in the folder being referenced by the job (though they might have moved subfolders within there)?
Ah - now I look carefully at my backups on disk, I see that there are two VMs with identical names for each of these two VMs. So I have one VM called server58 with 1 old restore point, and another called server58 with 4 recent restore points.
So I am now less concerned, but what might have caused this, and will the 'dead' restore points eventually be dropped (I think I have 'forget about deleted VMs after 14 days'), and I guess the Job regards them as being deleted VMs and newly created VMs?
Bob

[foggy]

Yes, most likely their moref IDs have changed due to some reason (e.g. VMs were re-registered in inventory). The old restore points will be removed according to the deleted VMs retention.

[readie]

thanks.

[readie]

We are now seeing more and more VMs being 'changed' in this way. One was in an 'exclusion' list, and is now being backed up. The same one stopped being backed up by its 'own' job, as 'machine has been deleted or . . '.
In both cases I have 'removed' from the relevant place in Veeam Backup, and then added again.
This has triggered a FULL (rather than CBT) backup - of a 2.5TB VM.
Should I have taken more time, and somehow persuaded Veeam that this really was the same server?
(I suspect all this happened due to ESXi Host problems, which involved some fairly drastic work on the hosts to get them back into VCentre.)
Bob

[alanbolte]

If indeed the ref IDs did change, there's no supported way to convince Veeam that these are the same VM (you may find some discussion of unsupported edits to Veeam's configuration database elsewhere in the forum). You can check the ref ID's via VMware's Managed Object Browser, or by looking at the names of the logs that start with "task" in c:\programdata\veeam\backup\<job name> on the Veeam server. If you see multiple task logs with the same VM name and different ref IDs (like vm-1234), then you know for certain what happened. Exclusions are also affected by ref ID changes.

Your suspicion about the source of this issue makes sense.

[readie]

Thanks - I'll put it down to experience. I'm just glad I didn't miss an obvious trick. (No I don't fancy messing with someone else's database, so will just let things take their course.)