Restore from physical host to VM or from host to a different host help

Rex2020 · September 29, 2026, 8:18pm

I’ve tried many image restores from urbackup to proxmox, virtualbox and hyper-v with the urbackup restore disk and starting with windows 10 and 11 most if not all of them will not boot and the boot can’t be repaired with the standard windows recovery process.

I’ve found a new way using disk2vhd from Microsoft and it works really well. Whatever it does when it creates the image, the host starts up and is able to find the boot hardware changes and fix what’s ever needed to let windows boot up. Short term i’ll script this and do a file level backup with urbackup, but it would be awesome if the image prep process disk2vhd uses could be incorporated into urbackup image backup.

PS love the tool, it’s just the imaging functionality has become a less useful sync image restores often happen to VM or a new host with different hardware.

LJ_LongWing · September 29, 2026, 9:25pm

The usual culprit with Windows 10/11 is the storage driver. Windows only enables the storage driver it booted with last, so a machine that ran from NVMe has the SATA/AHCI driver (storahci) disabled. In a VM with a SATA or VirtIO disk it then fails with INACCESSIBLE_BOOT_DEVICE, which Startup Repair usually can’t fix.

Things that usually help:

Before the backup, set Start to 0 for storahci and stornvme under HKLM\SYSTEM\CurrentControlSet\Services. The restored system can then boot from either controller type.
After restoring, boot into Safe Mode once. That enables all boot drivers. From the recovery command prompt: bcdedit /set {default} safeboot minimal, reboot, then bcdedit /deletevalue {default} safeboot.
Match the firmware to the original: UEFI (OVMF in Proxmox, Generation 2 in Hyper-V, “Enable EFI” in VirtualBox) for GPT disks, BIOS for MBR.
On Proxmox, use a SATA disk for the first boot. Windows has no VirtIO driver unless virtio-win was installed beforehand.

I agree an option on the restore CD to prepare the restored Windows for different hardware would be really useful.

uroni · October 3, 2026, 7:54pm

For this the restore cd had fixes in the past ( urbackup_backend/restore_cd/driver_edit.py at dev · uroni/urbackup_backend · GitHub ) . I just thought this would not be necessary for Windows 11 anymore. If it is may be worth re-enabling.

Rex2020 · October 6, 2026, 7:33pm

Thanks I will try the above. Does anyone know what triggers that driver_edit.py script noted above to run and updated the registry on the restored image? I was looking in the latest restore GUI and can’t seem to find the “run on different hardware” option. Is the script run automatically all the time during a restore or is it only available via the none GUI restore option?

sonic9 · October 7, 2026, 8:02pm

“StartOverride” to always enabled AHCI/SATA and NVMe
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\stornvme\StartOverride]
“0”=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\storahci\StartOverride]
“0”=dword:00000000

uroni · October 7, 2026, 8:09pm

If there is confirmation that this helps, it will be worth adding to the graphical restore.

The script also needs to be extended by NVMe.

LJ_LongWing · October 11, 2026, 2:31pm

To answer the question about what triggers it: the script only runs from the text-mode restore. After an image restore finishes, the menu there has an entry “Make Windows bootable on different hardware”, and that runs it on the restored Windows partition. The graphical restore has no equivalent, so it never runs there.

It also wouldn’t help with Windows 10/11 as it is. It sets Start to 0 for atapi, intelide, pciide, msahci and iastorv. msahci is the Windows 7 name; since Windows 8 the driver is storahci, and stornvme isn’t in the list at all.

If you can confirm that the Start / StartOverride change gets your restored machines booting, I can extend the script with storahci and stornvme and send it as a PR.

LJ_LongWing · October 12, 2026, 2:26am

I’ve sent the extension of the script as a pull request:

github.com/uroni/urbackup_backend

Restore: boot drivers for AHCI and NVMe on Windows 8 and later (#171)

2.6.x ← ljlongwing:restore-driver-edit-nvme

opened 02:23AM - 12 Oct 26 UTC

ljlongwing

+51 -28

This is the extension of `restore_cd/driver_edit.py` from the forum thread about… restoring to different hardware (17111), where you wrote that the script needs NVMe. The script behind "Make Windows bootable on different hardware" sets the disk controller drivers of Windows 7 to start at boot: `atapi`, `intelide`, `pciide`, `msahci`, `iastorv`. Two things are missing for Windows 8 and later: - The AHCI driver is `storahci` since Windows 8 (`msahci` before), and NVMe disks need `stornvme`. Both are added to the list. - A driver that was not needed to boot on the old hardware has a `StartOverride` subkey with a value `0` = 3. That keeps it from starting at boot even if `Start` is 0, which is the usual state of `storahci` on a machine that booted from NVMe and the other way round. The script now sets these values to 0 for the drivers in the list. This is the change sonic9 described in the thread. The driver handling is in a function now, so it only reads the keys of the drivers in the list instead of every service. **Testing:** with `chntpw` on a registry hive I made for this, with drivers in the different states (`Start` 0/3/4, with and without `StartOverride`, a non-driver service, a driver not in the list): the right values change, the others are untouched, and a second run changes nothing. I have not restored a Windows installation to other hardware with it, and nobody in the thread has confirmed the `StartOverride` change on their machines yet. The graphical restore still has no entry that runs the script; this only changes what the text mode restore does.

“Make Windows bootable on different hardware” in the text-mode restore now also

enables storahci and stornvme, and sets their StartOverride to 0, which is the

change sonic9 posted above.

I could only test it on a registry hive I made for the purpose, not by booting a restored Windows. If one of you can try it on a real restore to different hardware, that would tell us whether it is enough.

Rex2020 · October 12, 2026, 7:52pm

Any idea on syntax to call the script manually. The command screen UI does not seem to work for me with errors on disk being protective / corrupt GPT on restore target. I see the script in /root and can run your version after restoring with the GUI.

LJ_LongWing · October 12, 2026, 8:11pm

It takes the restored Windows partition as its only argument, and has to be run from the directory it is in, because it loads regedit_linux.py from there. In a terminal on the restore CD:

sudo -i
cd /root
python3 driver_edit.py /dev/sda3

Use the NTFS partition that has the Windows folder, not the EFI or recovery partition. “lsblk -f” lists them; on an NVMe disk it is something like /dev/nvme0n1p3.

The driver_edit.py on the restore CD is the old one, so replace it with the one from the pull request first (after the cd /root):

wget -O driver_edit.py https://raw.githubusercontent.com/ljlongwing/urbackup_backend/restore-driver-edit-nvme/restore_cd/driver_edit.py

It prints each driver it enables, or “No driver needed to be enabled. Changed nothing.” If it stops with “File exists”, an earlier run left /media/tmp_driver_edit behind; remove that directory and run it again.

About the GPT errors: the text-mode restore writes the saved partition table to the new disk and then lets gdisk repair it. You only see gdisk’s messages if the backup GPT could not be written where it was on the old disk, or if the partition did not show up afterwards. Is the target disk smaller than the original? And what is the last message before it stops?