Failed to modify disks

[drodecker]

Case #05069755

I attempted to perform a VM backup and restore to Hyper-V with Veeam using simple steps provided here.

This error came up while restoring to Hyper-V from an ESXI backup: Warning Failed to modify disks
Google is showing no exact search results for that error, but indeed this is the exact error message as can be seen in this screenshot.

The newly created Hyper-V attempts to boot, but fails to properly do so: Seems that the VHDX didn't complete it's migration.


Does anyone have knowledge or suggestions as to how to resolve this and allow the newly created Centos 7 VM to boot properly.

Our use case is for local seo services (EDIT by moderator: removed link)

[HannesK]

Hello,
and welcome to the forums.

The link looks like you work with agent backups. In the meantime we also support VMware backups instant recovery to Hyper-V directly. No need to use agents. Maybe that works better.

As for the issue itself: I can only recommend to work with support. It makes little sense to guess on that on a forum.

Best regards,
Hannes

[drodecker]

Thanks HannesK, the VMware backups instant recovery to Hyper-V directly goes quicker now. Nevertheless, the same warning message and outcome.

What's curious is that booting to Recovery mode does produce a working login and the full file system is available and processes seem to run.

IDK what's different in Recovery mode, but presumably I shouldn't be using that for production use.

[HannesK]

I cannot see any of your pictures, but as I mentioned before... I can only recommend investigating with support. It makes no sense guessing that kind of issue on a forum. I know that Linux systems can be very picky when it comes to hardware changes. So probably it's related to a CentOS configuration setting.

[RobinGFT]

Good morning,

Case #05176358

We've ran into the same problem.

We have an external ubuntu server, that is backuped by an agent and mirrored over veeam to our site and we wanted to restore it to a local hyper-v host.
The whole procedure was tested several times and worked every time till now. The last recovery was about was about three month's ago. But now the instant recovery fails. There is a warning in recovery process "failed to modify disks", but restore is going on.
Disks can also be recovered and even the step to migrate them to prodcution state is finishing successfully.
But the new Hyper-V VM won't boot, outputting a message, that grub is failing and can't read from a sector on the disk.

@drodecker Did you find a solution to solve the problem?

Kind regards, Robin.

[RobinGFT]

Case #05176358

Good morning everybody,

In case someone else slides into the same problem:
We've found an solution and maybe the cause of the trouble.
First the solution: Normal, instant restores are simply not working, so we tried to restore using the bare-metal-method.
* Create a bootable medium containing the veeam recovery tool (Download from HP)
* Grab a physical server, that has enough power an space
* Boot from the created medium
* Connect the restore tool to the VEEAM B&R server to load the repo containing the backup
* Restore the point you want
* assign the right volumes: backup <-> physical server
* Check bootloader!!!
* Run the restore.
* There may be errors, in our case the bootloader failed to install and we had to fix it manually
* If so: Boot from Live-Image like ubuntu and install grub to the volume you want
* The server is booting an der there were a few warnings and errors, but the machine runs and everything, we needed was accessible!

Second: The problem
In our opinion the problem is caused by the configured software raid on the backuped machine. VEEAM cannot deal with the subdivision of volumes and how to restore them. This may be a problem of the agent, but it is really not trivial.
In our case the target host we want to backup is rent from ionos (former 1&1) and we have no impact on how this server's raid is configured.

Additional tip from my side: Dump all your databases daily before the backup-job runs, then a granular restore from file level is not a problem

[HannesK]

thanks for posting a solution. I'm just a little bit surprised, that it worked before and then suddenly stopped working.

[RobinGFT]

Case #05176358

Since the last working configuration VEEAM B&R server was updated to v11a and the OS of the server to back up was updated from Ubuntu server 18.04 to 20.04.
Physical server and RAID configuration didn't change and everything on the B&R server and backups seemed to be fine. Granular restore worked, so we trusted veeam, as it never failed before and did not do any deeper tests to proof, that the full restore is also working.
To feel safe is maybe one of the biggest mistakes in current times...

If you need any further information, log files etc., please feel free to contact me. We would be really happy, if the current environment just works again. In the current situation we're not sure to stay with veeam. The restore takes a huge amount of time,ressources and a deep knowlegde for the target system, it's volume architecture and how to flush the bootloader.

Kind regards,
Robin