Job Report configuration

[noteirak]

Hello Everyone,

About the job reports that are sent by e-mail, I would have like to change some notification option : how to disable the "<vm> is no longer processed by this job. Make sure this change is intentional." message?

I have a backup job that is configured to backup everything on a specific cluster, and VMs change clusters from time to time (automatically or manually). Therefore, this message keeps being displayed everyday which is rather annoying. Is there a way to disable it at all?

Thank you for your help!

[Vitaliy S.]

Hello Maxime, as far as I know there is no way to skip (not to display) this message in the job report/session summary. To avoid situations like that the only workaround that comes to my mind is to use VM folders as the backup containers for your backup jobs. Thanks!

[noteirak]

Alright then, I'll try do to that, Thank you for your quick answer!

[pealto59]

[merged]

I'm using Veeam 6.0 with daily backups and a continuous replication job. The replication job frequently sends a report that "[servername] is no longer processed by this job. Make sure this change is intentional."

My issue is that a) it's not intentional, and b) that server is still showing up in the list of servers to replicate, and it seems to be replicating just fine.

So why am I getting this message all the time, and how do I make it stop?

Thanks.

[dellock6]

Has happened to me right today. Veeam Backup server run out of memory and several jobs starts to hang and failing with that error. I rebooted the server and the jobs retried correcty. Not sure what caused the underlying Windows server to act like this...

[Gostev]

The primary reasons for this behavior is ESXi host or vCenter Server occasionally not returning the full infrastructure tree. This happens from time to time, my guess for possible reasons are high load or network glitch. But we are seeing this quite often in real-world environments.

[davidb1234]

Actually you guys seem to have some kind of bug. This is not a vcenter issue.

I have a single 2 host cluster. I vmotioned a VM from one host to another in that cluster and the backup job cannot seem to locate the VM after the vMotion. This is during my intitial testing of the product. We haven't gone live yet. However we are fully licensed and purchased the software. We did a fresh install of version 6 update 3.

Support wasn't much help. [ID#5184893]

I was able to fix the backup job by readding the Vm but now I get the message in my job log that the OP refers to. I need to be able to clean that message up from the job log. Also I am worried because support was not able to help me determine why the job all of a sudden could not find the VM after a simple vmotion on the same cluster. At the very least I need to be able to remove that message from appearing in the job log.

[Vitaliy S.]

Veeam B&R tracks all VMs by its unique moref ID which is kept intact during vMotion operations. The only way to change this ID is to re-register the VM in virtual inventory or re-add ESX(i) server which hosts this VM.

Having looked through your support case details I see that you've re-added ESXi host to your inventory after some sort of issue with vCenter Server, right? Did it happen during your backup job tests?

[travis.vanholland]

I have had the same issue in my test environment. 2 ESXi 5.0.1 servers and just doing a backup job from one to the other. No vCenter environment setup here. After a couple of weeks the backup job will start failing and I have to readd the VM back in to the backup job for it to start working again. I am on version 6.0.0.181.

[StuartHurst]

[merged]

Hi
Getting a VM is no longer processed by this job. Make sure this change is intentional warning after I moved the VM to a new host, and then altered the backup to reflect this change. Now we get this warning. How do I get rid of this warning, or alter a backup job so that this doesn't happen? Based on the warning, and that data is being read, I believe that we're still backing up but this warning makes my director nervous...

Thanks for your help

[dellock6]

You need to wait for the "deleted VM retention period" to expire (default is 14 days) or you can reduce the value to 1 so Veeam will delete the moved VM from the original backup set, and after that increase again the value to what you like.

Luca.

[Matts N]

Hello!
I have a customer, running 6.5 patch 1, where we have been moving VM's around between hosts and now have the "<vm> is no longer processed by this job. Make sure this change is intentional." message. In the backup job I expect this to disappear once the VM retention has passed.

But... The replication job doesn't have any VM retention and the restore points have been rotated through long ago and the message still appears. Any thoughts on this?

Edit: Should probably add that we haven't recreated the backup or replication job, we simply removed the "old" VM's and re-added the "new", migrated ones to an existing job.

TIA!

// Matts

[v.Eremin]

The replication job doesn't have any VM retention.

Hi, Matts.

The deleted VM retention period isn’t shown in VB&R GUI for the replication job. However, if you take a closer look to it by the means of PowerShell, you will see that these options are still there:

Code: Select all

asnp VeeamPSSnapin
$Job = Get-VBRJob -name "Name of your replication job"
$Job.BackupStorageOptions.RetainDays

Moreover, you can even edit them in the same manner as if it were the backup job and set whatever number you want:

Code: Select all

asnp VeeamPSSnapin
$Job = Get-VBRJob -name "Name of your replication job"
$OptionsToSet = $Job.GetOptions()
$OptionsToSet.BackupStorageOptions.RetainDays = "The deleted VM retention period" #By default this number is 14.
$Job.SetOptions($OptionsToSet)

Don’t know whether this approach is likely to meet your expectations, though, it might be worth trying.

Hope this helps.
Thanks.

[Vitaliy S.]

Hi Matts,

If you use VM folders as source for you replication jobs, this message shouldn't appear even if you decide to move VMs between datastores, hosts.

Thanks!

[v.Eremin]

Our QA team has just confirmed that it’s an issue with a notification letter that will be probably addressed in one of the future updates.

Hope this helps.
Thanks.