LXC /Qemu Backups hängen sich auf

[j0k4b0]

Hallo zusammen,

ich habe seit einigen Wochen das Problem, dass meine Backups auf zwei von drei Nodes nicht mehr richtig laufen. Auch wenn ich diese manuell starte starten die Backups nichts.

Generell erstelle ich jede Nacht auf einem internen und einem externen NFS Datensicherungen. Seit dem die Probleme angefangen haben, habe ich die Backups alle nicht mehr gleichzeitig sondern je Node und NFS Zeitversetzt, sodass es keine Überschneidungen gibt.
Backups auf der lokalen Platte funktionieren.

Auf Node 2 sind es nur die LXC Container, auf Node 3 sind es neben LXC auch noch 2 von 4 Windows VMs. Wobei das bei den QEMU Systemen auf den fehlenden Agent sein kann. Da schlagen teilweise die freeze commands fehl, wenn ich die Logs richtig deute.
Node 1 macht keine Probleme. Alle Backups laufen rund. Und da sind mit über 20VMs die meisten drauf.

Selbst wenn ich QEMU mit den Agents fixen kann - was kann das Problem bei LXC sein? Die gestoppen LXC Container machen keine Probleme.

Hier mal eine Ausgabe:

INFO: starting new backup job: vzdump 125 --storage fra1-nfs1-pvec01 --mode snapshot --node fra1-pvec01-m03 --compress lzo --remove 0
INFO: Starting Backup of VM 125 (lxc)
INFO: Backup started at 2020-05-07 22:59:11
INFO: status = running
INFO: CT Name: fra1-dbc01-m04.prod.<name>.intern
INFO: found old vzdump snapshot (force removal)
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: create storage snapshot 'vzdump'
INFO: creating archive '/mnt/pve/fra1-nfs1-pvec01/dump/vzdump-lxc-125-2020_05_07-22_59_11.tar.lzo'

Danach hängt das für circa. 24 Stunden bis es dann irgendwann abbricht. Der Container bleibt locked und das darauffolgende Backup bricht wegen dem Lock ab.

Die vzdump Config (/etc/vzdump.conf) ist auf default, hatte temporär mal probiert den "tmpdir" zu ändern, keine positiven Resultate.

Server Reboot ist auch schon gemacht worden, keine Änderung.

Backups sind Snapshots - Compression habe ich schon alle mal Test-weise ausprobiert, keine Änderung.

Versionen:
Kernel: Linux 5.3.10-1-pve #1 SMP PVE 5.3.10-1
PVE Manager Version: pve-manager/6.1-3/37248ce6


Irgendeine Idee wie ich dem Problem auf die Spur komme?

 

[oguz]

hi,

Generell erstelle ich jede Nacht auf einem internen und einem externen NFS Datensicherungen. Seit dem die Probleme angefangen haben, habe ich die Backups alle nicht mehr gleichzeitig sondern je Node und NFS Zeitversetzt, sodass es keine Überschneidungen gibt.
Backups auf der lokalen Platte funktionieren.

wahrscheinlich gibt es dann ein problem mit dem nfs.. netzwerkverbindung koennte schuld sein.

du kannst in /var/log/syslog und in journalctl schauen, ob es irgendwas gibt wenn du ein backup startest (bzw. waehrenddessen und wenn es abbricht)

 

[j0k4b0]

Mhhh, es kann ein NFS Problem sein, das würde ich vorerst aber gerne ausschließen.

Ich habe ein zweites Proxmox Cluster welches ebenfalls auf den NFS Server Datensicherungen erstellt - nie Probleme.
Der Node 1 hat auch keine Probleme.
Node 2 macht auch teilweise Backups.

Auch wenn ich Tagsüber mehrfach NFS Backups anstoße hängen die immer. Bei den anderen Nodes gibt es die Probleme nicht.

Ich glaube auch, dass es auf bestimmte Container beschränkt ist. z.B. laufen gestoppte Container problemlos durch im Backup-Run. Auf allen Nodes!

In den Logs habe ich nichts finden können außer dem Abbruch, wenn ich den manuell veranlasse.

 

[j0k4b0]

Ok, anscheinend kann man das auf Container beschränken, welche ein NFS Verzeichnis mounten. Allerdings funktioniert das mit Container auf dem Node 1 problemlos.

Irgendwelche Ideen diesbezüglich?

 

[oguz]

sind beide nodes im selben rechenzentrum mit dem nfs? es kann sein, dass die verbindung nicht schnell genug ist

 

[j0k4b0]

Jap sind alle in einem RZ, sind sogar in dem gleichen RACK und ohne Umwege mit dem gleichen Switch verbunden.

Danke!

 

[j0k4b0]

Keine Idee mehr? Das Problem besteht immer noch. Es sind immer die gleichen Container, die Probleme verursachen. Der Rest läuft problemlos.
Wie kann ich da weiter debuggen?
Können es Prozesse im Container sein, die das "Snapshot-Backup" verhindern?
Wie genau funktionieren die vzdump Sicherungen? Was passiert im Container damit?

 

[oguz]

Ok, anscheinend kann man das auf Container beschränken, welche ein NFS Verzeichnis mounten. Allerdings funktioniert das mit Container auf dem Node 1 problemlos.

Irgendwelche Ideen diesbezüglich?

mountest du denn das nfs im container? wie genau machst du das? vielleicht hast du irgendetwas miskonfiguriert

funktioniert es z.b. wenn du den mount entfernst?

 

[j0k4b0]

