Backup Job legt die Maschine "lahm"

Priberius

Member
Dec 9, 2020
6
1
23
35
Moin,

ich habe das Problem das bei einigen VM das Backup die komplette VM während des Backups lahm legt, bei anderen überhaupt nicht. Ich habe da noch keine Systematik erkannt.

Hat irgendjemand ne Idee ?
 
Moin,

ich habe das Problem das bei einigen VM das Backup die komplette VM während des Backups lahm legt, bei anderen überhaupt nicht. Ich habe da noch keine Systematik erkannt.

Hat irgendjemand ne Idee ?
Das liegt ganz einfach am Schreibverhalten deiner VM und der Geschwindigkeit deines PBS. Ganz pauschal, dein PBS ist falsch gesized und zu langsam.
 
  • Like
Reactions: news
Ich häng mich mal dran – ich habe genau das gleiche Problem mit unseren RDP-Servern.
Sobald das Backup läuft, ist ein vernünftiges Arbeiten auf den Servern kaum noch möglich.
VDIs machen dagegen überhaupt keine Probleme.
 
Das liegt ganz einfach am Schreibverhalten deiner VM und der Geschwindigkeit deines PBS. Ganz pauschal, dein PBS ist falsch gesized und zu langsam

Moin,

erstmal vielen Dank für deine Antwort.
Ich habe Fragen zu deiner Antwort

1. Was genau meinst Du mit Schreibverhalten meiner VM ?
Zur Info das sind Windows VMs: wo RDP drauf läuft. Jetzt haben wir einige VMs auf der gleichen Node die das nicht juckt wenn Du ein Backup machst, andere sind währenddessen fast wie eingefroren. Die VMS werden alle auf dem gleichen PBS gesichert der über VLAN 1 GBit angebunden ist. Die Backups sind alle auf Snapshot eingestellt und auf jeder VM sind die Virtio Treiber sowie QEMU Guest Agent installiert. Ich würde behaupten die VMs unterscheiden sich nicht von der Config....

Desweiteren will mir nicht einleuchten weshalb das am PBS liegen soll . Der PBS läuft auf nem eigenen blech , Die Hardware ist n Ryzen 7 3700X, mit 64GB ECC RAM, 1 TB NVMEfür den PBS , und Storage 4x22TB WD Datacenter SATA . Der Storage ist mit ZFS als Raidz1 konfiguriert.
 
  • Like
Reactions: Oachkatze
Moin,

erstmal vielen Dank für deine Antwort.
Ich habe Fragen zu deiner Antwort

1. Was genau meinst Du mit Schreibverhalten meiner VM ?
Zur Info das sind Windows VMs: wo RDP drauf läuft. Jetzt haben wir einige VMs auf der gleichen Node die das nicht juckt wenn Du ein Backup machst, andere sind währenddessen fast wie eingefroren. Die VMS werden alle auf dem gleichen PBS gesichert der über VLAN 1 GBit angebunden ist. Die Backups sind alle auf Snapshot eingestellt und auf jeder VM sind die Virtio Treiber sowie QEMU Guest Agent installiert. Ich würde behaupten die VMs unterscheiden sich nicht von der Config....

Desweiteren will mir nicht einleuchten weshalb das am PBS liegen soll . Der PBS läuft auf nem eigenen blech , Die Hardware ist n Ryzen 7 3700X, mit 64GB ECC RAM, 1 TB NVMEfür den PBS , und Storage 4x22TB WD Datacenter SATA . Der Storage ist mit ZFS als Raidz1 konfiguriert.
Hey Priberius

Hast du schon mal probiert im PVE in den Optionen - QUEM die Option : Freeze/thaw guest filesystems on backup for consistency zu deaktiveren.
Wäre super, wenn du das mal testen könntest, ich kann gerade kein Backup Starten.

Gib mir bitte kurz Bescheid

LG
 
Moin,

erstmal vielen Dank für deine Antwort.
Ich habe Fragen zu deiner Antwort

