[SOLVED] PBS zerlegt PVE VMs...

[itNGO]

Hallo,
wir haben hier folgende Konstellation.

PVE-Server am Standort und PBS-Server Remote.
Der PBS und der PVE sind über Internet Verbunden. Ca. 400MBit.
Von Zeit zu Zeit kommt es vor, das der PBS nicht erreichbar oder nur "sehr" Langsam erreichbar ist. Der Internet-Provider hat da manchmal so "Phasen"....

Nun passiert es das der BackupJob dann bis in den Tag hinein läuft. Das stört den Kunden natürlich und er drückt im Backup-Job am PVE die STOP-Taste.
Der Backup-Prozess wird also abgebrochen. Das zerlegt immer mal wieder das NTFS-Dateisystem der Gäste. Es ist dann ein CHKDSK erforderlich. Bis lang war es immer reparabel. Heute ist aber eine VM so defekt, das ein älteres Backup zurückgespielt werden muss.

Frage: Sollte es nicht so sein das nach dem Freeze-Thaw die VM gar nix mehr davon mitbekommt das da ein Backup läuft und/oder ggf. abgebrochen wird?

QEmu-Agent ist installiert und der Backup-Modus ist SnapShot....

 

[fiona]

Hi,

Frage: Sollte es nicht so sein das nach dem Freeze-Thaw die VM gar nix mehr davon mitbekommt das da ein Backup läuft und/oder ggf. abgebrochen wird?

leider nein, das Freeze-Thaw ist nur dazu da, dass das Filesystem im konsistenten Status ist, sobald das Backup beginnt. Bei der Art wie das Backup implementiert ist, wird immer wenn der Gast einen neuen Schreibvorgang macht, zuerst geschaut, ob der relevante Block schon gesichert ist und wenn nicht, muss der alte Block vorher ins Backup geschrieben werden. Dadurch wird die IO im Gast durch die Backup-Geschwindigkeit limitiert.

Idealerweise sollte das Netzwerk für das Backup immer stabil sein. Möglicherweise könntest Du lokal einen PBS aufsetzen, und dann später mit Remotes und Sync auf den Haupt-PBS übertragen?

Relevante Bug-Reports und Feature-Requests um es zu verbessern:
https://bugzilla.proxmox.com/show_bug.cgi?id=3231
https://bugzilla.proxmox.com/show_bug.cgi?id=3631
https://bugzilla.proxmox.com/show_bug.cgi?id=4136

 

[itNGO]

Hi,

leider nein, das Freeze-Thaw ist nur dazu da, dass das Filesystem im konsistenten Status ist, sobald das Backup beginnt. Bei der Art wie das Backup implementiert ist, wird immer wenn der Gast einen neuen Schreibvorgang macht, zuerst geschaut, ob der relevante Block schon gesichert ist und wenn nicht, muss der alte Block vorher ins Backup geschrieben werden. Dadurch wird die IO im Gast durch die Backup-Geschwindigkeit limitiert.

Idealerweise sollte das Netzwerk für das Backup immer stabil sein. Möglicherweise könntest Du lokal einen PBS aufsetzen, und dann später mit Remotes und Sync auf den Haupt-PBS übertragen?

Relevante Bug-Reports und Feature-Requests um es zu verbessern:
https://bugzilla.proxmox.com/show_bug.cgi?id=3231
https://bugzilla.proxmox.com/show_bug.cgi?id=3631
https://bugzilla.proxmox.com/show_bug.cgi?id=4136

Ok, verstehe ich.
Könnte ein LXC auf dem Proxmox mit durchgereichter Platte den Zweck der "lokalen" Sicherung erfüllen, der anschliessend nen Sync an den Remote macht? Ich vermute mal so lässt sich das Latenz-Problem "umgehen"?

 

[fiona]

Am besten wäre natürlich ein dedizierter Server, ansonsten würde ich PBS eher als (am besten HA-managed) VM empfehlen, ist nicht wirklich designed um als Container zu laufen.

 

