zip file downloads from File Restore have errors

[k.jings]

Evaluating and new to ProxMox. Finally got around to testing around 60 File Restores. Windows 11 Pro: "...cannot open the folder. The Compressed (zipped) folder 'C:\tmp\xyz.zip' is invalid.". 7z extracts the zip contents while reporting "C:\tmp\xyz.zip Warnings: Headers Error". Some 7z extracts include an extra "Unexpected end of data". Testing the zip files with 7z reports the same error. Moving the zip files to Debian 11 and running unzip -t reports errors. zip -F | zip -FF seems to fix most. I do not have WinZip.

Does anyone else see this issue? Am I doing something incorrectly? I'd be grateful for feedback.

PVE: CPU(s) 16 x AMD Ryzen 7 3700X 8-Core Processor (1 Socket)
Kernel Version Linux 5.13.19-3-pve #1 SMP PVE 5.13.19-7 (Thu, 20 Jan 2022 16:37:56 +0100)
PVE Manager Version pve-manager/7.1-10/6ddebafe

PBS: CPU(s) 4 x AMD A10-7800 Radeon R7, 12 Compute Cores 4C+8G (1 Socket)
Kernel Version Linux 5.13.19-3-pve #1 SMP PVE 5.13.19-7 (Thu, 20 Jan 2022 16:37:56 +0100)

 

[dcsapak]

from where do you download the zips? pve or pbs? can you post your versions? ('pveversion -v' and 'proxmox-backup-manager versions --verbose')
any chance that you can upload such zip ? (without any critical data, and as small as possible)

 

[k.jings]

Downloaded on PVE.

pveversion -v

proxmox-ve: 7.1-1 (running kernel: 5.13.19-3-pve)
pve-manager: 7.1-10 (running version: 7.1-10/6ddebafe)
pve-kernel-helper: 7.1-8
pve-kernel-5.13: 7.1-6
pve-kernel-5.13.19-3-pve: 5.13.19-7
pve-kernel-5.13.19-2-pve: 5.13.19-4
ceph-fuse: 14.2.21-1
corosync: 3.1.5-pve2
criu: 3.15-1+pve-1
glusterfs-client: 9.2-1
ifupdown: residual config
ifupdown2: 3.1.0-1+pmx3
libjs-extjs: 7.0.0-1
libknet1: 1.22-pve2
libproxmox-acme-perl: 1.4.1
libproxmox-backup-qemu0: 1.2.0-1
libpve-access-control: 7.1-6
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.1-2
libpve-guest-common-perl: 4.0-3
libpve-http-server-perl: 4.1-1
libpve-storage-perl: 7.0-15
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 4.0.11-1
lxcfs: 4.0.11-pve1
novnc-pve: 1.3.0-1
proxmox-backup-client: 2.1.4-1
proxmox-backup-file-restore: 2.1.4-1
proxmox-mini-journalreader: 1.3-1
proxmox-widget-toolkit: 3.4-5
pve-cluster: 7.1-3
pve-container: 4.1-3
pve-docs: 7.1-2
pve-edk2-firmware: 3.20210831-2
pve-firewall: 4.2-5
pve-firmware: 3.3-4
pve-ha-manager: 3.3-3
pve-i18n: 2.6-2
pve-qemu-kvm: 6.1.0-3
pve-xtermjs: 4.12.0-1
qemu-server: 7.1-4
smartmontools: 7.2-1
spiceterm: 3.2-2
swtpm: 0.7.0~rc1+2
vncterm: 1.7-1
zfsutils-linux: 2.1.2-pve1

proxmox-backup-manager versions --verbose

proxmox-backup             2.1-1        running kernel: 5.13.19-3-pve
proxmox-backup-server      2.1.4-1      running version: 2.1.4       
pve-kernel-helper          7.1-8                                     
pve-kernel-5.13            7.1-6                                     
pve-kernel-5.13.19-3-pve   5.13.19-7                                 
pve-kernel-5.13.19-2-pve   5.13.19-4                                 
ifupdown2                  3.1.0-1+pmx3                             
libjs-extjs                7.0.0-1                                   
proxmox-backup-docs        2.1.4-1                                   
proxmox-backup-client      2.1.4-1                                   
proxmox-mini-journalreader 1.3-1                                     
proxmox-widget-toolkit     3.4-5                                     
pve-xtermjs                4.16.0-1                                 
smartmontools              7.2-1                                     
zfsutils-linux             2.1.2-pve1

