proxmox-restore-daemon und Filesystem ohne Partitiontable

S

sub2o5

Member
Nov 5, 2021
98
12
13
41
Hi,

Ich habe bei einer VM direkt ein EXT4-FS auf einem Blockdevice. Dieses sichere ich per PBS.
Filerestore scheint nicht zu funktionieren, lädt ewig und wirft dann manchmal einen Timeout.
Kann es sein, dass der proxmox-restore-daemon der mini-VM nicht mit der Konstellation klarkommt? (keine Partitiontable)
Oder mag das am großen Blockdevice liegen? (~40TB)

Gruß
Stephan
 
sub2o5 said:
Hi,

Ich habe bei einer VM direkt ein EXT4-FS auf einem Blockdevice. Dieses sichere ich per PBS.
Filerestore scheint nicht zu funktionieren, lädt ewig und wirft dann manchmal einen Timeout.
Kann es sein, dass der proxmox-restore-daemon der mini-VM nicht mit der Konstellation klarkommt? (keine Partitiontable)
Oder mag das am großen Blockdevice liegen? (~40TB)

Gruß
Stephan
Click to expand...
Hi,
bitte VM config posten qm config <VMID>. Versuch mal den snapshot zu einem loop device zu mappen und anschliessend zu mounten.
PHP: 
# map on /dev/loopX
proxmox-backup-client map <snapshot> <archive-name>
# mount /dev/loopX
mount /dev/loopX <mountpoint>
 
Chris said:
Hi,
bitte VM config posten qm config <VMID>. Versuch mal den snapshot zu einem loop device zu mappen und anschliessend zu mounten.
PHP: 
# map on /dev/loopX
proxmox-backup-client map <snapshot> <archive-name>
# mount /dev/loopX
mount /dev/loopX <mountpoint>
Click to expand...
Per Loop geht es, hatte ich gestern schon probiert und leider vergessen zu erwähnen.

Im Filerestore geht wiegesagt nichts auf, er zeigt zwar die 3 Laufwerke aber danach geht es nicht weiter.
Das Device ohne Partitiontable ist scsi1.
Die Daten liegen auf einem PBS und sind verschlüsselt.

Code: 
agent: 1
balloon: 2048
boot: order=scsi0
cores: 24
cpu: host
ide2: none,media=cdrom
machine: q35
memory: 8192
name: srv.int.local
net0: virtio=32:22:22:22:22:xx,bridge=vmbr100
numa: 0
ostype: l26
scsi0: nvme:vm-106-disk-0,discard=on,size=150G,ssd=1
scsi1: hdd:vm-106-disk-1,format=raw,size=39T
scsi2: hdd:vm-106-disk-2,format=raw,size=4G
scsihw: virtio-scsi-pci
smbios1: uuid=332bc19b-2915-4df2-87ce-db5889f25f88
sockets: 1
vmgenid: fe6b920a-7c67-4b86-ae0b-eb5ce41d16d6

1684395820249.png
Nach ca. 30-60 Sekunden:
1684395866634.png
 
Last edited:
Habe testweise scsi2 nochmal entfernt, wird sowieso nicht gebraucht. Manchmal kommt (nach 2-3 Minuten) auch folgende Meldung:

1684396412246.png

Mit der reinen Größe der virtuellen Platte kann das aber nicht zusammenhängen, oder?
 
sub2o5 said:
Habe testweise scsi2 nochmal entfernt, wird sowieso nicht gebraucht. Manchmal kommt (nach 2-3 Minuten) auch folgende Meldung:

View attachment 50510

Mit der reinen Größe der virtuellen Platte kann das aber nicht zusammenhängen, oder?
Click to expand...
Ob eine Partitionstabelle auf dem block device ist oder direkt das filesystem macht keinen Unterschied. Bitte mal testen welche requests der browser macht und wie viele bzw. ob diese jeweils eine response bekommen.
Dazu developer tools im Browser öffnen und den Netzwerk tab selektieren. Als filter der request 'restore' verwenden und dann auf den file restore button clicken und den block device index selektieren.