[xqlusive]

Wieso einfach wenn es auch kompliziert geht. Einfach PBS auf PVE installieren, dann Remote Sync.

 

[itNGO]

Wieso einfach wenn es auch kompliziert geht. Einfach PBS auf PVE installieren, dann Remote Sync.

Das Konstrukt gefällt mir persönlich nicht so gut. Ich hab jetzt ne VM mit PBS gegossen und die macht dann erst Lokal und dann ein Remote PBS das Sync-Backup. Die PBS-VM selbst kann ich dann wieder local mit vzdump wegsichern. Wenn dann der PVE mal kaputt geht, ist alles schnell wiederherzustellen.

 

[xqlusive]

Wenn es jetzt für Dich passt top. Hauptsache der Kunde muss nicht mehr das Knöpfchen drücken

 

[crmspezi]

Das Konstrukt gefällt mir persönlich nicht so gut. Ich hab jetzt ne VM mit PBS gegossen und die macht dann erst Lokal und dann ein Remote PBS das Sync-Backup. Die PBS-VM selbst kann ich dann wieder local mit vzdump wegsichern. Wenn dann der PVE mal kaputt geht, ist alles schnell wiederherzustellen.

Ok. Hätte ich nicht so gemacht, PBS in VM. Geht aber, wenn keine weitere Hardware da ist, besser als wenn es oft Probleme gibt. Oft spielt da die Investzurückhaltung vom Kunden mit rein. Kennen wir ja.

 

[Dunuin]

PBS im LXC klappt hier übrigens auch wunderbar. War mir auch lieber als bare metal neben PVE, weil es das Upgraden von PVE und sichern des PBS dann doch leichter macht. Hatte hier PBS sowohl als VM als auch als LXC und konnte da jetzt als LXC keine Nachteile feststellen (mal abgesehen von den typischen Limitationen wie schlechterer Isolation und fehlende Live-Migration).

@fiona:
Was könnte da denn als LXC z.B. Probleme machen? Irgendwas, worauf ich speziell achten sollte?

 

[fiona]

PBS im LXC klappt hier übrigens auch wunderbar. War mir auch lieber als bare metal neben PVE, weil es das Upgraden von PVE und sichern des PBS dann doch leichter macht. Hatte hier PBS sowohl als VM als auch als LXC und konnte da jetzt als LXC keine Nachteile feststellen (mal abgesehen von den typischen Limitationen wie schlechterer Isolation und fehlende Live-Migration).

@fiona:
Was könnte da denn als LXC z.B. Probleme machen? Irgendwas, worauf ich speziell achten sollte?

Wenn es für dich funktioniert, gut! Ja, die fehlende Isolation kann eben z.B. kosmetisches Probleme verursachen: https://forum.proxmox.com/threads/lxc-container-can-access-all-host-disks-but-shouldnt.129679/
Wirklich kritisches ist mir nicht bekannt, aber wir entwickeln PBS eben nicht dediziert als Container-Appliance.

 

[Zerstoiber]

@fiona, es wäre super wenn es da mal eine klar erkennbare Roadmap für gäbe. Kann man das Thema irgendwie hocheskalieren/priorisieren?

Dass die aktive Produktion während dem Backup auf den Backup-Storage umgeleitet wird, ist irgendwie murks und so wie man hier & in vielen anderen Threads & in den verlinkten Bugs sieht, führt es immer wieder zu Downtimes bis Datenverlust ("auf letztes Backup zurück").
Für professionelle Umgebungen eigentlich inakzeptabel, denn Backup-Systeme sind nunmal immer irgendwie "billiger/schlechter/älter/langsamer" als die Produktivsysteme.
Da wir auch regelmäßig-häufige Backups z.B. vieler aktiver VMs tagsüber brauchen, sehe ich da schon Probleme auf uns zukommen, die die Akzeptanz von PVE/PBS gefährden.
Dabei wäre es so schön, guten Gewissens byebye zu VMware und Veeam zu sagen und das Geld in Proxmox zu stecken ;-)

