Probleme mit Proxmox 6.4-13 LVM & Backup

Azrael14

Member
Jan 16, 2022
9
0
6
42
Hallo zusammen und einen schönen Sonntag Abend,



gleich mal eine Vorwarnung: Viel Text und ich glaube nicht gut strukturiert, ich versuche am Ende des Textes die Fragen noch mal kurz und bündig zusammen zu fassen.

Ich packe mal eine ganze Menge Screenshots mit dazu, in der Hoffnung ihr könnt euch ein Gesamtbild über mein Problem machen.



Ich habe seit ein paar Wochen bereits Probleme mit meinem Proxmox bzw. dem LVM „Verzeichnis“.

Leider sind meine Linux Kenntnisse Grundsätzlich eher schlecht und als klassischer Windows Admin verstehe ich das Konstrukt „LVM“ glaube ich immer noch nicht ganz.



Ich habe 2 Festplatten in einem Intel NUC welcher via Proxmox 6.4-13 in Betrieb. Eine interne 500GB SSD und eine 2 TB HDD extern angeschlossen.

Auf die Interne SSD habe ich damals das vorgefertigte Proxmox Image aufgebracht, leider ohne mich weiter mit den Grundlagen zu beschäftigen. Die 2 TB HDD ist ext4 formatiert. Auf dieser laufen mittlerweile VMs, CTs und es werden Backups dort abgelegt.

Die lokale SSD sollte primär für VMs und CTs verwendet werden, dies war auch so, bis es zu meinem „Problem“ kam.



Nun ist es so, dass der LVM „Ordner“ zu 97% gefüllt ist, und ich dort nicht freigeben kann, egal wo ich VMs / CTs hin verschiebe oder wie ich diese einbinde. Als ich das „Problem“ bekommen habe warn im LVM 11x LV abgelegt und angezeigt.

Diese habe ich mittlerweile aufgeräumt, bereinigt und unnötiges weggelöscht. Mittlerweile bin ich bei 7x LV im LVM „Verzeichnis“ jedoch wurde keine bisschen Kapazität frei gegeben.



Dies führt dazu das die Backups meiner größeren Datenbankmaschinen (Influx & Prostgre) leider fehlschlagen.
Die würde ich gerne schnellstmöglich beheben. Und auch das Datenablagekonstrukt aufräumen und richtig gestalten.



Hierbei bekomme ich folgende Meldung beim automatischen Job:

INFO: starting new backup job: vzdump 100 --node nuc --compress gzip --remove 0 --mode snapshot --storage Extern2TB

INFO: Starting Backup of VM 100 (lxc)

INFO: Backup started at 2021-12-31 11:42:19

INFO: status = running

INFO: CT Name: Influxdb

INFO: including mount point rootfs ('/') in backup

INFO: backup mode: snapshot

INFO: ionice priority: 7

INFO: create storage snapshot 'vzdump'


WARNING: You have not turned on protection against thin pools running out of space.

WARNING: Set activation/thin_pool_autoextend_threshold below 100 to trigger automatic extension of thin pools before they get full.

Logical volume "snap_vm-100-disk-0_vzdump" created.

WARNING: Sum of all thin volume sizes (394.00 GiB) exceeds the size of thin pool pve/data and the amount of free space in volume group (12.54 GiB).

INFO: creating vzdump archive '/mnt/pve/Extern2TB/dump/vzdump-lxc-100-2021_12_31-11_42_19.tar.gz'

INFO: tar: ./var/cache/man/ru/cat8/: Cannot savedir: Bad message

INFO: Total bytes written: 65421742080 (61GiB, 33MiB/s)

INFO: tar: Exiting with failure status due to previous errors

INFO: cleanup temporary 'vzdump' snapshot


Logical volume "snap_vm-100-disk-0_vzdump" successfully removed

