Target Issue

[Zew]

I thought this problem had been fixed but appears to still be an issue... :S

Deleted VM due to a mistake made, restored entire VM with option to restore VM Tags.

Ran Active Full on job a vew days later, says target has been delted or does not exist. (This this not the point of the checkbox restore VM Tags???!)

Had to edit job, re-select VM (same name as original) and now Backup job states "13/03/2017 11:58:26 AM :: This-VM is no longer processed by this job. Make sure this change is intentional." When I run the job?

How does one recover a VM fully while keeping the dang backup job intact?

My Old post about this issue was about Instant VM restore, this Time I did a full VM restore, with the Tags option, so a bit different, but expected my Backup job to be unaffected. Which it clearly was...
vmware-vsphere-f24/restore-vm-without-b ... 36490.html

[gollem]

Do the following:
- Delete the job
- Rescan your vcenter from the backup infrastructure tab
- Create a new job
- Do an active full

That should resolve it for you.

[Zew]

Mmm, thanks Gollem, the easier solution is to open the job, select the target VM, delete, click add, re-add the VM, click Finish.

That however is not the answer to the question...

"How does one recover a VM fully while keeping the dang backup job intact?"

Just to clarify that got my VM working on the backup job, you solution is probably to clear the existing warning, which I posted, that was not a huge concern as it was more of an FYI notice, and more of an annoyance then a problem.

[mma]

Hi

To keep it short & simple:

Restore of a VM = New VM = new VM ID.
Restore VM Tags has nothing to do with your VM ID.
Ask Google about vSphere Tags

vCenter, ESX Hosts, Veeam... don't care about the VM Name. Ech VM has a unique ID which is also used for the VM selection in your job settings.
Just remove and re add the VM to your job. Don't delete the job, there is no need for it.
If you delete the Job, you have an "orphaned" backup in your repository.

Regards
Marcel

[foggy]

Marcel is correct, this comes down to the new ID the restored VM (similarly to instantly recovered VM) gets upon registration in VI, which makes Veeam B&R to treat it as a new one.

[Delo123]

As Marcel said it will always be a new vm since it has a new id. However if you do not want to change jobs in the future after restoring a VM you could backup your vm's by using "VMs and Templates" in the add objects screen for backup instead of choosing individual VMs), also in case of adding a new VM in the same "folder" it will be automatically picked up by Veeam

[Zew]

It be nice if Veeam implemented a checkbox that says the old VM is forever gone, when you restore this VM, replace the existing jobs VM ID with the newly restored one. Bam call it a day. everyone's happy.

[Delo123]

How should Veeam know what the old vm is? Just by the name? In theory you could restore every vm to that name and Veeam would never know it actually isn't the same etc... But yeah, maybe something they could think about in some way...

[Zew]

Delo123, it would know the old VM by it ID? the exact problem that exists now. They could even add an algo to look to see if the existing VM ID exists within vSphere, if not have a pop up or something stating "Hey, noticed you are restoring a VM that doesn't seem to currently exist in your vSphere. Is the restored VM replacing the old VM ID?" Click yes, the backup job runs I guess a new chain for the newly recovered VM (Although it be nice if it still be able to keep the old source and still do CBT) but that may not be teh case or possible.

[mma]

Why not change your job setup?
You can select Folders, Tags, vCenters, Hosts.... as Job source. Your job setup with selection by VM name / VM ID is a bit outdated.

[blithespirit]

The simple answer to your question is around vCenter, you deleted the vm and vCenter deleted the data and iDs (MoRefs) from the database, when you recovered it using Veeam it does not recover the ID to vcenter database as that is not part of the backup file, so, when you recover the vm and Veeam checks vCenter for your ID when the job starts it does not exist anymore hence the error but it does find the name and a new ID so you get the request for confirmation.

In this circumstance it is as designed in vCenter. When you do an emergency recovery the ID is still within the VCenter database so you don't have any issue all pointers are functional.

Does that answer why it does it and why Veeam does not see it again?

Methods to change the job have been discussed.

Cheers

[Zew]

MMA,

If the souce job was set via a vCenter VM folder instead. I delete the VM, I do a full restore of the VM. Then Veeam picks this up as the same VM and continues the job with a normal forward incremental VIB? Or does the job simply create a whole new chain for said VM?

[foggy]

It will pick it up as a new VM and perform a full backup of it during the next incremental job run (entire VM data will be read and written into the corresponding VIB file).

[Zew]

basically if you ever have to recover a VM, you can never use the old chain?

[foggy]

You can map to the old chain, but entire VM will be read during the next job run anyway.

[Zew]

It will pick it up as a new VM and perform a full backup of it during the next incremental job run (entire VM data will be read and written into the corresponding VIB file).

But you said it does a full. What goods a VIB if you only have one VM in the chain, and it has to do a full after recovery?

[foggy]

This way you do not end up with two separate chains for the same VM, but continue the same chain maintaining its retention.

[Zew]

I get that, but the chain (VIB file) will be huge cause it contains technically a full copy of the restored VM, as well as the old (before restore) copy of the same VM, correct?

[foggy]

VIB will contain the entire data for the restored VM, right. Ifthe old VM is still running and backed up, VIB will also contain changes occurred in it since the last job run.