1. Was genau meinst Du mit Schreibverhalten meiner VM ?
Wenn deine VM viel schreibt, während des Backups, dann wird diese durch das Backup mehr genremst. Denn jeder Block, der von der VM während des Backups geschrieben wird, wird zuerst auf den PBS geschrieben und wenn der fertig ist, erst auf dein Storage.
Zur Info das sind Windows VMs: wo RDP drauf läuft. Jetzt haben wir einige VMs auf der gleichen Node die das nicht juckt wenn Du ein Backup machst, andere sind währenddessen fast wie eingefroren. Die VMS werden alle auf dem gleichen PBS gesichert der über VLAN 1 GBit angebunden ist. Die Backups sind alle auf Snapshot eingestellt und auf jeder VM sind die Virtio Treiber sowie QEMU Guest Agent installiert. Ich würde behaupten die VMs unterscheiden sich nicht von der Config....

Desweiteren will mir nicht einleuchten weshalb das am PBS liegen soll . Der PBS läuft auf nem eigenen blech , Die Hardware ist n Ryzen 7 3700X, mit 64GB ECC RAM, 1 TB NVMEfür den PBS , und Storage 4x22TB WD Datacenter SATA . Der Storage ist mit ZFS als Raidz1 konfiguriert.
Da beschreibst du Perfekt wie ein PBS niemals aussehen sollte.
Der PBS ist durch seine Deduplizierung für Flash Speicher optimal. Mit HDDs geht das notfalls auch, aber bremst dann schon etwas.
Die großen SATA HDDs schreiben eh langsam, vor allem bei Random I/O. Dazu hast du noch ein RaidZ gebaut, womit die HDDS noch einmal maximal gebremst werden.

Das einzige was dir noch helfen kann ist eine SSD im PVE und du richtest das fleecing ein, wie Chris oben schon erwähnt hat.
 
Wenn deine VM viel schreibt, während des Backups, dann wird diese durch das Backup mehr genremst. Denn jeder Block, der von der VM während des Backups geschrieben wird, wird zuerst auf den PBS geschrieben und wenn der fertig ist, erst auf dein Storage.

Da beschreibst du Perfekt wie ein PBS niemals aussehen sollte.
Der PBS ist durch seine Deduplizierung für Flash Speicher optimal. Mit HDDs geht das notfalls auch, aber bremst dann schon etwas.
Die großen SATA HDDs schreiben eh langsam, vor allem bei Random I/O. Dazu hast du noch ein RaidZ gebaut, womit die HDDS noch einmal maximal gebremst werden.

Das einzige was dir noch helfen kann ist eine SSD im PVE und du richtest das fleecing ein, wie Chris oben schon erwähnt hat.
Danke für die Info, Falk!

Ich habe mich ein wenig zum Thema fleece eingelesen und es auch auf meinem Testsystem ausprobiert.

Dabei ist mir aufgefallen, dass beim Erstellen eines Backups wie erwartet eine Fleece-Datei erzeugt wird. Interessanterweise wird diese Fleece-Datei bei ausgeschalteten Maschinen aber nicht mehr automatisch gelöscht – sie bleibt als RAW-Datei bestehen.

Gibt es dafür einen bestimmten Grund?

1750228347792.png

Außerdem noch eine Frage zur Funktionsweise:
Soweit ich verstanden habe, werden im Fleece-Image nur die Änderungen gespeichert, die während des Backups auf der laufenden Maschine entstehen.
Ist es normal, dass dabei dennoch eine Fleece-Datei in voller Plattengröße (RAW) erzeugt wird, auch wenn nur wenige Änderungen angefallen sind?

Danke dir im Voraus!
 
Ich habe bisher kein Feecing im Einsatz, da ich immer SSDs verbaue und PBS mit HDDs nur als Sekundärbackups benutze.
Eventuell kann @Chris etwas dazu sagen warum die Dateien liegen bleiben.
 
Danke für die Info, Falk!

