I have Windows10 backup set to do weekly full images (not files) of the C: drive. From the backup & restore center, everything looks fine. The images are held on an auxiliary hard drive independent from the primary SSD. No encryption or other unusual attributes.
The "WindowsImageBackup" directory on the aux drive has a "Backup 2018-04-28" directory with two
.vhdx files, one 432MB and one 78GB, that must map to two of the three partitions Windows creates on the boot drive.
I started having some stability problems so decided to go back two weeks to when it was working fine.
I shut down and rebooted from the original install USB media. It showed me the latest image being two weeks ago (which was odd, but okay). I selected it and let it go. After about 1 minute, I got a dialog saying that the restore had been cancelled with a "close" button on the dialog. No other information was available.
I tried again. Now, a moment after the restore has started, I get the following:
The system image restore failed. Error details: The volume does not contain a recognized file system. Please make sure that all required file system drivers are loaded and that the volume is not corrupted. (0x800703ED)
Now what? I can't boot the computer. The only option looks to be to reinstall completely which would be a major pain.
Perhaps I can unplug the auxiliary drive, do a full install, and then reconnect to restore the backup image?
I opened the command-line and used
diskpart to "clean" the C: disk. I rebooted and again tried to restore the image. This time I got a different error:
The system image restore failed. Error details: The computer needs to be restarted to finish preparing a hard disk for restore. To continue, restart your computer and run the restore again. (0x80042403)
I did that. On the next run, I get:
The system image restore failed. An error occurred while performing the recovery operation. _Details_
The "details" link says:
No disk that can be used for recovering the system disk can be found. Try the following: 1) A probable system disk may have been excluded by mistake. 2) A USB disk may have been assigned as a system disk. 3) An invalid disk may have been assigned as system disk. (0x80042412)
1) I excluded everything but the one disk I wanted to recover. I was very careful. 2) It's not a USB disk. 3) It was previously the system disk.
diskpart (via the command-line) doesn't show any modifications to "Disk 2" which is the primary boot drive. It's actually an M.2 SSD and I can't change it's drive number except by disconnecting the other physical drives.
After doing a fresh install of Windows10, I thought I'd try again to restore the image. This time I created a "live" Linux USB boot to better track what is going on. I also used
dd to make an image of the recent install so I can at least go back to that any time I want .
The image restore failed in exactly the same way saying "No disk that can be used for recovering the system disk can be found."
Booting into the Linux image, I find all the partitions exactly as they were so clearly the restore process didn't even get so far as to format the drive.
Sure enough, booting from the HD brought be back into the existing install of Windows.
There are three partitions on the boot drive (a 500GB NVME SSD) ...
- 499MB "Recovery Partition"
- 100MB "EFI System Partition"
- 293GB "Boot, Page File, Crash Dump, Primary Partition"
- 172GB "Unallocated"
... but only two .vhdx files in the backup. Perhaps there some manual way to extract one of those into the main partition?
.vhdx file... Once I went through the steps to take ownership of them, I can mount them! Using "Computer Management" (
This PC >
Manage), I can go to "Disk Management" and then Action::Attach VHD to mount the image. Everything appears to be there! (Note that right-clicking on the .vhdx file and selecting "Mount" does not work.)
Now... How do I transfer its contents to the real disk partition?
I found steps on how to restore a .vhd file but since I had a .vhdx file, they wouldn't work. All the instructions I could find to convert them required Hyper-V which is not available for Windows-10 "Home" edition.
I found the Disk2vhd utility by Microsoft but it sadly will read only from physical disks and not mounted .vhdx files.
Leaving Windows makes for more options, though, and I eventually came across
qemu-img for doing conversions like this. Specifically:
qemu-img convert -p -f vhdx -O raw /foo/hexdigits-backup-file.vhdx /bar/c3.raw
With spinning disks, you'll usually get a faster conversion if you can have the input and output on different physical devices. I decided that I only needed to convert the main partition (partition 3) as the others were probably fine from the new install.
Finally, copy it as root:
sudo dd if=/bar/c3.raw of=/dev/nvme0n1p3 bs=1M
You can add "status=progress" if your
dd is new enough to support it. Or you can do
sudo killall -USR1 dd from another shell to get older versions to spit out their status.
All that was left was to cross my fingers and reboot...
Windows started and said "Reparing..." but eventually failed saying that repair was not possible.
At this point I tried the solution offered by harrymc below... It wouldn't work either as PowerShell couldn't convert the .vhdx file into a .wim file. Who knows, perhaps the backup was just damaged (though
qeum-img didn't complain).
There were other things I could try but it was taking too much time. I gave up. I didn't ever restore the backup made with
dd. I installed Windows10 from scratch (yet again) and did all my configuration one more time. I mounted the .vhdx file as a drive ...
- From Windows File Explorer, right-click on the top-level
This PC(or whatever it has been renamed to) and select "Manage".
- From the
Attach VHD. Find your .vhdx file and select it. Use read-only mode to be safe.
- Again with File Explorer, locate the Drive: under which it has been mounted. Verify that it looks good and try to open a file or two.
... and copied over all the non-OS files plus things from
ProgramData that seemed appropriate.
In the end, I had to re-do all the configuration and reinstall all the software but at least I didn't lose any data.
The new install still has Windows system image backup enabled but I don't have any trust in it so I'm also using AOMEI Backupper (free edition for now) to regularly create images on another drive, UrBackup to regularly create a disk image over the network to another machine, and
dd (via Linux live USB) to occasionally create a full raw image of the drive.
Next time I have a problem, I'm hoping at least one of these methods will allow a successful restore.