RestoreVM failed with secondary HD lost

[webstyler]

Hello to all

I test restoreVM of linux centos VM an this failed

Scenario
VM linux centos 2 HD :1 + 1 (backup disk)
Veeam job backup only system disk (1)
RestoreVM failed with "nameVm.vmx" not found

>> Job work ONLY if we check "Remove excluded disks from VM configuration"

But, in this case when start VM machine on host filesystem need to be modify for lost disk or add and remount.. too operations for fix critical restoration

Any solutions to fix first issue and to plain linear restoration without manually modify ??

Thanks

[Vitaliy S.]

>> Job work ONLY if we check "Remove excluded disks from VM configuration"

Since you've excluded VM disk from a backup job, you need to enable this checkbox to remove a corresponding disk entry from VMX file to be able to boot this VM.

However the message below shouldn't prevent restore job from finishing successfully:

RestoreVM failed with "nameVm.vmx" not found

Please open a support case to investigate it further.

[webstyler]

Since you've excluded VM disk from a backup job, you need to enable this checkbox to remove a corresponding disk entry from VMX file to be able to boot this VM.

Please note that error is NOT on vsphere but on VEEAM and not on boot but on veeam restorevm job

However the message below shouldn't prevent restore job from finishing successfully: Please open a support case to investigate it further.

Job failed, we have already open support case but nothing solved at this time

[webstyler]

[merged]

So

VM vmware with 2 HD
Need to backup only first HD and Need a solution for fast and sure

So made backup job and "Remove excluded disks from VM configuration" (it not you give and error during restore from veeam server)

Now, if you made restore this work BUT when start VM Linux stopped because lost 1 disk, so you need enter in maintenance mode and remove secondary HD or edit VM configuration and add new HD.

If you think this on server with a lot of VM is not a possible way

Other solutions ?

Thanks

[dellock6]

Hi,
the flag for reconfiguring the .vmx file keep the consistency of the VM, but this of course does not work at a guest OS level. If that disk is declared in the fstab of the linux VM, the only other option I can think is setting noauto in the fstab, but this would make the server mot mounting the disks even when attached; unless you use a startup script that check for existing disks and mount it, when they are attached.

Best thing, for me, is to backup all the production disk installed in a VM.

[webstyler]

Hello Luca

About the flag: the error during restore is on VEEAM side and not on vSphere side, but we have open ticket for resolve this..

We have secondary HD used for hosting panel backup, so wouldn't backup 2 times
If master HD change any night any GB the secondary HD change any night many GB because any backup customer file change..

Simon

[dellock6]

Ok, I see.
Well, excluding disk in Veeam is working here and in many of my customers, so you were right in opening a ticket.

[webstyler]

About a rapid restore would be interesting to have a copy of secondary HD, also empty, to keep on backup storage ..

When I set a veeam job backup and set to made backup of primary HD but NOT of secondary, without remove from VM setting, I trhought it was handled +/- in this way..

[spgsit5upport]

Same issue here

Full backup exists, yet I can NOT restore it.

Backup was created with selected disk 1 & disk 2 ONLY (disk 1 = 1Gb, disk 2 = 8Gb)
This VM has also RDM disk, which is NOT being backed up

Restore fails:

The empty vmdk get created, but nothing gets restored!

Had to use extract (how good of you to provide it!) to get the VM structure back, copy it to LUN, register by hand

Seb

[Vitaliy S.]

Seb, please avoid posting log snippets as it is described when you click New Topic. Instead, please provide the complete log package to our support, since we would definitely like to investigate why restore failed for this backup when extract.exe worked (which means that the backup itself is fine).

Also, please include your support case number in this topic for our future reference.

Thanks!

[spgsit5upport]

I did not bother to open the case, it would take longer then to just do it the ay I done it.

But there is obviously a bug in the software which should be fixed

Seb

[robertson_scott]

I know this is an old thread, but it seems to be the same issue that I've just encountered (and worked though with support)...

We have the situation in our environments where servers often have a "C:\" disk in the order of 30-60GB (which holds the O/S, program files, etc) and a "D:\" disk in the order if 1-2TB (holding some form of user data). We rely on Veeam to backup the C:\ disks, but for various performance, space and technical reasons, we manage the backing of the larger "user data" disks via other methods.

When I try to restore a machine backed up with this configuration (noting that I am not removing the excluded disk from the VM configuration when doing the backup), it fails (with a RestoreVM failed with "nameVm.vmx" not found message).

The advice from support was to "You can do a restore VM files, then download the .vmx file, remove that disk from the file, save it, and re-upload it". The work around I am using is along those lines (but simpler): I restore the files to the ESXi host, and then I register the VM (which I can do, despite the missing disk still being referred to in the .vmx file).

In order to start the VM, I'll then need to:
a. Add the missing disk, or
b. Remove the missing disk from the configuration
...depending on my needs, I'll chose one of those 2 options, but either way, I can get the machine running.

My point in all of this is that if I can restore the files from the backup and then manually register the VM in ESXi using the .vmx file, why isn't Veeam doing this for me?

This issue was raised in support case 00607480 - the feedback I got was essentially that Veeam is operating correctly and I should use the approach I mentioned above. But to me, that's a poor work around - Veeam has, in my opinion, failed to restore a sever that it successfully backed up (and hence should be able to restore).

I'm posting this here to open it up to discussion and see if a change in the design of Veeam in this area may be warranted...

[veremin]

noting that I am not removing the excluded disk from the VM configuration when doing the backup

May I ask you why you don't do so? Once the corresponding option is enabled, you should have zero problems during restore. Thanks.

[robertson_scott]

The main reason is that I want to know that a disk has been removed from the VM (without having the guess/remember that is has or guess/remember what size it was).

[foggy]

I may not follow you here, but isn't this check box exactly what you need to be sure the disk has been removed from the backed up VM config?

[tsightler]

I think he's saying that he wants the disk excluded from backup, but during restore he would like it to be obvious that this VM did depend on another disk that was not part of the backup, rather than simply failing to restore. Using the "remove disk from VM configuration" makes it appear that this is the entire and complete VM, which isn't the case. I've actually run across this request multiple times, as it's very confusing to the end user when the VM restore fails. Perhaps a better would be to note during restore that the VM has 3 disk, but only two are part of the backup, and allow the user the either select the existing disk to use for the ones not contained in the backup, to create an "empty" version of this disk, or to simply remove/ignore that disk during restore, rather than removing it during backup itself. That way the user would have a complete picture of that VM. Might be too complicated but it really is confusing.

[foggy]

Ah, makes perfect sense this way, thanks, Tom.

[robertson_scott]

I think he's saying that he wants the disk excluded from backup, but during restore he would like it to be obvious that this VM did depend on another disk that was not part of the backup, rather than simply failing to restore

That's exactly what I'm saying - nicely put...