Ich habe mich ein wenig zum Thema fleece eingelesen und es auch auf meinem Testsystem ausprobiert.

Dabei ist mir aufgefallen, dass beim Erstellen eines Backups wie erwartet eine Fleece-Datei erzeugt wird. Interessanterweise wird diese Fleece-Datei bei ausgeschalteten Maschinen aber nicht mehr automatisch gelöscht – sie bleibt als RAW-Datei bestehen.

Gibt es dafür einen bestimmten Grund?
Bitte den kompletten Backup task log sowie den output von cat /etc/pve/storage.cfg posten, die fleecing images werden nach erfolgreichem Backup normalerweise aufgeräumt, ja.

View attachment 87229

Außerdem noch eine Frage zur Funktionsweise:
Soweit ich verstanden habe, werden im Fleece-Image nur die Änderungen gespeichert, die während des Backups auf der laufenden Maschine entstehen.
Ist es normal, dass dabei dennoch eine Fleece-Datei in voller Plattengröße (RAW) erzeugt wird, auch wenn nur wenige Änderungen angefallen sind?
Ja, da a-priori nicht festgestellt werden kann wie viel Speicher zum lokalen Zwischenspeichern benötigt wird. Daher ist auch die Empfehlung das auf einem thin provisioned storage zu haben, sodass nur on-demand Speicher alloziert werden muss.
 
Ja, da a-priori nicht festgestellt werden kann wie viel Speicher zum lokalen Zwischenspeichern benötigt wird. Daher ist auch die Empfehlung das auf einem thin provisioned storage zu haben, sodass nur on-demand Speicher alloziert werden muss.

Chris

Okay, super – das hatte ich mir schon fast gedacht.

Im Anhang findest du das Backup-Log – das Backup läuft erfolgreich durch.
Interessanterweise bleibt bei den ausgeschalteten VMs die Fleecing-Datei dennoch bestehen.
Ich habe sie jetzt manuell über die CLI gelöscht – das funktioniert einwandfrei.

1750328199423.png


Hier noch die storage.cfg


Code:
dir: local
        path /var/lib/vz
        content iso,snippets,vztmpl,import,backup,rootdir
        shared 0

zfspool: local-zfs
        pool rpool/data
        content rootdir,images
        sparse 1

pbs: PBS
        datastore backup
        server 10.75.0.40
        content backup
        fingerprint 86:6d:c8:d3:e5:c5:99:49:c9:08:e4:04:c1:f3:c8:ef:38:7d:a5:13:c2:7b:5d:53:2f:c3:45:54:d8:0b:a8:8c
        prune-backups keep-all=1
        username ########

iscsi: ProxmoxiSCSi
        disable
        portal 10.75.0.254
        target iqn.2000-01.com.synology:Valley.default-target.771e94ea939
        content images

nfs: TestNFS
        export /volume2/TestOrdner
        path /mnt/pve/TestNFS
        server 10.75.0.254
        content vztmpl,import,images,backup,rootdir,iso,snippets
        prune-backups keep-all=1

pbs: TESTPBS
        disable
        datastore backup
        server 192.168.0.15
        content backup
        fingerprint 86:6d:c8:d3:e5:c5:99:49:c9:08:e4:04:c1:f3:c8:ef:38:7d:a5:13:c2:7b:5d:53:2f:c3:45:54:d8:0b:a8:8c
        namespace test
        prune-backups keep-all=1
        username #######
 

Attachments

Ah ja, für gestoppte VMs gab es dieses issue https://bugzilla.proxmox.com/show_bug.cgi?id=6317

Der bugfix wurde mit qemu-server version 8.3.13 ge-packaged, diese version ist zu diesem Zeitpunkt nur via pvetest repo verfügbar.
Ahh Oke super :-) danke für die Info Chris, was ich sehe sollte speichertechnisch nichts belegt werden.

Ich werde es mal probieren mit einer VM bei einer unserer Kunden und mal schauen ob das Arbeiten auf einer RDP besser geht :-)