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

[veremin]

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!

[veremin]

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.

[veremin]

In addtion, Matts, can you shed a little more light on your replication scenario to help use better understand your scenario?

Generally speaking, this message means that the given VM is no longer present within the job. In case of replica, you can either move necessary VM back to the replication job if this VM has been deleted accidentally or ,otherwise, just remove it from replicas. In both of the cases this message will disappear.

Hope this helps.
Thanks.

[Matts N]

I will *try* to shed some light on what it is we have done.

It's a small customer, with 2 licensed ESXi servers (think it's Essentials, but not sure). There is no shared storage, everything is run locally on the ESXi hosts. Originally, VBR took a backup from the production ESXi to the "backup" ESXi, as well as replicated a number of VM's. That is, backup and replication from host A to host B.

Host A got too old and slow, so our customer bought a new host, host C. I wasn't thinking about the migrate capabilities in VBR and instead set up a new replication, now from host A to host C. During a weekend we shut down the VM's, did a final replication and started them on host C, thus leaving host A empty and ready to be decomissioned. After this, the backup jobs where changed to use host C as source instead of host A, still with host B as target. The same change was made with replication, using host C as source instead of host A, with host B as target.

Since the VM's had been moved, they changed moRef ID and wasn't recognized by the jobs and had to be re-added. Since the VM's where re-added with new ID a completely new replication was started, not touching the old replication at all. I manually removed the now defunct replication target, to make room for the new replica. Maybe this could be a problem, there is nothing for VBR to clean up?

After this the informational message appeared, for obvious reasons. The backup job has cleared them out, since retention has passed. In the replication job, however, the message still appears even tho both the original retention of 14 days has passed, as well as a later set retention of two days. That said, my cosmetic problem still exists. Hope the explanation is clear enough...?

[veremin]

I’m wondering what can be seen by going to the “Replicas” node.

Providing I’m right in my assumption, you would probably see duplicated VMs with different creation time. So, all you need to do in order to get rid of this message is to remove duplicated entries with old creation time.

Hope this helps.
Thanks.

[Matts N]

Vladimir, that is exactly what I did, when I realized it started a new replica. Had two VM's with a similar name ('Example' and 'Example(1)') that pointed me to this. I deleted the old ones, to avoid filling up the replica disk.

I won't be back at the office for a couple of days, will check current status when I get back. Thanks for your help so far!