https://bugzilla.proxmox.com/show_bug.cgi?id=4136
Das klingt nach einem guten Weg - aber keine Aktivität diesbezüglich erkennbar (weder im Bug noch auf https://pbs.proxmox.com/wiki/index.php/Roadmap)

 

[Falk R.]

Dass die aktive Produktion während dem Backup auf den Backup-Storage umgeleitet wird, ist irgendwie murks und so wie man hier & in vielen anderen Threads & in den verlinkten Bugs sieht, führt es immer wieder zu Downtimes bis Datenverlust ("auf letztes Backup zurück").

Das ist aber eigentlich die geniale Funktion um unabhängig vom Storagetyp/Dateisystem inkrementell sichern zu können. Es wird ja nix umgeleitet, es wird nur gewartet, dass dein Backup die Daten weg gesichert hat.

Für professionelle Umgebungen eigentlich inakzeptabel, denn Backup-Systeme sind nunmal immer irgendwie "billiger/schlechter/älter/langsamer" als die Produktivsysteme.
Da wir auch regelmäßig-häufige Backups z.B. vieler aktiver VMs tagsüber brauchen, sehe ich da schon Probleme auf uns zukommen, die die Akzeptanz von PVE/PBS gefährden.
Dabei wäre es so schön, guten Gewissens byebye zu VMware und Veeam zu sagen und das Geld in Proxmox zu stecken ;-)

Produktiv bastelst du dir so etwas mit ner schlechten Leitung nicht zusanmen. Ich habe einige Kunden mit PBS die sehr glücklich sind.
Sogar bei den Kunden, die kein SSD PBS haben und wir einen alten Server für den PBS nutzen läuft das super stabil. Der Backupserver sollte am besten eine Layer2 Verbindung zu den PVE haben und ein klein wenig Schreibperformance (machen wir oft mit Hardware Raid und vernünftigem Cache).
Offsite Backups machen wir immer mit Remote Sync.
P.S. Veeam habe ich bei meinen Kunden nicht ganz abgelöst, wir nutzen den Veeam Agent noch für die Sicherung von einem DC und den SQL/Oracle Servern um granulare Restores durchführen zu können. Für DR und Filerestore ist der PBS deutlich besser und schneller.

