Issues with checksum on Newly installed OS servers

Currently we are setting up the server room in our department and needed to set up a new backup server. So far everything is fine and easy to set up, until we go to verify the backups. Currently we’re just testing using the backup server and our MDT/WSUS server (both running windows server 2019. When attempting to reassemble the VHD using the assemble_disk_image.bat, it fails the footer and header checksum checks and exits like so:

image

Text version:
2023-06-15 16:33:54: ERROR: Footer checksum wrong. Switching to header
2023-06-15 16:33:54: ERROR: Header and footer checksum wrong
2023-06-15 16:33:54: ERROR: Error opening VHD-File “D:\UrBackup Backups\Mnemosyne\230615-1627_Image_C\Image_C_230615-1627.vhdx”
Press any key to continue . . .

I’ve tried changing the type of backup between the four options (vhdz, vhd, vhdxz, vhdx) and switching from #1 to full synthetic while going through the four options. I’m really at a loss and about to switch off URBackup, but wanted to make sure I’m not doing something stupid. I have tried doing a fresh install on both servers. The only thing I could think of is some network issue, but we just redid the entire rack and verified all the connections and the “Error opening VHD-File” leads me to believe its something wrong with the software.

Any help would be appreciated. It will unfortunately take me some time to respond as its the end of the workday here but I will check and respond as soon as I can. Thanks!

Seems it doesn’t switch over to the VHDX handling code and tries to read it as VHD. Sry, this is a bit of a neglected corner (assemble disk images) – will be fixed.

What kind of use cases do you have in mind for the disk image assembling?

We found this issue while wanting to test the backups using our Hyper-V server. Unfortunately, it’s not just with VHDX as the assembly fails regardless of if the backup is VHD, VHDZ, VHDX or VHDXZ. The fact it was failing on all four is what made me assume I was doing something wrong

Sadly it’s still not fixed … the offerd trial and commercial version are still “2.5.21-hyperv beta” over 8 months after this found essential bug