Proper procedure to update backup job after Quick Migration?

[keithlammers]

Please forgive me if this is a dupe, I checked the FAQ and searched the forums, but couldn't find a similar question.

tl;dr: Is there a recommended procedure for updating a backup job after the VMs have been Quick Migrated off the host, and then Quick Migrated back? Or do you always just have to delete the backup repository and start the job fresh after the Quick Migration?

I've got the following setup:

• Two ESXi 5.1 hosts with local storage only
• Veeam backup job for VMs on host 2 (forward incremental with synthetic full on Saturday)

Here's the scenario:

• Moved the VMs off of host 2 using Quick Migration
• Did some maintenance on host 2
• Moved the VMs back to host 2 using Quick Migration
• Did a rescan on vCenter from within Veeam, ran backup job, but it failed saying it couldn't find the VMs
• Edited the job, VMs showed as unavailable when clicking Recalculate, so I removed them, and re-added them
• Ran the job again, this time it completed successfully, but created brand new backups of each VM in the repository
• After a few days, I did a "Remove from disk" on the "old" VMs in the backup repository (Under Backups > Disk > Job)
• On the next job run, it fails with "Full storage not found" (after the previous step, I noticed that there were no .vbk files in the repository, so this error makes sense)

I've fixed this for now by just deleting the whole repository, and re-running the job, but that of course has left me without the older restore points. Is there a better way to do what I did above while still keeping the old restore points?

Thanks!

[foggy]

Keith, is there a chance that the host maintenance procedures had caused VM IDs change that resulted in Veeam B&R treating them as new ones (VMs were registered in vCenter anew)?

[keithlammers]

I was just installing ESXi patches, so I don't think any of that should have affected it. One thing I forgot to mention is that when I did the Quick Migration on the VMs, I chose not to delete the source VM files. Would that cause the migrated VM to then be treated as a new one?

[Vitaliy S.]

If you're running migration between two standalone hosts, then VMs will always get the new ID once they are registered on the new host. This is not the case when you have vCenter Server deployed.

[keithlammers]

Ok, sorry, I should have mentioned that we do have vCenter Server as well, which both hosts are registered in, and the vCenter Server is registered in Veeam.

[Vitaliy S.]

OK then I should also have elaborated my reply a bit more.

If you have a vMotion capability included to your vSphere Edition, then during migration Veeam will leverage this feature to perform migration. If you don't have it, then we will be using our own proprietary migration engine (depends on your hardware setup) that will re-register the migrated VM in the VI. This will force your VM id to change.

Here is a bit more details on migration job types > VMware : [FAQ] FREQUENTLY ASKED QUESTIONS

Hope this helps!

[keithlammers]

Ok, that makes sense then. So, since we don't have vMotion, any time I do a Quick Migration, the VM ID will change, and I'll have to start a new backup set for that VM, as the old full/incrementals are no longer applicable to that VM.

Thanks for clarifying, Vitaliy! Just wanted to see if I was just missing something that would allow me to continue on with the same backup set after the Quick Migration, but it appears not

[Vitaliy S.]

and I'll have to start a new backup set for that VM, as the old full/incrementals are no longer applicable to that VM.

Actually, you can use VM backup mapping feature to compare both VM images (in the backup file and on the production hosts) and run incremental passes for the jobs. During mapping backup job will compare all the blocks and then transfer changes only. This is described in the topic Alexander has referenced above.

[keithlammers]

Oh, awesome, good to know! I'll try that out the next time I migrate a VM. Thanks again, Vitaliy and Alexander!