vzdump status unkown nachdem NFS mount crashte

[HBO]

Guten Morgen,

während einiger Backups ist der NFS Mount gestorben, das System ist auch nicht wieder online zu bekommen (Hardware Problem). Ich hatte nun den NFS Mount mit "umount -l mountpunkt" entfernen müssen und habe diesen auf einem anderen NFS Mount wieder angelegt.
Das Backup lief trotzdem nicht weiter, entsprechend versuchte ich den vzdump Prozess zu beenden über das GUI (ohne Erfolg). Den Prozess hatte ich nun per Konsole gekillt, es bleiben aber 2 Prozesse jeweils stehen:
task UPID:mc2-node3:00007305:7852BE8E:595965D9:vzdump::root@pam:
\_ lzop

Im GUI sind die Prozesse auch noch laufend, allerdings mit dem Status "unknown".

Bekomme ich die Prozesse nun irgendwie beendet, sodass die Backups mit dem neuen NFS Mount heute Nacht wieder laufen können?

*edit*
Die offenen Backup Jobs hängen weiterhin, haben aber wieder den Status "running" und die korrekte PID wird angezeigt. Ein "STOP" im GUI oder "kill -9 PID" bringt allerdings keinen Erfolg.

 

[fireon]

Ja das Problem kenne ich nur zu gut. Passiert nur dann wenn die während dem Backup die Backupmaschine stirbt. Der Prozess ist technisch nur durch einen Reboot/Reset der Hostmaschine zu beenden. Da das I/O im Kernel selbst wartet, und ist es mal da drinne gehts auch nicht mehr raus. Deswegen hat das Teil auch den Namen "NFS-Kernel-Server". Es gibt jede Menge Optionen für Timeouts, aber das kannste vergessen. Ich hab das hier im Forum schon mal wo ausführlich behandelt, konnte jetzt aber den Beitrag nicht finden.

Fakto: Du musst schauen das eine Backupmaschine läuft. Hängt sich das Teil während dem Backup auf, ist es Pech. Technisch nicht lösbar. Wir setzten aber trotzdem überall NFS ein, ist halt mal am schnellsten. Und Ausfälle hatten wir in den letzten Jahren vielleicht bei allen Kunden (und das sind viele) 3. Das ist leicht verschmerzbar.

Aber wo auch das zu viel ist und du mit Performanceeinbußen zu recht kommst, nimmste Samba, dort das du das Problem nicht. So machen wir das auch.

 

[HBO]

Schonmal SMB hinter einem 10GE Netzwerk getestet was dabei rum kommt? Ich hatte das auch nun durch einen Reboot gelöst, allerdings ist es ziemlich unschön den Kunden (da laufen bis zu 70 VMs) eine Wartung aufzudrücken um dem Host einen Reboot geben zu können.

Über das NFS haben wir derzeit eine maximale Schreibgeschwindigkeit von 375MB/s, mehr gibt das NAS dahinter sowieso nicht her. Sollte das mit SMB erreichbar sein würde ich hier einfach wechseln.

 

[fireon]

Über das NFS haben wir derzeit eine maximale Schreibgeschwindigkeit von 375MB/s, mehr gibt das NAS dahinter sowieso nicht her. Sollte das mit SMB erreichbar sein würde ich hier einfach wechseln.

Ja würd ich auf jeden Fall mal probieren. Liegt hier bei uns wohl ach daran das wir überall PVE als Storage und Backup verwenden. Bei der Debianversion ist ne buggy Sambaversion enthalten. Naja normal nutzen wir so ein Zeugs nicht, aber da kann man dann nicht aus, bei PVE5 (ja neues Debian) wird es das Problem wohl nicht geben. Zeitlich gesehen braucht der Samba um ein drittel mehr Sicherungszeit.

Aber sei gewarnt! Du nutzt Samba in einer gesicherten Umgebung. Wirklich gut absichern mit Passwort/Verschlüsselung und vor allem Zugriff nur von den PVE IP's. Locky und Co. falls Publiclaufwerke macht davon natürlich auch nicht halt.

 

[HBO]

Keine Sorge, allein das PVE Netz ist so schon per VLAN getrennt und das Interface nur per Reverse Proxy und per VPN erreichbar.
Das Backup Netz ist nochmal per VLAN getrennt und sowieso nur Intern erreichbar durch die Nodes selbst. Ich werde das wohl mal testen, vielleicht klappts ja.