https://bugzilla.proxmox.com/show_bug.cgi?id=4136
Das klingt nach einem guten Weg - aber keine Aktivität diesbezüglich erkennbar (weder im Bug noch auf https://pbs.proxmox.com/wiki/index.php/Roadmap)

 

[Zerstoiber]

Danke @Falk R. , ich muss mich da noch mal genauer reinfuxen, bisher hatte ich eigentlich gemeint (mehrfach gelesen zu haben) dass ein Teil des aktiven Schreibprozesses umgeleitet wird. Aber es ist so wie du es schreibst, habe ich auch noch mal oben genauer nachgelesen:
@fiona schrieb es ja auch - sorry, hab ich missgedeutet
Bei der Art wie das Backup implementiert ist, wird immer wenn der Gast einen neuen Schreibvorgang macht, zuerst geschaut, ob der relevante Block schon gesichert ist und wenn nicht, muss der alte Block vorher ins Backup geschrieben werden.

Sprich nicht das aktive Schreiben wird umgeleitet, wohlaber durch den Backupprozess "ausgebremst".
Dass es dabei aber immer wieder Probleme gibt bis hin zu zerschossenen Dateisystemen ist irgendwie "uncool", hier gibt es wirklich so viele Problemthreads dahingehend dass ich schon etwas Bauchschmerzen habe, ob uns das auch droht... (200TB, >100 VMs, mehrfach tagsüber incremental Backups)

VMware und Veeam macht es ja mit dem einfachen VMware Snapshot, wodurch eine temporäre zweite Disk erstellt wird in welche alle Änderungen reinlaufen. Sprich kein ausgebremstwerden durch die Geschwindigkeit des Backupsystems. Im Hintergrund kann Veeam dann in aller Ruhe aus dem unveränderlichen Read-Only Snapshot (also der Originaldisk) die Blöcke auslesen. Vorteil ist Geschwindigkeit, Nachteil ist, dass danach noch mal kurz die Änderungen gemerged werden - finde ich aber akzeptabler als NVME-Produktiv-Geschwindigkeit auf HDD-Backup-Geschwindigkeit bremsen zu lassen.

https://bugzilla.proxmox.com/show_bug.cgi?id=4136 klingt genau nach einer solchen Lösung

da wird in https://www.mail-archive.com/qemu-devel@nongnu.org/msg876056.html auch ausgeführt, was das bisherige Problem ist mit copy-before-write; image-fleecing klingt irgendwie schöner.

pull backup: QEMU only exports a kind of snapshot (for example by NBD), and third party 
software reads this export and stores it somehow, also called "external backup"

copy-before-write operations: We usually do backup of active disk, guest is
running and may write to the disk during the process of backup. When guest
wants to rewrite data region which is not backed up yet, we must stop this
guest write, and copy original data to somewhere before continuing guest write. 

image-fleecing: the technique that allows to export a "snapshotted" state of the active disk with help of 
copy-before-write operations. We create a temporary image - target for copy-before-write operations, and provide an 
interface to the user to read the "snapshotted" state. And for read, we do read from temporary image the data 
which is already changed in original active disk, and we read unchanged data directly from active disk. The temporary 
image itself is also called "reverse delta" or "reversed delta".

 

[Falk R.]

Dass es dabei aber immer wieder Probleme gibt bis hin zu zerschossenen Dateisystemen ist irgendwie "uncool", hier gibt es wirklich so viele Problemthreads dahingehend dass ich schon etwas Bauchschmerzen habe, ob uns das auch droht... (200TB, >100 VMs, mehrfach tagsüber incremental Backups)

Also ich betreue PVE Cluster mit bis zu 700 VMs, da haben wir bei vernünftigem Sizing nie Probleme. Die meisten Probleme lese ich hier im Forum mit Bastellösungen wie NFS hinter einem PBS und so.

VMware und Veeam macht es ja mit dem einfachen VMware Snapshot, wodurch eine temporäre zweite Disk erstellt wird in welche alle Änderungen reinlaufen. Sprich kein ausgebremstwerden durch die Geschwindigkeit des Backupsystems. Im Hintergrund kann Veeam dann in aller Ruhe aus dem unveränderlichen Read-Only Snapshot (also der Originaldisk) die Blöcke auslesen. Vorteil ist Geschwindigkeit, Nachteil ist, dass danach noch mal kurz die Änderungen gemerged werden - finde ich aber akzeptabler als NVME-Produktiv-Geschwindigkeit auf HDD-Backup-Geschwindigkeit bremsen zu lassen.

Da du ja in der Regel nur inkrements wegschreibst und bei ZFS ein COW Filesystem ist, hast du auch mit langsameren Disks im PBS kein echtes Problem im Produktivbetrieb. Deine NVMe muss ja mehr ackern, erst lesen bevor geschrieben werden kann und der PBS muss ja nur im Stream wegschreiben. Deshalb auch beim PBS immer schön Special Devices benutzen, wenn HDDs im Einsatz sind.
Der Snapshotmerge bei VMware hat in der Regel einen höheren Impact als das PBS Backup. (bei identischer Hardware getestet)

Warum eigentlich mehrfach täglich backups? Normalerweise reicht ja einmal täglich und die Logsicherung der DB Server alle 5 Minuten.

 

[Zerstoiber]

Danke @Falk R. , das klingt ernsthaft beruhigend und eine Bastellösung wird es bei uns definitiv nicht ;-)
Leider können wir aktuell nur mit Test-VMs evaluieren, erst wenn wir die große Migration auf Proxmox vollziehen, sehen wir, wie es wirklich läuft.
Ich habe brutal Bock drauf und Vertrauen in die Stabilität von Proxmox und Ceph, aber das Backup-Thema...

