Old VM's showing in logs?

[neilpotter]

When a backup job starts, in the action list after Building VM list, we have a list of old, unregistered VM's showing up with notes of "vmname is no longer processed by this job".
Is there something I need to do to remove the old vm's from the config as they don't show within the job edit screens.
These old VMs are also "tested" during a SureBackup of the main backup job we have. Again, I can't work out how to exclude these old gm's.

Thanks

[Gostev]

These messages should only be logged once for each VM that was unregistered. Do they keep repeating for the same VM?

[neilpotter]

Yes they appear at the start of every job. However, i've just realised that I can remove those old backups from the "Backups" section under each repository. That has now stopped the old VM's "erroring" on the backup job. For clarity I just have two jobs to backup ALL of my VM's. One for the local site, and one for an off site copy.

Is this the right way to sort this?

[foggy]

What retention and Deleted VMs retention settings do you have for this job and what backup method it is using (forward or reverse incremental)? And what Veeam B&R version are you at?

[neilpotter]

Hi guys.
Realised I never had the retention set, so i've sorted this. Had some other issues since so I forgot about this.

Thanks for the help.

[Moebius]

After upgrading from v7 to v8 some SureBackup jobs are failing.
This is due to some vms that were removed from the job, but that are still tested on each SB run.

The backup job gives this informational message: "<your-VM-name> is no longer processed by this job. Make sure this change is intentional." This is fine, as I have 30-days retention set in my backup jobs. I want the removed vms to be kept in my vbk files for a while before being deleted.

What I don't understand is why the SB job tries to test those vms as well. It should simply get the current vm list from the backup job, not the vms that have been removed from the job - regardless whether they still are in the backup files or not.
This never happened with v7 and I believe this unwanted behavior was introduced in v8.

[veremin]

I've asked QA team to confirm that behaviour; will update the topic, once I have more information. Thanks.

[nefes]

So we've had a test on VMware SureBackup job in both v7 and v8.
First run of job backed up VM1 and VM2. Second run backed up only VM2.
After that we've started SureBackup and linked that Backup job to it.
In both v7 and v8 VM1 and VM2 are started in SureBackup, and that job finished successfully.

I suppose, you have slightly different case? Could you please elaborate a bit, what was the difference and what error do you see in SureBackup?

[Moebius]

I don't have the possibility to test with v7 anymore.
However, I'm positive that I never saw the SB job failing in v7 due to a vm removed from the job. It's possible that the removed vm was tested and the test succeeded, so the fact that a removed vm was still included in the job went unnoticed.

Now, the removed vms are failing the SB job due to "OS not booting in the allotted time", but that's not the point. The vms were removed from VMware and from the backup job due to several reasons; I cannot think of a single reason why the SureBackup job should keep testing them (and even worse, testing an old vm image, always the same: the image when the backup included those vms last time).
It seems that the only way to stop getting this failed status from the SureBackup job would be to delete the removed vms from the backup files without waiting for the retention to expire, which I don't want to do since I want to keep the images of the removed machines for some weeks more - if only to be able to access the guest files.

This sure looks like a bug to me.

[veremin]

That's by design. Surebackup gets list of all VMs present in restore points, and tries to verify them. As long as VM is present in backup, it will be verified by SureBackup. Thanks.

[Moebius]

Thank you Vladimir. I understand that it's by design.

However, it does not make any sense to me. SureBackup should get the list of all the VMs currently present in the backup job and not in the restore points. Could you explain what's the point in verifying VMs that are still in the restore points but not in the backup job anymore? Thanks.

[foggy]

SureBackup should get the list of all the VMs currently present in the backup job and not in the restore points.

This will not work if some sort of dynamic container (host, datastore, VM folder...) is used to add VMs into the job.

[Moebius]

That's a good point, I hadn't thought of that.
Still, I find the actual behavior unsatisfactory. Any workaround to get rid of the error messages short of deleting the removed vm from all restore points?

[foggy]

The current behavior is not ideal, however it is, so to say, the lesser of two evils. Cannot think of any workaround, though. You can try to disable boot verification settings for this particular VM or increase boot timeout.

[Kynaeus2]

Hi guys,

Veeam B&R Enterprise 6.5 / VMware 5.1.0