ERROR: Backup of VM 100 failed - command 'set -o pipefail && tar cpf - --totals --one-file-system -p --sparse --numeric-owner --acls --xattrs '--xattrs-include=user.*' '--xattrs-include=security.capability' '--warning=no-file-ignored' '--warning=no-xattr-write' --one-file-system '--warning=no-file-ignored' '--directory=/mnt/pve/Extern2TB/dump/vzdump-lxc-100-2021_12_31-11_42_19.tmp' ./etc/vzdump/pct.conf ./etc/vzdump/pct.fw '--directory=/mnt/vzsnap0' --no-anchored '--exclude=lost+found' --anchored '--exclude=./tmp/?*' '--exclude=./var/tmp/?*' '--exclude=./var/run/?*.pid' ./ | gzip --rsyncable >/mnt/pve/Extern2TB/dump/vzdump-lxc-100-2021_12_31-11_42_19.tar.dat' failed: exit code 2

INFO: Failed at 2021-12-31 12:14:28

INFO: Backup job finished with errors

TASK ERROR: job errors




Oder diese Meldungen wenn ich manuell Starte:

INFO: starting new backup job: vzdump 100 --remove 0 --mode snapshot --storage Extern2TB --node nuc --compress gzip --mailto abc@edf.com
INFO: Starting Backup of VM 100 (lxc)
INFO: Backup started at 2022-01-16 18:27:47
INFO: status = running
INFO: CT Name: InfluxDB2022
INFO: including mount point rootfs ('/') in backup
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: create storage snapshot 'vzdump'
Logical volume "snap_vm-100-disk-0_vzdump" created.
INFO: creating vzdump archive '/mnt/pve/Extern2TB/dump/vzdump-lxc-100-2022_01_16-18_27_47.tar.gz'
INFO: tar: ./var/cache/man/ru/cat8/: Cannot savedir: Bad message
INFO: Total bytes written: 80549959680 (76GiB, 36MiB/s)
INFO: tar: Exiting with failure status due to previous errors
INFO: cleanup temporary 'vzdump' snapshot
Logical volume "snap_vm-100-disk-0_vzdump" successfully removed
ERROR: Backup of VM 100 failed - command 'set -o pipefail && tar cpf - --totals --one-file-system -p --sparse --numeric-owner --acls --xattrs '--xattrs-include=user.*' '--xattrs-include=security.capability' '--warning=no-file-ignored' '--warning=no-xattr-write' --one-file-system '--warning=no-file-ignored' '--directory=/mnt/pve/Extern2TB/dump/vzdump-lxc-100-2022_01_16-18_27_47.tmp' ./etc/vzdump/pct.conf ./etc/vzdump/pct.fw '--directory=/mnt/vzsnap0' --no-anchored '--exclude=lost+found' --anchored '--exclude=./tmp/?*' '--exclude=./var/tmp/?*' '--exclude=./var/run/?*.pid' ./ | gzip --rsyncable >/mnt/pve/Extern2TB/dump/vzdump-lxc-100-2022_01_16-18_27_47.tar.dat' failed: exit code 2
INFO: Failed at 2022-01-16 19:04:05
INFO: Backup job finished with errors
TASK ERROR: job errors






Nachdem ich den CT dann auf die Externe Platte gelegt hatte, bekam ich folgende Fehlermeldungen welche vermutlich darauf hindeuten das Snapshots auf ext4 nicht klappen, hier habe ich noch nicht weiter gelesen da ich dies auch eigentlich wieder auf der lokalen SSD haben möchte.





Detailed backup logs:

vzdump 110 --compress gzip --remove 0 --storage Extern2TB --mode snapshot --node nuc --mailto …






110: 2022-01-16 14:55:51 INFO: Starting Backup of VM 110 (lxc)

110: 2022-01-16 14:55:51 INFO: status = running

110: 2022-01-16 14:55:51 INFO: CT Name: influx

110: 2022-01-16 14:55:51 INFO: including mount point rootfs ('/') in backup

110: 2022-01-16 14:55:51 INFO: mode failure - some volumes do not support snapshots

110: 2022-01-16 14:55:51 INFO: trying 'suspend' mode instead

110: 2022-01-16 14:55:51 INFO: backup mode: suspend

110: 2022-01-16 14:55:51 INFO: ionice priority: 7

110: 2022-01-16 14:55:51 INFO: CT Name: influx

110: 2022-01-16 14:55:51 INFO: including mount point rootfs ('/') in backup

110: 2022-01-16 14:55:51 INFO: starting first sync /proc/12295/root/ to /mnt/pve/Extern2TB/dump/vzdump-lxc-110-2022_01_16-14_55_51.tmp