Auf was für einem storage befindet sich auf PBS Seite der datastore? sind dort SSDs oder HDDs im Einsatz?

Edit: Auch von Interesse: Wie performat ist das navigiern wenn der snapshot via loop device gemapped und gemounted wurde?
 
Last edited:
Habe testweise einer anderen VM ein 32GB-Platte gegeben und dort raw ext4 draufgepackt. Das funktioniert und ist performant.

Netzwerkanalyse der großen RAW-Partition und dem Versuch des Filerestore:
1684572385667.png
1684572394691.png
(immer mal eine andere Fehlermeldung)

Die Backups sind auf hdd/ssd (zfs specialdevices) und eigentlich recht performant. Zumal das ZFS noch ganz frisch ist und das Backup dementsprechend kaum fragmentiert.

Mapping per CLI dauert 3-4 Sekunden, selbst wenn währenddessen noch der Filerestore mit "Loading..." rumrödelt.

anschließender mount ~10 sekunden

Navigation auf dem FS relativ flott, "find" läuft auch schnell.
Insgesamt stockt da kaum was.
Lesegeschwindigkeit einer größeren Datei ~145MB/s.
Tar über kleinere file > dev/null ~ 90mb/s

Würde also das Backend als Flaschenhals ausschließen.

Alles in Allem echt seltsam.

Edit: PVE und PBS sind frisch aufgesetzt.
Aktuelle Versionen, PVE vom offiziellen Stick/ISO.
PBS läuft (auch wenn nicht empfohlen, Homelab) auf dem PVE (dort nachträglich installiert)

Edit2:

Beim PBS sieht man in der Tasklog, dass die Datastore Read Object-Tasks mit einem Fehler abbrechen.
"TASK ERROR: connection error: not connected"
- wohl aber vorher schon zig Chunks gelesen haben!
Es scheinen immer 4 Prozesse/Tasks gleichzeitig zu laufen.
Einer bricht dann irgendwann ab und der PVE öffnet einen Neuen.

Edit3:
IO-Delay während dessen zwischen <=0.20%
 
Last edited:
sub2o5 said:
Habe testweise einer anderen VM ein 32GB-Platte gegeben und dort raw ext4 draufgepackt. Das funktioniert und ist performant.

Netzwerkanalyse der großen RAW-Partition und dem Versuch des Filerestore:
View attachment 50610
View attachment 50611
(immer mal eine andere Fehlermeldung)

Die Backups sind auf hdd/ssd (zfs specialdevices) und eigentlich recht performant. Zumal das ZFS noch ganz frisch ist und das Backup dementsprechend kaum fragmentiert.

Mapping per CLI dauert 3-4 Sekunden, selbst wenn währenddessen noch der Filerestore mit "Loading..." rumrödelt.

anschließender mount ~10 sekunden

Navigation auf dem FS relativ flott, "find" läuft auch schnell.
Insgesamt stockt da kaum was.
Lesegeschwindigkeit einer größeren Datei ~145MB/s.
Tar über kleinere file > dev/null ~ 90mb/s

Würde also das Backend als Flaschenhals ausschließen.

Alles in Allem echt seltsam.

Edit: PVE und PBS sind frisch aufgesetzt.
Aktuelle Versionen, PVE vom offiziellen Stick/ISO.
PBS läuft (auch wenn nicht empfohlen, Homelab) auf dem PVE (dort nachträglich installiert)

Edit2:

Beim PBS sieht man in der Tasklog, dass die Datastore Read Object-Tasks mit einem Fehler abbrechen.
"TASK ERROR: connection error: not connected"
- wohl aber vorher schon zig Chunks gelesen haben!
Es scheinen immer 4 Prozesse/Tasks gleichzeitig zu laufen.
Einer bricht dann irgendwann ab und der PVE öffnet einen Neuen.

