Hello, Proxmox community!
I want to share my experience and a solution for a backup restore issue that might be helpful for other users who are upgrading to Proxmox VE 9.x.
**The Problem:**
After upgrading one of my hosts to **Proxmox VE 9.0.5**, I was unable to restore a VM backup (in `.vma.gz` format) that was created on another host. However, the exact same backup file **restored successfully** on a host running **Proxmox VE 8.4.11**.
**Symptoms:**
When attempting to restore on PVE 9.0.5, the process would reach about 74% and then fail with the following error:
vma: restore failed - wrong vma extent header chechsum
...
TASK ERROR: command '... | vma extract...' failed: exit code 133
This indicated that the issue was not with the backup file itself (since it was valid on PVE 8), but likely a regression or incompatibility in the `vma extract` utility in the new version, especially when handling piped/streamed data.
**The Solution (Workaround):**
After some experimenting, I found a 100% working method to successfully restore the VM on the new PVE 9.0.5 host. The solution is to separate the process into two stages, using the strengths of both Proxmox versions:
**Stage 1: Decompress the archive on the working system (Proxmox VE 8.4.11)**
On the host where the restore works correctly, I performed a manual decompression of the `.gz` archive into an uncompressed `.vma` file. I used the `gunzip` command and redirected the output to a new file:
```bash
# Create a temporary directory on storage
mkdir -p /mnt/pve/NFS/temp_restore
# Decompress the archive
gunzip -c /path/to/backup/vzdump-qemu-VMID-DATE.vma.gz > /mnt/pve/NFS/temp_restore/vzdump-qemu-VMID-DATE.vma
Important Note: I immediately named the uncompressed file using the standard vzdump format, because qmrestore can fail to recognize files with custom names.
Stage 2: Restore from the uncompressed file on the target system (Proxmox VE 9.0.5)Now, with a "clean" and verified .vma file, I initiated the restore process on the new PVE 9.0.5 host, using this uncompressed file as the source:
Bash
qmrestore /mnt/pve/NFS/temp_restore/vzdump-qemu-VMID-DATE.vma <NEW_VMID> --storage local-lvm
The restore process from the uncompressed file completed successfully without any errors.
Conclusion:
This experience strongly suggests that the problem is likely a software bug in PVE 9.0.5 related to handling the streamed restoration of compressed archives created on previous versions.
I hope this method helps other users who encounter a similar situation, and perhaps it will bring the potential bug to the attention of the developers.
Thank you for your time!
I want to share my experience and a solution for a backup restore issue that might be helpful for other users who are upgrading to Proxmox VE 9.x.
**The Problem:**
After upgrading one of my hosts to **Proxmox VE 9.0.5**, I was unable to restore a VM backup (in `.vma.gz` format) that was created on another host. However, the exact same backup file **restored successfully** on a host running **Proxmox VE 8.4.11**.
**Symptoms:**
When attempting to restore on PVE 9.0.5, the process would reach about 74% and then fail with the following error:
vma: restore failed - wrong vma extent header chechsum
...
TASK ERROR: command '... | vma extract...' failed: exit code 133
This indicated that the issue was not with the backup file itself (since it was valid on PVE 8), but likely a regression or incompatibility in the `vma extract` utility in the new version, especially when handling piped/streamed data.
**The Solution (Workaround):**
After some experimenting, I found a 100% working method to successfully restore the VM on the new PVE 9.0.5 host. The solution is to separate the process into two stages, using the strengths of both Proxmox versions:
**Stage 1: Decompress the archive on the working system (Proxmox VE 8.4.11)**
On the host where the restore works correctly, I performed a manual decompression of the `.gz` archive into an uncompressed `.vma` file. I used the `gunzip` command and redirected the output to a new file:
```bash
# Create a temporary directory on storage
mkdir -p /mnt/pve/NFS/temp_restore
# Decompress the archive
gunzip -c /path/to/backup/vzdump-qemu-VMID-DATE.vma.gz > /mnt/pve/NFS/temp_restore/vzdump-qemu-VMID-DATE.vma
Important Note: I immediately named the uncompressed file using the standard vzdump format, because qmrestore can fail to recognize files with custom names.
Stage 2: Restore from the uncompressed file on the target system (Proxmox VE 9.0.5)Now, with a "clean" and verified .vma file, I initiated the restore process on the new PVE 9.0.5 host, using this uncompressed file as the source:
Bash
qmrestore /mnt/pve/NFS/temp_restore/vzdump-qemu-VMID-DATE.vma <NEW_VMID> --storage local-lvm
The restore process from the uncompressed file completed successfully without any errors.
Conclusion:
This experience strongly suggests that the problem is likely a software bug in PVE 9.0.5 related to handling the streamed restoration of compressed archives created on previous versions.
I hope this method helps other users who encounter a similar situation, and perhaps it will bring the potential bug to the attention of the developers.
Thank you for your time!