Hi oguz,
ich glaube, die Aussage ist nicht mehr richtig. Leider. Sehr merkwürdig das ganze. Sorry!

Ein konkretes Beispiel:
Ich habe ein MariDB Galera Cluster mit 3 Nodes. Alle auf die drei Hardware Systeme aufgeteilt.

Erster Hardware Node mit dem ersten DB-Node laufen die Backups problemlos. Auf dem zweiten und dritten Node lassen sich keine Backups erstellen. Dort hängen die auch wieder bei "Creating Archive...". Ich habe gerade mit beginn des Blog Posts mal ein manuelles Backup auf dem NFS angelegt (derzeit absolut keine Last auf dem NFS oder Netzwerk).
Die Container sind übrigens alle gleich. Einmal erstellt, kopiert, Name und IP geändert und feuer. Also absolut identisch.

INFO: starting new backup job: vzdump 125 --storage fra1-nfs1-pvec01 --mode snapshot --node fra1-pvec01-m03 --compress lzo --remove 0
INFO: Starting Backup of VM 125 (lxc)
INFO: Backup started at 2020-05-19 13:11:04
INFO: status = running
INFO: CT Name: fra1-dbc01-m04.prod.<domain>.intern
INFO: found old vzdump snapshot (force removal)
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: create storage snapshot 'vzdump'
INFO: creating archive '/mnt/pve/fra1-nfs1-pvec01/dump/vzdump-lxc-125-2020_05_19-13_11_04.tar.lzo'

Diese VM liegt auf meinem Hardware Node 3. Also einer der Nodes, die bei den Backups Probleme macht.

Wenn ich über diesen Hardware Node auf das NFS gehe, gibt es folgende Datei: /mnt/pve/fra1-nfs1-pvec01/dump/vzdump-lxc-125-2020_05_19-13_11_04.tar.dat

Also quasi die "tmp" Datei von dem Backup run.

13:12:15 = 35MB Größe
13:18:38 = 219MB Größe

Wird also durchaus größer. Wenn auch nur extrem langsam. Im Backup-Lauf sehe ich aber keine weitere Ausgabe dazu. Nur "creating archive"

Im der /etc/vzdump Config steht folgendes:

tmpdir: /tmp/

Gut, in dem Ordner gibt es nun auch einen Ordner:
/tmp/vzdumptmp14894/

Der ist aber nur 6.5K groß und wird auch nicht größer. Da sind auch nur die pct.conf und pct.fw im Unterordner /etc/vzdump/ Dateien drin. Sonst nichts.

Auch frage ich mich: wieso gibt es die .tar.dat Datei im NFS? Müsste die Datei gemäß dem "tmpdir" nicht auf /tmp/ erstellt werden und dann nur dahin verschoben werden? --- falls das möglich ist, wäre das sowieso viel besser und schneller. Hätte gedacht, dass "tmpdir" genau dafür gedacht ist.

Wie hängen die Order zusammen? Was mache ich falsch? Kann ein Prozess in dem Container dafür verantwortlich sein? Aber wieso wird dann die .tar.dat Datei größer? Wieso sehe ich aber auch keinen Fortschritt dieser .tar.dat Datei in der Backup Ausgabe, wie es bei den anderen VMs auch ist?

Danke für euren Support!

 

[oguz]

ich vermute deine backups sind vielleicht zu gross fuer deinen /tmp ordner, und deswegen funkt es nicht.

vielleicht kannst du probieren, das tmpdir auf deinem NFS ordner zu setzen. z.b. /tmpdir: /mnt/pve/your/nfs/share

wenn moeglich auch bei dem NFS server die 'no_squash_root' option aktivieren. (um permissionprobleme zu vermeiden)

 

[j0k4b0]

/tmp/ hat eine Größe von 500GB und der Container ist kleiner als 10GB.

Hier mal mein NFS Exports:

/backups/proxmox/pvec01 10.0.0.128/26(rw,sync,no_root_squash,no_all_squash)

Habe dennoch mal das tmp dir auf das NFS geändert und das Backup neu gestartet. 1zu1 das gleiche Verhalten wie oben beschrieben.

 

[j0k4b0]

Krass. Absolut krass.
Hier mal der Output, Backup ist fertig:

INFO: starting new backup job: vzdump 125 --node fra1-pvec01-m03 --compress lzo --remove 0 --mode snapshot --storage fra1-nfs1-pvec01
INFO: Starting Backup of VM 125 (lxc)
INFO: Backup started at 2020-05-19 14:18:07
INFO: status = running
INFO: CT Name: fra1-dbc01-m04.prod.<name>.intern
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: create storage snapshot 'vzdump'
INFO: creating archive '/mnt/pve/fra1-nfs1-pvec01/dump/vzdump-lxc-125-2020_05_19-14_18_07.tar.lzo'
INFO: Total bytes written: 23293286400 (22GiB, 1.1MiB/s)
INFO: archive file size: 7.59GB
INFO: remove vzdump snapshot
INFO: Finished Backup of VM 125 (06:01:53)
INFO: Backup finished at 2020-05-19 20:20:00
INFO: Backup job finished successfully
TASK OK

Muss jetzt mal prüfen wieso der nur mit 1.1MiB/s schreibt. Das ist super wenig. Richtig krass. Und wieso sind das 22GB Backup wenn die VM gerade mal 9GB groß ist? Was ist da falsch?

Lg

Edit.
Frage mich wieso da kein prozentualer Fortschritt zu sehen ist. :O