Edit3:
IO-Delay während dessen zwischen <=0.20%
Click to expand...
Sind die 'connection errors' im PBS tasklog mit den Zeiten den '500 connection reset errors' auf PVE Seite korreliert? Ich konnte das Problem bei mir lokal noch nicht nachstellen, habe aber kein so grosses Backup. Tritt dieses Problem auch bei anderen Backups mit solcher disk size auf?
 
Ja, es scheint als würde der Daemon auf PVE-Seite immer 4 Sitzungen zum PBS aufbauen, sobald eine Abbricht baut er im Hintergrund direkt eine Neue auf. Je länger das Fenster ohne Ergebnis rödelt, desto länger wird dann die Liste der "roten Einträge".

Das ist leider meine einzige Disk mit dieser Größe, kann es anderweitig leider nicht testen.
Ich könnte versuchen, mir noch einen Stapel Platten zu organisieren und ein Dummydevice anzulegen, um es dann mit Trash zu füllen und zu sichern. Aber das Artet in extreme Arbeit aus. :-/
 
Man iseht auch recht schön an den Uhrzeiten, dass es immer 4 Prozesse sind: (Liste 2-3mal so lang)
1684738599505.png
 
sub2o5 said:
Ja, es scheint als würde der Daemon auf PVE-Seite immer 4 Sitzungen zum PBS aufbauen, sobald eine Abbricht baut er im Hintergrund direkt eine Neue auf. Je länger das Fenster ohne Ergebnis rödelt, desto länger wird dann die Liste der "roten Einträge".

Das ist leider meine einzige Disk mit dieser Größe, kann es anderweitig leider nicht testen.
Ich könnte versuchen, mir noch einen Stapel Platten zu organisieren und ein Dummydevice anzulegen, um es dann mit Trash zu füllen und zu sichern. Aber das Artet in extreme Arbeit aus. :-/
Click to expand...
Bitte einen Bugreport aufmachen und auf diesen Thread hier verweisen: https://bugzilla.proxmox.com/
Als workaround bleibt zur Zeit der file restore via map und mount.
 
Okay, bitte auch /var/log/proxmox-backup/file-restore/qemu.log anhaengen.
 
Ich setze mir mal eine Dev-VM auf und versuche mir die PVE-Buildumgebung einzurichten und mit dem mem/maxmem der restore-vm zu spielen.
rudimentäres Patchen mit Hexeditor ging leider nicht, Rust scheint die Stringlänge und -Offset gesondert zu schreiben. ;-)
 
Nach dem erhöhen des Speichers für die Restore-VM (1024MB) läuft es!

Über die Schmerzen der letzten 3 Stunden bis ich den Kram endlich kompilieren konnte möchte ich an dieser Stelle nicht sprechen...
Eine Buildumgebung einzurichten ist ohne tiefgreifendes Wissen quasi unmöglich und ich mußte diverse Abkürzungen nutzen, damit ich irgendwie ans Ziel kam ;-)
 
sub2o5 said:
Nach dem erhöhen des Speichers für die Restore-VM (1024MB) läuft es!

Über die Schmerzen der letzten 3 Stunden bis ich den Kram endlich kompilieren konnte möchte ich an dieser Stelle nicht sprechen...
Eine Buildumgebung einzurichten ist ohne tiefgreifendes Wissen quasi unmöglich und ich mußte diverse Abkürzungen nutzen, damit ich irgendwie ans Ziel kam ;-)
Click to expand...
Hi,
danke für die Status-Updates und das debuggen. Eigentlich ist das Einrichten des build system relativ einfach, siehe dazu die readme hier [0].

Woran hat es denn gehackt? Externes Feedback ist immer willkommen.

[0] https://git.proxmox.com/?p=proxmox-...53e42f232e1f00efe2717a168043c7d82e61e;hb=HEAD
 