110: 2022-01-16 15:31:05 ERROR: Backup of VM 110 failed - command 'rsync --stats -h -X -A --numeric-ids -aH --delete --no-whole-file --sparse --one-file-system --relative '--exclude=/tmp/?*' '--exclude=/var/tmp/?*' '--exclude=/var/run/?*.pid' /proc/12295/root//./ /mnt/pve/Extern2TB/dump/vzdump-lxc-110-2022_01_16-14_55_51.tmp' failed: exit code 23






Meinem Verständnis nach ist LVM also ein Virtuelles / Logisches Verzeichnis welches eine Größe von 500GB fassen kann. Diese sind aufgrund der LV welche mir unter „lvdisplay“ angezeigt werden offenbar voll obwohl keine der Festplatten voll ist (Zumindest meinem Verständnis nach). Daher scheitern aber meine Backups und ich kann das nicht ohne weiteres bereinigen.



Nach meinen Recherchen wäre es nun möglich das LVM zu vergrößern auf z.B. 1TB, und die Images der CTs/VMs einfach weiter manuell zu verteilen. Da es nur virtuell ist kann ich die Platten weiter „ausgewogen“ belasten und befüllen. Ist das so richtig? Ich lese überall, wenn ich das LVM nun über 2 Festplatten erstrecke und auf z.B. 1TB festlege würde Proxmox entscheiden wo es was ablegt. Verliert man da nicht völlig den überblick und die Kontrolle?














So nun noch mal der Versuch das ganze in kurz und knapp:



  • Ist es möglich bei meinen Festplatten / Partitionssituation das LVM zu vergrößern, um Proxmox inkl. Backup Jobs wieder vollumfänglich nutzen zu können?
  • Ist es Sinnvoll den LVM über mehrere (physikalische) Festplatten zu erweitern? Oder sollte ich das Problem anders angehen? Die Kapazitäten auf den Festplatten sind denke ich vorhanden und frei. -Hier bin ich mir nur auch gar nicht ganz sicher
  • Sind die Fehler „Cannot savedir: Bad message“ im Backup tatsächlich aufs LVM zurückzuführen oder gibt’s hier noch andere Ansätze für die Fehlersuche?


Ich hoffe jemand hat Zeit und Lust das zu lesen und mich zu unterstützen.

Wenn mehr Informationen benötigt werden, liefere ich diese natürliche gerne nach. Auch könnte man sich gern via Discord / Fernwartung austauschen.



Vielen Dank bis hier her & viele Grüße

Alexander
 

Attachments

  • df-h.png
    df-h.png
    19.2 KB · Views: 2
  • lsblk.png
    lsblk.png
    41.1 KB · Views: 2
  • lvdisplay-1.png
    lvdisplay-1.png
    98 KB · Views: 2
  • lvdisplay-2.png
    lvdisplay-2.png
    40.4 KB · Views: 2
  • LVM97.png
    LVM97.png
    49.7 KB · Views: 2
  • pvdisplay.png
    pvdisplay.png
    18.1 KB · Views: 2
  • Storage Ext2TB.png
    Storage Ext2TB.png
    119.6 KB · Views: 2
  • Storage Local.png
    Storage Local.png
    115.9 KB · Views: 2
  • Storage Local-lvm.png
    Storage Local-lvm.png
    119.5 KB · Views: 2
  • Übersicht.png
    Übersicht.png
    79.8 KB · Views: 2
Last edited:
Hallo,
Nun ist es so, dass der LVM „Ordner“ zu 97% gefüllt ist, und ich dort nicht freigeben kann, egal wo ich VMs / CTs hin verschiebe oder wie ich diese einbinde. Als ich das „Problem“ bekommen habe warn im LVM 11x LV abgelegt und angezeigt.
Die Screenshots zeigen, dass 97% der physischen Platte der Volume Group pve zugewiesen sind (EDIT: das bedeutet nicht, dass dieser Speicher auch schon innerhalb der Volume Group in Benutzung ist). Bei local-lvm ist die Auslastung viel geringer. Für detailierte Auslastung, das Kommando lvs benutzen, siehe hier für eine kurze Erklärung (leider auf Englisch).

  • Sind die Fehler „Cannot savedir: Bad message“ im Backup tatsächlich aufs LVM zurückzuführen oder gibt’s hier noch andere Ansätze für die Fehlersuche?
