I running Urbackup at my Homelab, in docker. My OS Windows disk passed way and i bought a replacement. When I tried to restore the image backup, using UrBackup Image Restore, i got some errors in MBR(see screenshot).
My former disk is a Netac NVME 512gb Gen3. The replacement is a Fanxiang NVME 500gb Gen4. So, the former disk is a little bigger than the new one. But the entire OS is occupying least of 50% of the disk. So, was needed to use a spill disk because of the difference of disk sizes. The restore process completes, even considering the MBR write error. But, after the reboot, the restored disk can’t boot Windows 11. The disk not even appears on BIOS boot priority. Someone could help me?
I have never done img backups, but I am a bit knoledagble in general filesystems and such.
I can tell you this.
MBR is the old partition table used in f ex fat32, and that is what your boot partition has, both on windows and linux.
GPT is the “newer” table used for more or less all other filesystems, in your case NTFS (I would assume).
The img might simply be corrupt, I can not help you figure out if that is the case or not.
Hopefully someone else on this forum can help you with that.
As far as I know, an image backup cannot be restored to any drive that is smaller than the original.
It is an image of the entire drive, all 512 MB regardless of what amount of data was on the partition.
There is no way that it can be restored to a 500MB drive.
One alternative is to find some way to mount the image and use windows disk manager (if windows image) to shrink the partition to under 500MB then convert the shrunk, mounted drive back to an image that can be restored to the smaller drive. There are also numerous live linux tools that can mount, then shrink, then re-image a partition.
The second issue is the GPT header on your new 500MB drive.
You will have to use a linux live partition manipulation tool to write zeros to the first 1024 bytes of the new drive to remove any trace of GPT.
If you don’t, nothing will be able to write an MBR image to that drive.
There must be no trace of the GPT header remaining on the new drive.
