proxmox zst backup format can't be restored from gui

[dengolius]

May 12 09:46:40 pxtool pvedaemon[1250]: <root@pam> starting task UPID:pxtool:000033D2:0283B39B:5EBA5460:qmrestore:100:root@pam:

May 12 09:46:40 pxtool pvedaemon[13266]: ERROR: couldn't determine format and compression type

May 12 09:46:40 pxtool pvedaemon[1250]: <root@pam> end task UPID:pxtool:000033D2:0283B39B:5EBA5460:qmrestore:100:root@pam: ERROR: couldn't determine format and compression type

So how to restore from .zst fortmat like it was done for .lzo and .gzip? Maybe I missed something in DOCS ? But I don't see any info from google search, only as feature request on Proxmox forum.

 

[fabian]

your backups don't follow the expected naming scheme, hence the detection fails.

 

[dengolius]

your backups don't follow the expected naming scheme, hence the detection fails.

LOL, as for vma.gzip adding one word into archive name - works well, but for zst adding word breaks the working logic of the archiver?
I think that this is at least a strange conclusion and strange logic of work...

If proxmox web ui shows the archive - so it must works well. But if now - it's not working as for vmz.gz files.

 

[fabian]

LOL, as for vma.gzip adding one word into archive name - works well, but for zst adding word breaks the working logic of the archiver?
I think that this is at least a strange conclusion and strange logic of work...

If proxmox web ui shows the archive - so it must works well. But if now - it's not working as for vmz.gz files.

the change to add zstd support also reworked the detection logic which got stricter. we're already working on relaxing it again to match the old behaviour - archives as created by vzdump are not affected though, only those which are manually renamed after the backup.

 

[RobFantini]

same issue here, we do use a non standard backup script .

if you want we could test any alpha / beta version of the update. until then we'll use other compression method.

 

[RobFantini]

well even setting backup type to lzo - restore fails. this is a 1000GB backup done two times during an emergency. not fun.

so i'll try renaming the back up file to standard naming convention.

 

[H4R0]

zst support got added with pve 6.2 you are running 6.1 ?

 

[RobFantini]

zst support got added with pve 6.2 you are running 6.1 ?

we are up to date.

the issue is in vzump we have this set:

script: /fbc/bin/pve/backup.sh

our custom script creates files names like this:
vzdump-qemu-88950-pro4v9-a-2020_05_14-16_46_44.vma.zst

we are able to restore with this mv:

mv vzdump-qemu-88950-pro4v9-a-2020_05_14-16_46_44.vma.zst vzdump-qemu-88950-2020_05_14-16_46_44.vma.zst

 

[t.lamprecht]

FYI: This should be addressed with updating to libpve-storage-perl in version 6.1-8 and or later, just moved to our pvetest testing repo.

 

[RobFantini]

FYI: This should be addressed with updating to libpve-storage-perl in version 6.1-8 and or later, just moved to our pvetest testing repo.

Hi
I installed libpve-storage-perl_6.1-8_all.deb on a couple of systems and tested backup and restore of a kvm and lxc, worked perfect! thank you.

 

[willybong]

From 6.2-9 is fixed

 

[rootnetworks]

I renamed ZST backup file because we transfer to another node Make file name more readable not to be confused with backups that already exist on the node. but encountered an error when recovering

Is the filename so important? I think it is possible to read the format inside ZST, not the filename.

qmrestore centos7-web-1.vma.zst 101
error before or during data restore, some or all disks were not completely restored. VM 101 state is NOT cleaned up.
ERROR: couldn't determine archive info from '/opt/kvm/template/centos7-web-1.vma.zst'

 

[fabian]

yes it's important if you use qmrestore (or the API as root@pam) you can also restore from files that are outside of the regular hierarchy (so no potential for confusion since they are not listed over the API/GUI), so you don't need to change the filename, just the place where it's stored for that.

 

[rootnetworks]

yes it's important if you use qmrestore (or the API as root@pam) you can also restore from files that are outside of the regular hierarchy (so no potential for confusion since they are not listed over the API/GUI), so you don't need to change the filename, just the place where it's stored for that.

for me I have multiple clusters transfer backup to another cluster may have the same VMID. This requires great care. for better I can transfer to a temp folder instead of dump directory

 

[fabian]

you can transfer it wherever if you are using qmrestore, just pass in the absolute path..