Comprehensive data protection for all workloads
Post Reply
noteirak
Lurker
Posts: 2
Liked: never
Joined: Dec 12, 2011 10:42 am
Contact:

Job Report configuration

Post by 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.
VP, Product Management
Posts: 27055
Liked: 2710 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: Job Report configuration

Post by 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
Lurker
Posts: 2
Liked: never
Joined: Dec 12, 2011 10:42 am
Contact:

Re: Job Report configuration

Post by noteirak »

Alright then, I'll try do to that, Thank you for your quick answer!
pealto59
Lurker
Posts: 1
Liked: never
Joined: Apr 10, 2012 5:34 pm
Full Name: MazUser
Contact:

"[servername] is no longer processed by this job." But it is

Post by 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
Veeam Software
Posts: 6137
Liked: 1928 times
Joined: Jul 26, 2009 3:39 pm
Full Name: Luca Dell'Oca
Location: Varese, Italy
Contact:

Re: Job Report configuration

Post by 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...
Luca Dell'Oca
Principal EMEA Cloud Architect @ Veeam Software

@dellock6
https://www.virtualtothecore.com/
vExpert 2011 -> 2022
Veeam VMCE #1
Gostev
Chief Product Officer
Posts: 31460
Liked: 6648 times
Joined: Jan 01, 2006 1:01 am
Location: Baar, Switzerland
Contact:

Re: Job Report configuration

Post by 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
Expert
Posts: 162
Liked: 15 times
Joined: Nov 15, 2011 8:47 pm
Full Name: David Borden
Contact:

Re: Job Report configuration

Post by 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.
VP, Product Management
Posts: 27055
Liked: 2710 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: Job Report configuration

Post by Vitaliy S. » 1 person likes this post

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
Influencer
Posts: 13
Liked: 2 times
Joined: May 15, 2012 8:02 pm
Full Name: Travis Van Holland
Contact:

Re: Job Report configuration

Post by 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
Influencer
Posts: 10
Liked: 2 times
Joined: Mar 02, 2012 8:42 am
Full Name: Stuart Hurst
Contact:

Moved host of a VM and altered this in Backup

Post by 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
Veeam Software
Posts: 6137
Liked: 1928 times
Joined: Jul 26, 2009 3:39 pm
Full Name: Luca Dell'Oca
Location: Varese, Italy
Contact:

Re: Job Report configuration

Post by 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.
Luca Dell'Oca
Principal EMEA Cloud Architect @ Veeam Software

@dellock6
https://www.virtualtothecore.com/
vExpert 2011 -> 2022
Veeam VMCE #1
Matts N
Enthusiast
Posts: 59
Liked: 10 times
Joined: Dec 27, 2010 10:41 am
Full Name: Matts Nilsson
Contact:

Re: Job Report configuration

Post by 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
Product Manager
Posts: 20271
Liked: 2252 times
Joined: Oct 26, 2012 3:28 pm
Full Name: Vladimir Eremin
Contact:

Re: Job Report configuration

Post by veremin » 1 person likes this post

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.
VP, Product Management
Posts: 27055
Liked: 2710 times
Joined: Mar 30, 2009 9:13 am
Full Name: Vitaliy Safarov
Contact:

Re: Job Report configuration

Post by 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
Product Manager
Posts: 20271
Liked: 2252 times
Joined: Oct 26, 2012 3:28 pm
Full Name: Vladimir Eremin
Contact:

Re: Job Report configuration

Post by 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
Product Manager
Posts: 20271
Liked: 2252 times
Joined: Oct 26, 2012 3:28 pm
Full Name: Vladimir Eremin
Contact:

Re: Job Report configuration

Post by 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
Enthusiast
Posts: 59
Liked: 10 times
Joined: Dec 27, 2010 10:41 am
Full Name: Matts Nilsson
Contact:

Re: Job Report configuration

Post by 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
Product Manager
Posts: 20271
Liked: 2252 times
Joined: Oct 26, 2012 3:28 pm
Full Name: Vladimir Eremin
Contact:

Re: Job Report configuration

Post by 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
Enthusiast
Posts: 59
Liked: 10 times
Joined: Dec 27, 2010 10:41 am
Full Name: Matts Nilsson
Contact:

Re: Job Report configuration

Post by 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! :)
Post Reply

Who is online

Users browsing this forum: Ivan239 and 251 guests