I've been going through my 2x surebackup jobs every day trying to improve the reliability of the test by adjusting settings and VMs, eg updating VMware tools, allowing longer timeouts, that sort of thing. I've also been cleaning up redundant VMs that were previously being backed up by shutting them down and deleting them from disk. I subsequently went to the Veeam backup job and removed the corresponding VMs. I'm finding that the Surebackups are testing all the VMs in the linked backup job but also the ones that used to be in it too. For example,

the backup job will contain these VMs:
Oracle application 1-1
Oracle application 2
workstation 1

the application group will contain these VMs:
Domain Controller, marked with the DNS, GC, and DC roles

and the surebackup will link the backup job, but when actually running it will test these VMs:
Oracle application 1-1
Oracle application 1 (recently restored and then subsequently removed from Vmware, hence the 1-1)
Oracle application 2
Oracle application 3 (redundant, deleted from VMware datastore and Veeam backup job)
workstation 1

I've unlinked the backup job and saved the Surebackup, re-added it and confirmed it only shows the VMs the backup job has, refreshed the list in the backup job, double checked the virtual lab and application groups... Not seeing any other people having this problem around, unless my google phrasing is just off for describing the problem.

[Vitaliy S.]

Hi Greg,

Do you still have restore points for these VMs in the job? Did you delete these VM from VI and from backups?

Thanks!

[foggy]

Greg, please review the thread above, this behavior is currently expected.

[Kynaeus2]

Thanks Alex and Vitaliy, I didn't realize this behavior was expected.

I'm still within the retention period for the deleted VM's so I assume that's why they're still being tested. As I noted they were removed from VMware inventory and deleted from the datastore, since I'm fine with losing this VM entirely by removing the restore points for it. Am I better to wait until the retention period passes and they're removed automatically or am I better off going into the backup target and removing the restore points starting from the oldest full to the next full (to prevent inconsistencies with incrementals)?

[foggy]

You'd better wait until retention applies. Restore points might contain other VMs as well.

[MSweetman]

Hi All,
I'm seeing something unexpected in a SureBackup job.
Running VB&R 8.0.0.2084 (latest V8) and have been cleaning up Backup and SureBackup jobs to optimise storage and performance.
A Daily Backup (Forever Inc) job contained both Windows and Linux machines was operational.
A separate Daily Linux job has been created and a Surebackup job has been created for it.
The original Daily Backup (Forever Inc) job had the Linux VMs removed, the remaining Windows VMs were sorted into the required order and saved as the Windows Daily backup job.
Both backup jobs are running fine.

Both have a newly created SureBackup jobs linked to their respective backup jobs. The new SureBackup for Linux is working fine however, the new SureBackup for Windows is trying to test both the Windows VMs and the Linux VMs.

It would seem that the new Surebackup for Windows job is still testing all the VMs from the original backup job and not using the new Windows Daily linked job, ever though is does the correct linked job.

Any ideas on how to rectify this?

[PTide]

Hi,

Any ideas on how to rectify this?

You should delete old VMs data from backup. Just set VM retention to 2 (some minor bugs may occur if the value set to 1) and wait. After two days all VMs that have been excluded from the job will be gone from the backup as well and your Surebackup job will check only windows machines.

Thank you.

[MSweetman]

Hi,
Thanks for the quick response.
Will reduce the VM retention to 2 and await the outcome.
Interesting observation.....(Scheduled) SureBackup is designed to verify the most recent backup using either a App Group, a Linked job or both. In either case one would think if the VM is no longer in either the App Group or the Linked job, the VM would be excluded from testing.
May be worth an enhancement....
Again thanks.

[foggy]

Yes, this is how it currently works, Surebackup verifies all VMs that present in restore point. Please review some considerations in the thread above.

[MSweetman]

Hi All,
We successfully run a number of Surebackup jobs daily which gives great comfort to the management that the backups are good.
One SureBackup job uses our Exchange backup job which is our AD & Exchange servers - 2 AD + 2 EXCH 2016 + 2 EXCH 2010.

We decommissioned the 2 Exch 2010 servers and removed them from the Exchange backup job back in early Nov.
The backups for the 2 EXCH 2010 servers are still in the repository, along with the other AD & EXCH servers.

One thing that I'm curious about is one Surebackup job starts 2 servers which are no longer backed up.
Note - have removed and re-added the backup job to the SureBackup job.
Why would the SureBackup start the 6 servers and not just the current 4 in the actual backup job.

Thanks......Mark

[foggy]

Hi Mark, this behavior is expected, please review this thread for details.