Why do I not need to edit my backup job when backing up restored VMs with Instant VM Recovery?

[Asahi]

Hi,

I have a question about backups of Instant vm restored VMs.
Veeam Version : 10.0.1.4854

Normally, restored VMs will have a different Moref ID, so running an existing backup will result in the following error.
===
Virtual Machine is unavailable and will be skipped from processing.
===
If you get this error, you need to open the backup job and remove the VM with a zero size and add it again.

However, if the VMs are restored to the VMware environment through instant VM recovery and then restored through migration, the job succeeds without having to re-register the VMs in the backup job.

If you look at the log, you can see that the Moref ID has changed.
However, Veeam seems to be automatically performing a full scan and differential block transfer.
Why do VMs after restoring from instant VM recovery are successfully backed up without editing the backup job?
Does anyone know why it works this way?

I thought that any VMs whose Moref IDs had been changed would always need to be removed from the backup job once and added again.
In fact, the VMs restored by "Entire VM Restore" needed to be modified in the backup job.

● Before Restore
====================
[23.10.2020 12:08:48] Info VM name: Linux_2, VM ref: vm-886, VM host name: sm003.sm.domain, source host name: 192.168.33.110, source host id : 4de95db4-adcd-4b11-ad
====================

● After Restore (Not Backup job Editing)
====================
[23.10.2020 15:47:44] Info VM name: Linux_2, VM ref: vm-898, VM host name: sm003.sm.domain, source host name: 192.168.33.110, source host id : 4de95db4-adcd-4b11-ad
====================

By the way, I made a video of the backup job setup and series of operations as shown below and uploaded it to youtube.
※The video is finished in about 5 minutes because I used free software.
Please watch in order from (1).
If you watch this video, you can see that the VM was able to be backed up without editing the backup job.

(1)
https://youtu.be/5h-UguWiPhA

(2)
https://youtu.be/mp9e_bak0BM

(3)
https://youtu.be/wsoKObmgVB4


Kind Regards,
Asahi,
Climb Inc.

[foggy]

Hi Iio, did you do Quick Migration after Instant Recovery? There's a logic that replaces moRef ID in Veeam B&R database after Quick Migration, for the backup jobs to continue normally.

[Asahi]

Hi foggy,

Thank you for reply.

Yes, I ran Instant VM Recovery and then Quick Migration.
That was the answer I was looking for!

So, am I correct in understanding that this is a Veeam specification?

But I'm confused.
Because I contacted Veeam customer support and the Veeam engineers said they don't know why MorefID is being tracked.
Case #04457674

Kind Regards,
Asahi,
Climb Inc.

[HannesK]

that's because foggy has some knowledge that support engineers simply do not have without escalating (you are in tier1 with that case).

Keep in mind that many of the "green" people on the forums work in Veeam R&D since many years and they can ask the actual developer behind any feature

[foggy]

So, am I correct in understanding that this is a Veeam specification?

Yes, this is a by-design behavior.

[Asahi]

Hi HannesK and foggy,

Thank you for reply.
Your kind responses have solved a problem I was having!

By the way, I'm very curious as to why such logic has been implemented in Instant VM Recovery + Quick Migration.
Could you tell me why this logic has been implemented?

Kind Regards,
Asahi,
Climb Inc.

[Andreas Neufert]

There is no API within VMware that allow us to set the moREF ID. When you register a VM at the vCenter (manually or by API), the vCenter give it a new moREF ID.

Depending on if the Veeam job has to register the VM or not, the existing job continue to work.

Example: If you restore a VM to original place and the old VM still exist, we will leverage the existing registration and just change the configuration and data => no new moREF ID and backup job continues to process the VM.

[Gostev]

Could you tell me why this logic has been implemented?

Because it is too easy to forget to update your job to include the "new" VM for customers who don't use container-based jobs, thus ending up without any backups for the given VM.

[Asahi]

Hi,

Thank you for reply.
I'm very happy to see the logic.

By the way, in the future, will I be able to update my MorefID on the Veeam side when I do an "Entire VM Restore" to the original location?

Kind Regards,
Asahi,
Climb Inc.

[foggy]

This is not needed as in case of an in-place restore, Veeam B&R preserves morefID of the original VM.

[soncscy]

These are all good facts to know, but why aren't they documented in any of the user guides? I'm pretty sure I've told my clients dozens of times now to plan maintenance windows they didn't need to and run active fulls needlessly because this information isn't written in the guides that I can find for Veeam.

[Egor Yakovlev]

Hi Harvey

It is impossible to document all the things that "Just Works" in Veeam.
I will pass that question to documentation team and we will see if such information could be added to the guide.

/Thanks!

[soncscy]

Hi Egor,

I appreciate your position here and looking into add this, but I disagree with your statement -- this isn't a minor nuance that just got missed, there are pretty non-trivial implications of not knowing this information.

And from what I can tell, seems like this wasn't even made aware to support either? Someone with direct RND access had to see this topic and comment on it?

Don't get me wrong, I'm not upset that Alexander answered (that's why these forums are really great!), I'm upset that this is really important information on the recovery process that wasn't documented, and I don't think writing it off as "it just works!" is a good response, as I'm sure I'm not the only one who realized that they've needlessly told clients they need to run active fulls, impacting production, when we had a way to avoid this with instant recovery.

We wouldn't have used it in every case, sure, but knowing your options is always best. Please reconsider the viewpoint on properly documenting these procedures; we don't need the secret sauce on how it works, just to know the secret sauce is included.

Neither the instant recovery method or the restore to original location method are documented at all, and I wasn't even aware there __was__ a way to restore without having to run active fulls on the backup afterwards.