by cardendave » Mon Jan 18, 2016 11:06 pm people like this post
I have a problem with a clients backup which I believe is quite common:
server.server.local is no longer processed by this job. Make sure this change is intentional.
From what I am reading this is something to do with a change in vmware, but nothing has changed. I have tried removing the virtual machines and readding them but no joy, although I am doing this without submitting in between as I cannot submit zero VMs. If I create a new job it works, however I cannot recreate the old job as I do not have the space to start a new repository and it also goes to Cloud Connect that I would also have to reseed.
by rreed » Wed Jan 20, 2016 5:24 pm people like this post
We also occasionally get random ID changes, causing this same issue in our environment. Same thing. I just remove/re-add the VM to the job and go on (no job recreation, etc). Its next backup will run a full of that particular VM in the job, it does give the same "complaint" until retention passes, along w/ seeing the VM show up twice in the backup file until passing. I dunno, I just live w/ it and cut my eyes at VMware when it happens.
by dahuafschmied » Wed Jan 20, 2016 6:17 pm people like this post
hi i had a case some days ago. #01243304 how to assign the new ID to the old backup files. result: not possible and no plans for a tool/workaround to do this. ( i know this is not exact this case. just for information if you are thinking about fixing this case this way.
by rreed » Thu Jan 21, 2016 2:30 pm people like this post
Thanks foggy, great article! But for us it's, we all go home at the end of the day, nothing happens/changes over night via human hands, no DRS running, replication, vmotions, etc., come in the next morning, Veeam suddenly can't find/identify a few VM's here and there. As mentioned, I just remove/re-add and go about my business. It's few and far between, doesn't seem to hurt much, so I just live w/ it. Until it happens w/ one of my 3-7TB VM's, then it might become an issue.