Thank you

[LimnedMoon]

Hey man,
i want to say thank you so much for this.

I was in Big Trouble for Data-Losses and only got a .vma snapshot as Backup.
With your stuff i got my latest update back and dont lost a wekk of work.

Keep up and thanks again

[JD-Howard]

Also want to say thank you!

I primarily run Linux, but do a fair bit of C# programming over RDP on a Win11 Proxmox VM. I wanted to VirtualBox this VM on a Linux laptop while I was traveling. If not for this script, then I would have some crazy docker configuration or other Proxmox specific tools installed on my daily driver I did not want... I think the only thing I had to install was qemu utils.

Here is my full bash script if anyone wants a reference:

#!/bin/bash
touch ./win11.vdi
rm ./win11.vdi
zstd -d ./win11.vma.zst
rm ./win11.vma.zst
python3 ./vma.py ./win11.vma ./extracted
mv ./extracted/drive-sata0 ./win11.raw
rm -rf ./extracted
rm ./win11.vma
qemu-img convert -f raw -O vdi ./win11.raw ./win11.vdi
rm ./win11.raw

My 250GB ZST took about 20 minute to copy off my NAS backup server onto an NVME with about 1.5TB of space free. The above script does what it can to control the total consumed size through the various stages of the conversion, but that RAW file is the full 500GB I allocated in Proxmox; make sure you have the space available.... The above script running on NVME takes about 40 minutes in total and produced a 441GB VDI file. The 1st boot in VBox takes a while as windows adapts to the new environment, some apps do detect the change in hardware and require a fresh login, but generally works. My Win11 VM was never licensed to begin with so that wasn't an issue for me, but it would be if Microsoft would actually allow that at a reasonable price point...

[marcosandresacevedo]

I am also a C# software dev that depends on a lot of tooling that is primarily on Windows so Proxmox is an integral part of my development environments infrastructure for virtualizing Windows machines and setting up development environments and middleware.

As with many before from what I was able to find people have numerous issues with the way Proxmox implements their approach to virtual machine backups and end up with "corrupted" compressed zst files and inaccessible images from the respective vma files. It was my turn to suffer from one of these unusable backup scenarios.

First I wanted to express my thanks to the author of this script as I was able to perform a raw image extract from a vma file that I proceeded to promptly convert to a VDI with VboxManage. I was able to do this on a Windows 10 system with minimal fuzz by downloading Python embedded and simply running this script. The image converted to VDI booted without issue on a newly minted VirtualBox VM with the converted VDI attached as a SATA primary boot drive (though it was setup initially as VirtIO SCSI in Proxmox).

For anyone that finds themselves reading this and is facing the same issues here the scenario and what I did:

• Windows 10 virtual machine in Proxmox 7.4-3 was rendered unusable due to zfs corruption (what else is new).
• I kept my backups in an NFS share powered by Unraid in a separate machine. Proxmox had performed a backup of this machine seemingly without errors previously as per its logs.
• I deployed a second Proxmox 8.4-1 install in a separate machine to attempt this backup as I wasn't gonna use the Proxmox host with the current zfs degradation to perform any of this work.
• I quickly ran in to issues with Proxmox being unable to uncompres the zst file due to "error (36) : Restored data doesn't match checksum".
• Besides the cursory searches leading me to many people having the same issue there were some people having success in extracting the archive and restoring the machine from the extracted vma file despite errors. Most tooling I tried that uncompressed zst files delete the extracted vma on checksum error but I saw an unrelated post recommending this version of 7zip with zstd support.
• Using that version of 7zip I was able to extract the vma file from the zstd. It still returned an error when it was finished but it didn't delete the vma file.
• I attempted to restore the extracted vma file to the Proxmox install but it ended with an error: vma: restore failed - short vma extent (17054 < 131584).
• Back to research again I ran in to posts from people suggesting that it could be possible to extract the raw disk image from the vma file using the vma extract command with the binary available on the Proxmox machine. However this once again leads to a scenario where it will throw an error and delete the extracted config file and raw images if it believes that there is a problem with the archived files.
• Continuing the search led me to this post and this repository.
• I didn't want to bother the Windows installation with a full python install so I just grabbed the embedded release and unzipped it to a folder and put vma.py there as well.
• Ran .\python.exe vma.py .\vzdump-qemu.vma .\extract\ from a Power Shell prompt.
• I was greeted with a raw "drive-scsi0" file with a size matching what was provisioned for the virtual machine disk originally from Proxmox (384GB) and no errors.
• The next step was to simply run: & 'C:\Program Files\Oracle\VirtualBox\VBoxManage.exe' convertfromraw .\drive-scsi0 .\drive.vdi from the Power Shell prompt inside the extract directory that was created when extracting the files form the vma with this python script.
• VboxManage successfully converted the raw disk image to a thinly provisioned vdi, saving disk space as I was already eating up my 2TB NVMe drive doing all this work.
• Created a new Windows 10 virtual machine on Virtual Box and attached the vdi as its primary drive.
• The Windows 10 virtual machine backup booted successfully after booting with a "Getting things ready" loading screen and rebooting itself immediately, presumably for Windows to reconfigure itself to the hardware change of going form a qemu/kvm q35 machine to a VirtualBox PIIX3.

I am aware that this does not mean that in all instances of a corrupt Proxmox backup it means that this process will result in a non corrupt bootable disk image. But it seems that the area where Proxmox has catastrophically failed is in how they implement the all critical backup process. However this is not the place to air such complaints so I'll leave it there.

Thank you for making this script that became a critical tool in my data recovery process.