File restore download bricht ab bei großen Dateien

[KnowVation]

Hallo Zusammen,

wir haben Proxmox Backupserver neu bei uns im Einsatz und testen gerade verschiedene Backup / Restore Szenarien. Dabei ist uns aufgefallen dass der Download einzelner Dateien (hier als Beispiel eine 25Gb große Datenbanksicherung) sich nicht downloaden lässt. Bei kleineren Dateien scheint es ohne Probleme zu funktionieren. Bei Files in der Größenordnung (25Gb) läuft der Download an und bleibt dann nach ein paar Minuten bei einer beliebig übertragenen Datenmenge stehen. Das sind mal 800Mb mal 4Gb aber der Download wird nie fertig. Browser habe ich Chrome, Firefox und Edge getestet.

Ist das Problem bekannt?

Danke und Grüße
Ronny

 

[dcsapak]

gehts um das file-restore im pve ?

wenn ja, was sagt denn das file /var/log/proxmox-backup/file-restore/qemu.log auf dem host wo das file-restore initiiert wurde (also wo das webinterface verbunden ist)

auch interessant wäre das journal vom backup server zu der zeit

 

[KnowVation]

Hallo

Ja es geht um das File-restore im pve. Wo finde ich das journal vom Backupserver?

[2022-11-29T12:11:21+01:00] PBS file restore VM log
[init-shim] beginning user space setup
[init-shim] debug: agetty start failed: /sbin/agetty not found, probably not running debug mode and safe to ignore
[init-shim] reached daemon start after 0.50s
[2022-11-29T11:11:22.504Z INFO  proxmox_restore_daemon] setup basic system environment...
[2022-11-29T11:11:22.504Z INFO  proxmox_restore_daemon] scanning all disks...
[2022-11-29T11:11:22.505Z 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
EXT4-fs (vdd): VFS: Can't find ext4 filesystem
EXT4-fs (vdd): VFS: Can't find ext4 filesystem
EXT2-fs (vdd): error: can't find an ext2 filesystem on dev vdd.
FAT-fs (vdd): invalid media value (0xf3)
FAT-fs (vdd): invalid media value (0xf3)
VFS: could not find a valid V7 on vdd.
ntfs: (device vdd): read_ntfs_boot_sector(): Primary boot sector is invalid.
ntfs: (device vdd): read_ntfs_boot_sector(): Mount option errors=recover not used. Aborting without trying to recover.
ntfs: (device vdd): ntfs_fill_super(): Not an NTFS volume.
ufs: ufs_fill_super(): bad magic number
befs: (vdd): invalid magic header
F2FS-fs (vdd): Can't find valid F2FS filesystem in 1th superblock
F2FS-fs (vdd): Can't find valid F2FS filesystem in 2th superblock
[2022-11-29T11:11:22.517Z INFO  proxmox_restore_daemon::proxmox_restore_daemon::disk] drive 'vdd' ('drive-virtio0'): found partition '/dev/vdd2' (2, 1073741824B)
[2022-11-29T11:11:22.518Z INFO  proxmox_restore_daemon::proxmox_restore_daemon::disk] drive 'vdd' ('drive-virtio0'): found partition '/dev/vdd3' (3, 4294967296B)
[2022-11-29T11:11:22.519Z INFO  proxmox_restore_daemon::proxmox_restore_daemon::disk] drive 'vdd' ('drive-virtio0'): found partition '/dev/vdd1' (1, 524288B)
[2022-11-29T11:11:22.520Z INFO  proxmox_restore_daemon::proxmox_restore_daemon::disk] drive 'vdd' ('drive-virtio0'): found partition '/dev/vdd4' (4, 16097738752B)
EXT4-fs (vdb): VFS: Can't find ext4 filesystem
EXT4-fs (vdb): VFS: Can't find ext4 filesystem
EXT2-fs (vdb): error: can't find an ext2 filesystem on dev vdb.
FAT-fs (vdb): bogus number of reserved sectors
FAT-fs (vdb): bogus number of reserved sectors
VFS: could not find a valid V7 on vdb.
ntfs: (device vdb): read_ntfs_boot_sector(): Primary boot sector is invalid.
ntfs: (device vdb): read_ntfs_boot_sector(): Mount option errors=recover not used. Aborting without trying to recover.
ntfs: (device vdb): ntfs_fill_super(): Not an NTFS volume.
ufs: ufs_fill_super(): bad magic number
befs: (vdb): invalid magic header
F2FS-fs (vdb): Can't find valid F2FS filesystem in 1th superblock
F2FS-fs (vdb): Can't find valid F2FS filesystem in 2th superblock
EXT4-fs (vdc): VFS: Can't find ext4 filesystem
EXT4-fs (vdc): VFS: Can't find ext4 filesystem
EXT2-fs (vdc): error: can't find an ext2 filesystem on dev vdc.
FAT-fs (vdc): bogus number of reserved sectors
FAT-fs (vdc): bogus number of reserved sectors
VFS: could not find a valid V7 on vdc.
ufs: ufs_fill_super(): bad magic number
befs: (vdc): invalid magic header
F2FS-fs (vdc): Can't find valid F2FS filesystem in 1th superblock
F2FS-fs (vdc): Can't find valid F2FS filesystem in 2th superblock
EXT4-fs (vda): VFS: Can't find ext4 filesystem
EXT4-fs (vda): VFS: Can't find ext4 filesystem
EXT2-fs (vda): error: can't find an ext2 filesystem on dev vda.
FAT-fs (vda): bogus number of reserved sectors
FAT-fs (vda): bogus number of reserved sectors
VFS: could not find a valid V7 on vda.
ufs: ufs_fill_super(): bad magic number
befs: (vda): invalid magic header
F2FS-fs (vda): Can't find valid F2FS filesystem in 1th superblock
F2FS-fs (vda): Can't find valid F2FS filesystem in 2th superblock
[2022-11-29T11:11:23.543Z INFO  proxmox_restore_daemon::proxmox_restore_daemon::disk] zpool 'SAPTRANS' (on: ["vdb"]) auto-mounted at 'Ok("/mnt/zpool/SAPTRANS")' (size: Some(53552873472))
[2022-11-29T11:11:24.123Z INFO  proxmox_restore_daemon::proxmox_restore_daemon::disk] zpool 'MaxDB' (on: ["vdc"]) auto-mounted at 'Ok("/mnt/zpool/MaxDB")' (size: Some(1206885810176))
[2022-11-29T11:11:24.231Z INFO  proxmox_restore_daemon] disk scan complete, starting main runtime...
[2022-11-29T11:11:46.948Z INFO  proxmox_restore_daemon::proxmox_restore_daemon::watchdog] Inhibit added: 1

 

[dcsapak]

Wo finde ich das journal vom Backupserver?

das kann man auf der cli vom backup server mit 'journalctl' ausgeben lassen
mit '--since' und '--until' kann man die zeit einschränken und mit '>' in ein file umleiten, zb:

journalctl --since '2022-11-28' --until '2022-11-30' > /tmp/journal.log

 

[dcsapak]

ist das log restore log von nachdem der file-download abgebrochen ist?

 

[KnowVation]

Das log restore log ist nachdem ich den download abgebrochen hatte da es nach ca. 40Mb nichtmehr weiter ging.

Hier noch das Journal log, danke für den Tip mit der Ausgabe in temp.

In diesem Beispiel habe ich ca. 12:10Uhr eine kleine Datei ca. 3 Mb heruntergeladen. Danach habe ich den Download für die 25 Tb Datei gestartet und nach ca. 10 Minuten abgebrochen da nach den 40Mb nichtsmehr heruntergeladen wurde.

Ich habe den Vorgang auch sicherheitshalber schonmal die ganze nacht durchlaufen lassen leider ging es da auch nach einigen Mb einfach nicht weiter.

 

[dcsapak]

In diesem Beispiel habe ich ca. 12:10Uhr eine kleine Datei ca. 3 Mb heruntergeladen. Danach habe ich den Download für die 25 Tb Datei gestartet und nach ca. 10 Minuten abgebrochen da nach den 40Mb nichtsmehr heruntergeladen wurde.

mhmm war das eine einzelne datei oder ein directory als zip?

wenn es ein zip war, kann es passieren dass viele nullen hintereinander kommen und das so gut wegkomprimiert wird dass es so aussieht als würde wenig/nichts heruntergeladen

auch möglich ist dass da vllt. irgendein proxy/firewall dazwischen funkt? gibt es sowas im netzwerk?

 

[KnowVation]

Kein Proxy oder Firewall dazwischen, es ist eine einezelne Datei. Es handelt sich um ein komprimiertes MAXDB Datenbankbackup mit der Endung .bck

Kleiner Nachtrag. Ich habe noch eine einzelne Datei größe ca. 11Gb heruntergeladen welche kein DB Backup ist und da hat der Download ohne Probleme funktioniert. Ebenfalls habe ich einen Ordner mit 15Gb heruntergeladen, dieser wurde beim Download automatisch gezippt und hat ebenfalls funktioniert.

Es scheint also nur die Datenbankbackups zu betreffen, aber gerade da wäre das Feature für uns interessant

 

[dcsapak]

Kein Proxy oder Firewall dazwischen, es ist eine einezelne Datei. Es handelt sich um ein komprimiertes MAXDB Datenbankbackup mit der Endung .bck

Kleiner Nachtrag. Ich habe noch eine einzelne Datei größe ca. 11Gb heruntergeladen welche kein DB Backup ist und da hat der Download ohne Probleme funktioniert. Ebenfalls habe ich einen Ordner mit 15Gb heruntergeladen, dieser wurde beim Download automatisch gezippt und hat ebenfalls funktioniert.

Es scheint also nur die Datenbankbackups zu betreffen, aber gerade da wäre das Feature für uns interessant

interessant, es sollte eigentlich egal sein was für eine datei es ist...
gibts auf dem host wo das file-restore gestartet wird irgendwelche interessante log einträge? bzw. von dort wäre das journal auch mal interessant (beginnend bevor der file restore gestartet wird bis es abbricht; vielleicht 5min vorher + nachher )