Warum mehrfach? Weil wegen wenn...
Mündliche Kunden-Daten werden aufgenommen und in Datenbanken, Office-Filerservern, etc. abgelegt.
Bei Datenverlust könnte gar nicht nachvollzogen werden, welche Menschen da ohne Termin am Schalter standen und welche Anträge/Zahlungen etc. gehandled wurden, Menschen würden auf Bearbeitung warten und es kommt nichts...

Datenverlust durch "hups, ausversehen gelöscht" etc. decken wir zwar z.B. auch mit VSS-Snapshots ab (da machen wir "viele"), zusätzlich aber eben dann auch immer wieder richtige Backups, um Datenverlust (durch mich, den Storage-Admin ;-D) bestmöglich auszuschließen

 

[Falk R.]

Danke @Falk R. , das klingt ernsthaft beruhigend und eine Bastellösung wird es bei uns definitiv nicht ;-)
Leider können wir aktuell nur mit Test-VMs evaluieren, erst wenn wir die große Migration auf Proxmox vollziehen, sehen wir, wie es wirklich läuft.
Ich habe brutal Bock drauf und Vertrauen in die Stabilität von Proxmox und Ceph, aber das Backup-Thema...

Warum mehrfach? Weil wegen wenn...
Mündliche Kunden-Daten werden aufgenommen und in Datenbanken, Office-Filerservern, etc. abgelegt.
Bei Datenverlust könnte gar nicht nachvollzogen werden, welche Menschen da ohne Termin am Schalter standen und welche Anträge/Zahlungen etc. gehandled wurden, Menschen würden auf Bearbeitung warten und es kommt nichts...

Datenverlust durch "hups, ausversehen gelöscht" etc. decken wir zwar z.B. auch mit VSS-Snapshots ab (da machen wir "viele"), zusätzlich aber eben dann auch immer wieder richtige Backups, um Datenverlust (durch mich, den Storage-Admin ;-D) bestmöglich auszuschließen

OK, klingt verständlich.
Deshalb dokumentieren viele Kunden solche Vorgänge in Sharepoint oder irgend einer anderen DB basierten Anwendung.
Der Vorteil, die Logs kannst du ohne impact in kurzen Abständen sichern und zusätzlich auch per Logshipping auf nen anderen Server direkt kopieren, damit gar nix verloren geht. Dann spart man sich die vielen Backups von Dokumentdateien.
Damit machst du auch dein Backup wieder entspannter.

 

[WHF]

Mir hat es diese Woche auch bei drei VM's das Filesystem zerlegt. Erst mal nicht verstanden, was da passiert ist. Der PBS hängt via 10GB an dem PVE Cluster und das Limit ist nachts auf 70 MB und tagsüber auf 50 MB die Sekunde begrenzt. Demzufolge dreht der PBS Däumchen, zumal dieser auch recht gut bestückt ist.

Grund war / ist bei mir sehr wahrscheinlich ein Problem mit dem Netzwerk:

Feb 21 09:28:29 rx2540-1 corosync[3502588]: [KNET ] link: host: 2 link: 1 is down
Feb 21 09:28:29 rx2540-1 corosync[3502588]: [KNET ] host: host: 2 (passive) best link: 0 (pri: 1)
Feb 21 09:28:33 rx2540-1 corosync[3502588]: [KNET ] rx: host: 2 link: 1 is up
Feb 21 09:28:33 rx2540-1 corosync[3502588]: [KNET ] link: Resetting MTU for link 1 because host 2 joined
Feb 21 09:28:33 rx2540-1 corosync[3502588]: [KNET ] host: host: 2 (passive) best link: 0 (pri: 1)

