Zip archive inconsistent - Recovery not possible

[fireon]

Hello all,

pve-manager/6.4-4/337d6701 (running kernel: 5.4.106-1-pve)
proxmox-backup-server 1.1.5-1 running version: 1.1.5

i wanted to restore a whole directory. Unfortunately, after downloading the ZIP can not be opened and also not unpacked.

Zip archive inconsistent

This is not the same with all VM's and all directories. Some directories will be download, and are consistent. What could be the cause of the behaviour here?

 

[dcsapak]

with which program do you try to open it?
could you try to do a 'zipinfo <file>' on a debian 10 machine? (thats what we mostly tested here)

is there anything in the journal/syslog during the download of the zip?

if you can reproduce it with some non-sensitive data, you can open a bug and attach such a zip file there

 

[fireon]

Ok, i will have a look @evening.

 

[fireon]

Strange. 2 of 3 folders show me everything with zipinfo. But with the graphical application "ark" from Ubuntu/KdeNeon, it did not open correctly. But not all. Some folders can be opened normally. And one folder show me

Archive:  root.zip
[root.zip]
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
note:  root.zip may be a plain executable, not an archive
zipinfo:  cannot find zipfile directory in one of root.zip or
          root.zip.zip, and cannot find root.zip.ZIP, period.

It is an GIT archive inside. I have already downloaded it 3 times. Always a different size, each time corrupt. I'll search again and test, maybe I'll find something I can upload.

 

[dcsapak]

It is an GIT archive inside. I have already downloaded it 3 times. Always a different size, each time corrupt. I'll search again and test, maybe I'll find something I can upload.

ok did you check the syslog/journal of the pbs for errors/warnings? (or is it the single file restore on pve for vms? in that case the /var/log/proxmox-backup/file-restore/qemu.log on pve is interesting)

 

[fireon]

/var/log/proxmox-backup/file-restore/qemu.log

This file and the directory did not exist here. But, i had a look in journalctl durning the single filerestore. And i see a log of normal info logs. No Errors.

 

[dcsapak]

do you use the file restore on the pbs webgui or the pve webgui ?
if on pbs: you have to check the logs on pbs
if a ct on pve: check the journal on pve
if a vm on pve: check the file i said above on pve (that file must exists for the vm single file restore)

 

[fireon]

Ok, now i undertand more. thank you. I do an filerestore of an VM from pve. This is the Log:

[2021-05-13T16:54:31+02:00] PBS file restore VM log
[init-shim] beginning user space setup
[init-shim] reached daemon start after 0.69s
[2021-05-13T14:54:32Z INFO  proxmox_restore_daemon::proxmox_restore_daemon::disk] drive 'vdb' ('drive-scsi0'): found partition '/dev/vdb2' (2, 37041995776B)
[2021-05-13T14:54:32Z INFO  proxmox_restore_daemon::proxmox_restore_daemon::disk] drive 'vdb' ('drive-scsi0'): found partition '/dev/vdb1' (1, 536870912B)
[2021-05-13T14:54:32Z INFO  proxmox_restore_daemon::proxmox_restore_daemon::disk] drive 'vda' ('drive-scsi1'): found partition '/dev/vda1' (1, 4293901824B)
[2021-05-13T14:54:32Z INFO  proxmox_restore_daemon::proxmox_restore_daemon::disk] Supported FS: reiserfs, ext3, ext4, ext2, vfat, msdos, iso9660, hfsplus, hfs, sysv, v7, ntfs, ufs, jfs, xfs, befs, f2fs, btrfs
[2021-05-13T14:54:39Z WARN  proxmox_restore_daemon::proxmox_restore_daemon::disk] mount error on '/dev/vdb2' (reiserfs) - EINVAL: Invalid argument
EXT4-fs (vdb2): couldn't mount as ext3 due to feature incompatibilities
[2021-05-13T14:54:39Z WARN  proxmox_restore_daemon::proxmox_restore_daemon::disk] mount error on '/dev/vdb2' (ext3) - EINVAL: Invalid argument
EXT4-fs (vdb2): write access unavailable, skipping orphan cleanup
[2021-05-13T14:54:39Z INFO  proxmox_restore_daemon::proxmox_restore_daemon::disk] mounting '/dev/vdb2' succeeded, fstype: 'ext4'
watchdog expired, shutting down
reboot: Power down

If i do an "file" on the ZIP-File, i get this information:

root.zip: Zip archive data, at least v4.5 to extract

If i do an zipinfo, i get this information:

Archive:  root.zip
[root.zip]
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
note:  root.zip may be a plain executable, not an archive
zipinfo:  cannot find zipfile directory in one of root.zip or
          root.zip.zip, and cannot find root.zip.ZIP, period.

If i choose some directories inside this directory, and recover that, it works. Also with ubuntu's graphical ARK. The only thing I noticed: The tmestamp in the log is wrong. 2 hours behind. On the system, and other logs, there is the right time. This is config of the VM:

agent: 1
bios: ovmf
boot: order=scsi0;net0
cores: 32
cpuunits: 900
description: Ubuntu Entwicklungsserver auf Basis 20.04
efidisk0: SSD-vmdata:vm-115-disk-0,size=1M
hotplug: disk,network,usb,memory,cpu
memory: 4096
name: ubudev.osit.cc
net0: virtio=5C:77:2B:E7:DB:BB,bridge=vmbr0,firewall=1
numa: 1
onboot: 1
ostype: l26
scsi0: SSD-vmdata:vm-115-disk-1,discard=on,size=35G,ssd=1
scsi1: SSD-vmdata:vm-115-disk-2,discard=on,size=4G,ssd=1
scsihw: virtio-scsi-pci
serial0: socket
sockets: 1
vcpus: 8

 

[dcsapak]

mhmm... i really hoped there would be more info in the log. any chance to get a hand on one of such zip files?
also how long does the zip download take? more than 10 minutes? if yes, maybe we do shutdown the restore vm while it's still generating

 

[fireon]

Yes, more then 10 Minutes. Maybe it is the size and the Quantity of files? I'am searching for another directory.

 

[dcsapak]

yes, if there are many files, it can take a while to generate the zip. after 10 minutes after the last api call to the daemon inside the restore vm, it shuts itself down,
i'll try to reproduce it here, and if i can send a fix