Assemble NTFS vhd fails

wildpygmy · March 2, 2025, 7:33pm

I’m in a major bind trying to figure out how to restore an an image backup. I’m running urbackup in a docker on my unraid server, which backups a Windows 11 client on my network. In the process of trying to fix various issues, I think I’ve corrupted my urbackup database (even though I tried restoring it from the backup it saves). As a result (I think), when I try to use the bootable recovery usb, even though it lists my backups, when I try to start a restore I get messages “Loading MBR failed: Error reading image size from server” and “MBR info not found. Cannot restore to partition”.

That said, I still have all my backup vhdz files. As an alternative I was trying to assemble a .vhd to try restoring with another program. However when I run the following command (from shell within the docker)

urbackupsrv assemble -a /media/5600x-Dsktp/250217-0203_Image_SYSVOL/Image_SYSVOL_250217-0203.vhdz -a /media/5600x-Dsktp/250217-0204_Image_C/Image_C_250217-0204.vhdz -a /media/5600x-Dsktp/250217-0204_Image_ESP/Image_ESP_250217-0204.vhdz -o /media/VHD/250127.vhd

I get the following output:

2025-03-02 14:21:08: Clustersize: 4096
2025-03-02 14:21:08: ClustersPerMFTNode Offset: 48
2025-03-02 14:21:08: MFTStart: 72448
2025-03-02 14:21:08: Attribute Type: 16 nonresident=0 length=96
2025-03-02 14:21:08: Filename=$MFT
2025-03-02 14:21:08: Attribute Type: 48 nonresident=0 length=104
2025-03-02 14:21:08: Attribute Type: 128 nonresident=1 length=72
2025-03-02 14:21:08: Attribute Type: 16 nonresident=0 length=96
2025-03-02 14:21:08: Filename=$Bitmap
2025-03-02 14:21:08: Attribute Type: 48 nonresident=0 length=104
2025-03-02 14:21:08: Attribute Type: 128 nonresident=1 length=72
2025-03-02 14:21:08: Bitmap size=27168
2025-03-02 14:21:08: VHD-Parent: "/media/5600x-Dsktp/250120-0251_Image_C/Image_C_250120-0251.vhdz"
2025-03-02 14:21:08: Sectorsize: 512
2025-03-02 14:21:08: Clustersize: 4096
2025-03-02 14:21:08: ClustersPerMFTNode Offset: 48
2025-03-02 14:21:08: MFTStart: 125278833
2025-03-02 14:21:08: Attribute Type: 16 nonresident=0 length=96
2025-03-02 14:21:08: Filename=$MFT
2025-03-02 14:21:08: Attribute Type: 48 nonresident=0 length=104
2025-03-02 14:21:08: Attribute Type: 128 nonresident=1 length=96
2025-03-02 14:21:08: Attribute Type: 16 nonresident=0 length=96
2025-03-02 14:21:08: Filename=$Bitmap
2025-03-02 14:21:08: Attribute Type: 48 nonresident=0 length=104
2025-03-02 14:21:08: Attribute Type: 128 nonresident=1 length=72
2025-03-02 14:21:08: Bitmap size=31195616
2025-03-02 14:21:08: ERROR: NTFS magic wrong
2025-03-02 14:21:08: WARNING: Volume  not an NTFS volume. Copying all blocks...
2025-03-02 14:21:08: ERROR: Footer checksum wrong. Switching to header
2025-03-02 14:21:09: Writing GPT header...
Segmentation fault

This happens no matter which image I try to assemble (I’ve tried several older ones). I’m not totally sure if I’m supposed to be including the ESP vhdz in the assemble, but even assembling just the C drive also produces a seg fault.

I do think that the image itself is okay, as I am able to mount it using urbackupsrv mount-vhd (after running my docker in privileged mode) and browse the files from the docker shell.

I’ve seen a couple other posts with similar issues assembling NTFS vhdz files, but they have no responses.

I’m pretty desperate here. If assembling a VHDZ isn’t going to work, is there anything else I can try to get this image restored to my drive? I had been nervous about using the cleanup or remove-unknown commands for fear they will wipe my actual image backups, though I am in the process of backing up the images and then going to try that. I have already tried running repair-database and defrag-database but they both result in various errors (happy to reply with those if needed).

Any suggestions towards the ultimate goal of restoring a image to my Windows 11 machine are much appreciated!

wildpygmy · March 2, 2025, 8:30pm

UPDATE: As one last hail mary I tried running the Urbackup Recovery USB with the official Urbackup docker running rather than the binhex version I had been primarily using. I have no idea why, but this allowed my restore to start properly (I had already restored my backup of the urbackup databse files to the official docker). Fingers crossed the reimaging is sucessful and I have no issues rebooting my computer when it’s done. My only guess is I screwed something up with permissions/users settings of config files in the binhex version while trying to troubleshoot, and my level of Linux knowledge is very low.

That said, I had previously tried using the assemble command in the official docker, and it throws the same errors described above, so the issue about assembling VHDs remains an open question.

Basically if I’m going to continue using Urbackup as an image based backup solution going forward, I want to ensure that I have some way of accessing disk images to pull particular files without doing a full re-imaging of my drive. As of now I have no good way of doing this. In the binhex docker, the “mount image” in the webui fails (see several commenters on the unraid forum discussing the permission denied accessing the content0 dir) , and in the official docker, the mount button isn’t even present. And as discussed I’ve been unsuccessful assembling a vhd file to mount manually. So any other recommended solutions/options?

uroni · March 2, 2025, 8:35pm

Here is how to restore via command line:

https://urbackup.atlassian.net/wiki/spaces/US/pages/2981890/How+to+restore+via+command+line

You can also uncompress the vhd, then it is a standard VHD file an can be opened/mounted with tools that can read this format. The volume starts at 512KB offset.

wildpygmy · March 3, 2025, 9:46pm

Thanks for response, but I’m still having issues trying to mount a vhd file. I tried 2 things.

I ran the assemble command in the original post. It results in a seg fault.
I also tried decompressing a vhdz image using the urbackup decompress-file command. That processed, and my understanding is that it doesn’t change the file extension. So after decompression I tried manually changing the file extension to .vhd, and mounting it in windows (tried a few different ways including using Disk Management and ImDisk) . This either fails with an error (in the case of Disk Management) or mounts a disk that asks me to format it when I click on it (ImDisk).

Am I doing something incorrectly with either of these steps? If not, any idea what the issue is here?