Entweder ein Switch Problem oder NIC / Kabel Defekt auf dem betroffenen PVE Node.

Irgendwie macht mir das aber mächtig Bauchschmerzen, dass Fehlertoleranz durch Abwesenheit glänzt und das Backup die VM's lahmlegt.

Vielleicht hat ja jemand mal dasselbe Problem und das hier hilft.

 

[Zerstoiber]

das Thema Backup Fleecing (Umleitung in eine lokale Disk, nicht zum PBS) kann gar nicht schnell genug kommen, das Thema bereitet auch uns große Bauchschmerzen - denn bisher ist es eine sehr unglückliche Architektur die ja wie man hier im Forum sieht immer wieder zu gravierenden Problemen und Corruption etc. führt.
https://www.mail-archive.com/pve-devel@lists.proxmox.com/msg09294.html

 

[Falk R.]

Mir hat es diese Woche auch bei drei VM's das Filesystem zerlegt. Erst mal nicht verstanden, was da passiert ist. Der PBS hängt via 10GB an dem PVE Cluster und das Limit ist nachts auf 70 MB und tagsüber auf 50 MB die Sekunde begrenzt. Demzufolge dreht der PBS Däumchen, zumal dieser auch recht gut bestückt ist.

Grund war / ist bei mir sehr wahrscheinlich ein Problem mit dem Netzwerk:

Feb 21 09:28:29 rx2540-1 corosync[3502588]: [KNET ] link: host: 2 link: 1 is down
Feb 21 09:28:29 rx2540-1 corosync[3502588]: [KNET ] host: host: 2 (passive) best link: 0 (pri: 1)
Feb 21 09:28:33 rx2540-1 corosync[3502588]: [KNET ] rx: host: 2 link: 1 is up
Feb 21 09:28:33 rx2540-1 corosync[3502588]: [KNET ] link: Resetting MTU for link 1 because host 2 joined
Feb 21 09:28:33 rx2540-1 corosync[3502588]: [KNET ] host: host: 2 (passive) best link: 0 (pri: 1)

Entweder ein Switch Problem oder NIC / Kabel Defekt auf dem betroffenen PVE Node.

Irgendwie macht mir das aber mächtig Bauchschmerzen, dass Fehlertoleranz durch Abwesenheit glänzt und das Backup die VM's lahmlegt.

Vielleicht hat ja jemand mal dasselbe Problem und das hier hilft.

Wenn du 10 GBit hast, warum limitierst du den PBS auf so kleine Werte?
Damit wird dein Backup langsam und im schlimmsten Fall hängen sich die VMs weg, wenn produktiv mehr geschrieben wird als der PBS wegschreiben darf.
Ich limitiere das Backup nie und habe auch bei keinem Kunden jemals eine defekte VM gehabt.
Ein vernünftiges Design des Clusters und des PBS ist nun mal unerlässlich und dann läuft auch alles Stressfrei.
Wenn du aus welchem Grund auch immer, das Backup limitieren musst, ist irgendetwas falsch gesized.

 

[WHF]

Wenn du 10 GBit hast, warum limitierst du den PBS auf so kleine Werte?
Damit wird dein Backup langsam und im schlimmsten Fall hängen sich die VMs weg, wenn produktiv mehr geschrieben wird als der PBS wegschreiben darf.
Ich limitiere das Backup nie und habe auch bei keinem Kunden jemals eine defekte VM gehabt.
Ein vernünftiges Design des Clusters und des PBS ist nun mal unerlässlich und dann läuft auch alles Stressfrei.
Wenn du aus welchem Grund auch immer, das Backup limitieren musst, ist irgendetwas falsch gesized.

Weil von Außen auch noch ein paar Sicherungen über eine 1GB Leitung kommen und das so im Rahmen bleibt. Bisher gab es keinerlei Probleme, bis auf jetzt. Es fehlt die Fehlertoleranz, sowas darf einfach nicht sein.