Access via Google Chrome Version 98.0.4758.74 running Windows 11 Pro, Version 21H2 (OS Build 22000.469). Intel Core i7-6770HQ. 32GB RAM. 1TB nvme, Raid1. Used built-in Extract function (via Explorer). 7zip 21.07 (x64). Windows built-in tar (bsdtar, 3.5.2).

I have not had time to run statistically significant testing. I will share what I have done so far:

• Three datasets
  • data1 3.01 GB
  • data2 21.50 GB
  • data3 105.00 GB
• data1
  • No issues: Windows extract; 7zip; Windows tar -xvzf.
    • WinDiff was used to verify the extracts.
      • All matched
• data2
  • Windows extract and tar: no problem.
  • 7zip issued 1 error, and continued the extract:
    • Warnings
    • Headers Error
  • WinDiff showed all three extracts are a match!
    • Do not know what the 7zip error means, but it seemed to have no impact on the extract.
• data3
  • Just kicked off the testing.
    • It will run for several hours.
      • I will report later.

On the surface, it appears that the smaller zip files seem to work consistently. I see erratic results with some of the larger downloads. Sorry, I am unable to send samples due to the sensitive nature of the content. I can share that on Linux a 625MiB file showed several of these errors with unzip -t:

error:  invalid compressed data to inflate
    testing: 2002/2002_05/2002_05_13/
  error:  invalid compressed data to inflate
    testing: 2002/2002_05/2002_05_04/
  error:  invalid compressed data to inflate
    testing: 2002/2002_05/2002_05_03/
  error:  invalid compressed data to inflate
    testing: 2002/2002_05/2002_05_07/
  error:  invalid compressed data to inflate
    testing: 2002/2002_12/
  error:  invalid compressed data to inflate
    testing: 2002/2002_12/2002_12_28/
  error:  invalid compressed data to inflate

zip -F and zip -FF seemed not to repair the downloaded zip. tar -xzvf bombed:

gzip: stdin: invalid compressed data--format violated
tar: Child returned status 1
tar: Error is not recoverable: exiting now

As I said, probably statistically invalid results at this point, but inconsistency remains as valid.

 

[k.jings]

Unless there are others with this issue, I recommend closing this thread until I (or someone) can provide statistically significant findings. I am thinking of writing my issue off for now as a newbie downloading file restore zip files on a highly congested network. Thank You, Dominik, for responding.

 

[dcsapak]

yeah, sorry i could not reproduce the issue here... if you can create a small reproducer sample, you can simply attach it here and i'll look at it, or better you can open a bug report on https://bugzilla.proxmox.com then

 

[ubu74]

Same issue, Firefox 100, pve 7.2-3 Download seems finished (not shown as failed in Browser) but different sizes at different tries and not finished, ( trying chrome and vivaldi now)

 

[ubu74]

https://forum.proxmox.com/threads/z...-file-restore-have-errors.103775/#post-448318 also did report this issue, seems to happen only to bigger directories (1-10GB)

 

[ubu74]

Log on proxmox host
Jun 09 13:18:10 pve1 pvedaemon[422329]: file restore task failed: command '/usr/bin/proxmox-file-restore extract '--crypt-mode=encrypt' '--keyfd=11' ct/10000102/2022-05-31T00:42:57Z ... - --base64 1 --repository pbs-backup@pbs@10.0.0.15bs-backup' failed: exit code 255
Jun 09 13:18:10 pve1 pvedaemon[383404]: <root@pam> end task UPIDve1:000671B9:0BC00741:62A1D3EFbs-download::root@pam: file restore task failed: command '/usr/bin/proxmox-file-restore extract '--crypt-mode=encrypt' '--keyfd=11' ct/10000102/2022-05-31T00:42:57Z ... - --base64 1 --repository pbs-backup@pbs@10.0.0.15bs-backup' failed: exit code 255
Jun 09 13:18:12 pve1 pveproxy[431451]: worker exit

Open for suggestions

 

[dcsapak]

can you check the syslog on the pbs side ?

 

[ubu74]

Yes but i did not see anything at that timestamp in the journal, ist there a specific logfile i should check?

 

[dcsapak]

no the normal syslog should contain *some* info about that...
you can try to execute the 'proxmox-file-restore' command from the error by hand and check if there is any more information then...