Ich vermute, dass der Fehler nicht wegen LVM ist. Bitte versuchen einen file system check vom Container (mit pct fsck <ID>) zu machen, siehe hier.
 
Last edited:
Hallo Fabian,

vielen Dank fürs durchlesen meiner Fragen und für Deine Antwort.
Danke auch für die Aufklärung bzgl. LVM. Sollte man hieran was verändern? Wenn ich das richtig verstanden habe ist die anzeige in "local-lvm" dann die tatsächlich genutzte Kapazität des LVM (und damit eben der zugewiesenen 97% von pve).


Du hattest recht, Proxmox bzw. LVM war nicht das Problem. Nachdem ich "pct fsck" über die beiden CTs hab laufen lassen klappt das Backup wieder. Die Meldung ist identisch mit denen aus dem von Dir verlinkten Beitrag.

Kann ich etwas unternehmen um dieses Inode Problem nicht wieder zu bekommen?

Und gibt es eine Möglichkeit auch VMs zu überprüfen? Bzw. besteht da überhaupt die Notwendigkeit? Oder verhält sich das anders wenn da diese nicht auf die gleiche Art auf die Host-Ressourcen zugreifen?

Bei beiden Maschinen wird mir auch "command 'fsck -a -l /dev/pve/vm-100-disk-0' failed: exit code 1" zurück geliefert wie im verlinkten Beitrag. Muss ich mir hierzu sorgen machen?



Schon jetzt vielen Dank, ich kann endlich wieder saubere Backups erstellen!

Viele Grüße
Alexander
 
Hallo Fabian,

vielen Dank fürs durchlesen meiner Fragen und für Deine Antwort.
Danke auch für die Aufklärung bzgl. LVM. Sollte man hieran was verändern? Wenn ich das richtig verstanden habe ist die anzeige in "local-lvm" dann die tatsächlich genutzte Kapazität des LVM (und damit eben der zugewiesenen 97% von pve).
97% des physikalischen Disk sind der Volume Gruppe pve zugewiesen. Die Volume Gruppe selbst weist das dann logischen Volumen zu. Im Grunde kannst Du auch noch die letzten 3% der Volume Gruppe verfügbar machen. Mit vgs siehst Du in der VFree-Spalte wie viel Speicher noch bestimmten LVen zugewiesen werden kann. Schadet auch nicht, falls ein bisschen frei ist für Notfälle. Die "echte" Auslastung ist allerdings auf den logischen Volumen selbst, je nachdem wie es eben wird (z.B. als Dateisystem wie pve/root oder als Thin-Pool).

Du hattest recht, Proxmox bzw. LVM war nicht das Problem. Nachdem ich "pct fsck" über die beiden CTs hab laufen lassen klappt das Backup wieder. Die Meldung ist identisch mit denen aus dem von Dir verlinkten Beitrag.

Kann ich etwas unternehmen um dieses Inode Problem nicht wieder zu bekommen?
Schwer zu sagen was zu der Inkonsistenz geführt hat, aber z.B. sauberen Shutdown machen statt Stoppen, etc. ist immer gut.

Und gibt es eine Möglichkeit auch VMs zu überprüfen? Bzw. besteht da überhaupt die Notwendigkeit? Oder verhält sich das anders wenn da diese nicht auf die gleiche Art auf die Host-Ressourcen zugreifen?

Bei beiden Maschinen wird mir auch "command 'fsck -a -l /dev/pve/vm-100-disk-0' failed: exit code 1" zurück geliefert wie im verlinkten Beitrag. Muss ich mir hierzu sorgen machen?
Bei VMs sollte der fsck innerhalb der virtuellen Maschine stattfinden (wenn Du es auf dem Host machen willst, vorher feststellen wo genau das Dateisystem ist, vermutlich auf einer Partition?).

Schon jetzt vielen Dank, ich kann endlich wieder saubere Backups erstellen!

Viele Grüße
Alexander
 

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!

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!