Chris said:
Hi,
danke für die Status-Updates und das debuggen. Eigentlich ist das Einrichten des build system relativ einfach, siehe dazu die readme hier [0].

Woran hat es denn gehackt? Externes Feedback ist immer willkommen.

[0] https://git.proxmox.com/?p=proxmox-...53e42f232e1f00efe2717a168043c7d82e61e;hb=HEAD
Click to expand...
Die URL kannte ich nicht. Ich habe in diversen Dokus und READMEs gefischt, ein PVE frisch als VM installiert, dort den Kram nachinstalliert, mich stundenlang mit mangelhaftem Rust/Cargo-Wissen durch Dependencies gekämpft, dann gefühlt 300 librust-xxx-dev-Pakete installiert und, nachdem ich noch an 2 Stellen gepatcht hatte um librust-proxmox-tfa-irgendwas version 3 statt 4 (die 4 fand ich nicht per apt) nutzen zu können, ging es dann ;-)

Die meiste Zeit ging damit drauf, cargo lauffähig zu bekommen. War trial&error, anfangs fand er "hex" und "anyhow" nicht.

Ich arbeite morgen mal deinen Link ab und schaue, ob ich damit besser zu Rande komme!

Meine Quellen:
https://git.proxmox.com/?p=pve-common.git;a=blob_plain;f=README.dev
https://pve.proxmox.com/wiki/Developer_Documentation#Development_Package_Repository

Vielleicht sollte man alle alten Dokumente mal zusammenfassen / durch Verweise auf aktuelle Versionen ersetzen, denn letztlich findet man natürlich das, was die Suchmaschine zuerst ausspukt und was Foren anbieten.

Edit:

Mein rudimentärer "Patch" der qemu_helper.rs ab Zeile 312:

let ram = if debug {
1024
} else {
// add more RAM if many drives are given
match id {
f if f < 10 => 1024,
f if f < 20 => 2048,
_ => 4096,
}
};

Geht sicherlich deutlich eleganter, womöglich könnte man auch eine Abfrage einbauen, ob die VM mit OOM gecrasht ist und sie dann mit doppeltem RAM neu starten, bzw. das irgendwie etwas größzügiger am System-RAM festmachen.
 
Last edited:
Hi,
Chris said:
danke für die Status-Updates und das debuggen. Eigentlich ist das Einrichten des build system relativ einfach, siehe dazu die readme hier [0].

Woran hat es denn gehackt? Externes Feedback ist immer willkommen.

[0] https://git.proxmox.com/?p=proxmox-...53e42f232e1f00efe2717a168043c7d82e61e;hb=HEAD
Click to expand...
Hallo Chris,

ich bin genau nach Anleitung vorgegangen. Frisches Debian 11.
mk-build-deps schlägt fehl, es sind 2 Pakete nicht auffindbar:

[...]
Hängt ab von: librust-zstd-0.12+bindgen-dev ist aber nicht installierbar
Hängt ab von: librust-zstd-0.12+default-dev ist aber nicht installierbar
 
sub2o5 said:
Hi,

Hallo Chris,

ich bin genau nach Anleitung vorgegangen. Frisches Debian 11.
mk-build-deps schlägt fehl, es sind 2 Pakete nicht auffindbar:

[...]
Hängt ab von: librust-zstd-0.12+bindgen-dev ist aber nicht installierbar
Hängt ab von: librust-zstd-0.12+default-dev ist aber nicht installierbar
Click to expand...
Hi,
bitte stable-2 branch Anstelle von master verwenden. master verwendet bereits Abhängigkeiten von Debian 12.
 
Ok, bin weiter, habe aber wieder das Problem, dass Cargo nicht die Abhängigkeiten findet/lädt.

Code: 
➜  proxmox-backup git:(stable-2) ✗ cargo build --all --release
error: no matching package named `anyhow` found
location searched: registry `crates-io`
required by package `pbs-api-types v0.1.0 (/root/proxmox-backup/pbs-api-types)`
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom
Back