Why does a restore want to power off source VM?

[homerjnick]

I ran a backup of a VM...I then copy backup to a NAS...I delete backup from primary backup storage...transport NAS to DR site...re-IP...then add it as a repo to my Veeam B&R server at production site and rescan.

So I now see as Disk (Imported) the backup on my NAS...I then want to restore just one .VMDK from that backup.

It then advises it will power off my source VM...why? Why can't I restore the .VMDK from the backup that is on my DR site without powering off the source VM?

[DGrinev]

Hi Nick,

Please can you clarify which type of restore did you choose?
Also, share your settings for the restore, as it seems like you choose the original location for target destination.

Thanks!

[homerjnick]

I open up the Veeam B&R Console...

I go to Disks (Imported) to see my backup that was copied to the NAS and added to my DR site and then added as a repo.

I right click the backup stored on this NAS under Disks (Imported) and choose "Restore Virtual Disks" and select the virtual disk I want but at this point it advises it will power off Source VM...which is NOT at my DR site but naturally at my production site.

Why? I am restoring from a backup that was dumped to Primary Backup Storage BUT copied (simple windows file copy) to a NAS, and then imported into Veeam B&R when it is at the DR site...the original backup job/data on Primary Backup storage that was the source of the copy to the NAS has been deleted.

It makes no sense to me that the backup on a repo at a different site is asking to power off Source VM when I attempt to restore a VMDK from it.

[homerjnick]

I'm also naturally restoring to my ESXi host at my DR site...

[DGrinev]

Hi Nick,

I discussed your question with the dev team and it seems like an issue on our side, we will address this in the following updates.
Thank you for the valuable feedback!

[tsightler]

I believe this is a small bug in the behavior of the Restore Virtual Disks wizard. Whenever you run this wizard it always selects the original VM as the target and it pops up this message before it gives you the opportunity to pick a different VM where you want to restore the disk. However, if you do pick another VM as the target for the restore, the restore process will not power off the original VM, only the target VM to which you are restoring the disk, so you can safely ignore the message in this case.

Note also that you can choose to restore VMDK files via the the "Restore VM Files" wizard, which is a very different process that doesn't require picking a target VM at all and should not have this artifact.

[homerjnick]

Many thanks for the replies...and info.

I believe this is a small bug in the behavior of the Restore Virtual Disks wizard. Whenever you run this wizard it always selects the original VM as the target and it pops up this message before it gives you the opportunity to pick a different VM where you want to restore the disk. However, if you do pick another VM as the target for the restore, the restore process will not power off the original VM, only the target VM to which you are restoring the disk, so you can safely ignore the message in this case.

Note also that you can choose to restore VMDK files via the the "Restore VM Files" wizard, which is a very different process that doesn't require picking a target VM at all and should not have this artifact.

But that doesn't use a proxy does it? It means I would be restoring from a backup on a NAS at my DR site but going through my B&R server at Production site thus hindering the restore process by traversing the WAN?

[DGrinev]

Hi Nick,

In case you want to run local restore process at the DR site, you should deploy Gateway server there and associate it as a Mount server, then specify the server for the repository as it described in our UG.
Please keep in mind this scenario can be applied only to NAS repository (CIFS share).

Thanks!

[tsightler]

But that doesn't use a proxy does it? It means I would be restoring from a backup on a NAS at my DR site but going through my B&R server at Production site thus hindering the restore process by traversing the WAN?

This is true, but the simple workaround is to install another copy of VBR at the DR site, even if just temporary.

But if you don't want to do this, then using the "Restore virtual disks" option and ignoring the warning about powering off the source VM is the best best. As long as you have properly selected an alternate target VM for the disk restore the warning is superfluous.

[homerjnick]

Many thanks for all the info...I'll proceed with my plan.