Moin,
ich habe erst 4 Tage Proxmox Erfahrungen und eine Grundsatzfrage:
Wenn ich in Proxmox die HA-VM oder Proxmox selbst herunterfahre, wird dann HA ordentlich heruntergefahren oder nur abgeschaltet mit Gefahr von Inkonsistenzen?
In der HA-VM Konfiguration habe ich den QUEMU Agenten aktiviert, der dabei helfen soll
Brauche ich den überhaupt dafür?
Muß in HA ein Agent-Gegenstück installiert werden oder ist das in HA sowieso implementiert?
Danke und gute Nacht, mir reichts für heute 
Moin,
wieder sehr akribisch 
Also das ist so, HA also die HAOS Version, die man z. B. sich mittels Helferskript installiert hat den Guest Agent installiert und kommuniziert darüber auch mit Proxmox, also wenn Du ein Reboot, Stopp der VM aus Proxmox heraus machst, wird die VM konsistent gestoppt, auch wenn Du Proxmox direkt herunterfährst, werden alle Instanzen, also LXC und VMs konsistent gestoppt, solange sie den Guest Agent in der VM installiert haben.
Also ja, das muss so eingestellt werden!
Wenn Du eine Windows VM erstellst, musst Du Dich aber selbst darum kümmern, dass in Windows der Guest Agent installiert wird, das gilt auch für Linux VMs, da muss man selbst Hand anlegen.
Kommen wir aber zum eigentlichen Problem, auf das Du sicherlich, bei Deiner akribischen Art stoßen wirst 
Welches ist der beste Modus um ein Backup der VM zu machen, nehme ich,
Ich mache nur Snapshot, auch wenn da immer wieder behauptet wird, dass das, zu inkonsistenten Datenbanken führen soll, habe ich davon noch nichts mitbekommen, denn der interne Mechanismus ist so ausgelegt, dass erst eine Liste erstellt wird, der zu sichernden Daten, sollte sich in der Zeit der Sicherung eine Datei verändern, wird diese auf eine Sperrliste gesetzt und nochmals gelesen.
Viele nutzen Stopp, aber da sehe ich eher das Problem, denn, wenn ein externer Dienst, der z. B. einen MQTT Broker Add-on befeuert, könnte dann seine Daten nicht mehr loswerden, diese Daten würden fehlen, weil ja HA fürs Backup gestoppt wird.
Der Client ist aber im Standard so eingestellt Fire and forget!
Also wer mit Stopp arbeitet, sollte dann keine Add-ons in HA nutzen, die als Datendrehscheibe genutzt werden, dass darf dann nur extern stattfinden.
Ach so, auch das HA interne Backup macht kein Stopp und da hat sich auch noch keiner wegen Inkonsistenzen beschwert
VG
Bernd
P.S.: Ich muss da noch etwas nachschieben,
Moin Bernd
So tief bin ich in dem Thema auch nicht drin, aber ist das wirklich ein Problem? 
Ich nutze hier z.B. auch den Stop-Mode
der das gleiche bewirkt als wenn man HA über dessen WebGUI
regulär herunterfahren würde. Somit werden dann und dafür dann natürlich auch die laufenden Addons gestoppt, was ja auch vollkommen normal ist.
Ich meine das der Stop-Mode eigentlich eher dann ein Problem sein könnte wenn man ohne den/einen QEMU Guest Agent arbeitet, oder arbeiten muss. Was bei einer anderen VM bei mir z.B. der Fall ist.
Aber wie schon gesagt, so tief habe ich mich auch noch nicht mit dem Thema beschäftigt und mir sind bezüglich der HA VM da auch noch keine Probleme aufgefallen. Wobei ich in den letzten Jahre allerdings und auch zum Glück, nicht schon x-mal ein HA VM Restore machen musste, oder gemacht habe. 
VG Jim
Moin,
ja genau, das ist auch korrekt erkannt und da war / ist mein Kopfproblem, denn wenn der Hichi Lesekopf, jede Sekunde Daten liefert, aber das Add-on Zigbee, oder MQTT nicht online ist, wo bleiben dann die Daten, wie geschrieben, Fire and forget.
Nach dem nochmaligen lesen, habe ich es jetzt so verstanden, dass das Backup Tool ein Mechanismus nutz, der die VM stoppt, dann das Backup startet und alle anfallenden Schreiboperationen auf die VM abfängt und nach dem Backup wieder mit der VM abgleicht.
Ich kann mir schon Szenarien vorstellen, in dem es besser ist ein Stopp zu machen oder eben ein Snapshot, aber in dem Bereich, in dem wir uns bewegen, macht das aus meiner Sicht keinen Unterschied.
Ich werde da auch nicht tiefer einsteigen, denn ich werde da keine Geister jagen, ich habe mit meinen Backupeinstellungen, seit 2 Jahren keine Probleme, sollte es doch einmal zu einer Unstimmigkeit kommen, dann werde ich das neu bewerten
VG
Bernd
Moin Bernd
Natürlich zählen erst einmal die eigenen Erfahrungswerte, sprich wenn man etwas nutzt und sich dadurch bisher keinerlei Probleme ergeben haben, dann gibt es vermutlich auch gar keinen Grund sich darüber Gedanken zu machen und wie Du so schön geschrieben hast “Geister zu jagen”.
Mir ging es in erster Linie um diese Aussage
und das ist m.M.n. so nicht korrekt, (Edit: “Nicht korrekt” klingt ggf. etwas hart. Sagen wir besser ist m.M.n. etwas zu pauschal.) eben weil Stop die HA VM so stoppt und herunterfährt, wie es HAOS auch selber machen würde. Demnach dürfte man dann ja auch, wenn man Proxmox und eine HA VM gar nicht nutzen würde und HA bare metal installiert hätte, mit installierten HA Addons, nicht ein System neu starten
Was korrekt ist und Du mit der Aussage ja wohl auch zum Ausdruck bringen wolltest/willst, sind natürlich Deine Überlegungen zu dem Thema
und wie ein Stop damit dann umgeht weiß ich auch nicht wirklich genau, sprich ob das
zutreffend ist. Ich würde sogar eher vermuten das die Daten, die zwischenzeitlich z.B. von dem von Dir als Beispiel genannten IR-Lesekopf anfallen, schlicht und einfach weg sind/wären. Denn das wäre bei einer HA bare metal Installation bei einem System neu starten, dann ja auch der Fall. Wenn z.B. der als Addon installierte MQTT Broker nicht läuft kann er ja schließlich keine Daten empfangen und auch HA diese Daten nicht in seine Datenbank übernehmen. Was dann HA nach einem System neu starten mit diesen dann fehlenden Daten macht und wie dann was und wo nachgetragen und/oder “geglättet/angepasst” wird, ist dann noch eine andere Frage.
Wie gesagt vermute ich das ein Stop der HA VM mit vorhandenen QEMU Guest Agent, sich genau so verhält als wenn an HA per System neu starten neu starten würde.
Naja - das wird nicht nur “behauptet” sondern das steht auch so in der offiziellen Doku von Proxmox.
snapshot mode
This mode provides the lowest operation downtime, at the cost of a small inconsistency risk. It works by performing a Proxmox VE live backup, in which data blocks are copied while the VM is running. If the guest agent is enabled (agent: 1) and running, it calls guest-fsfreeze-freeze and guest-fsfreeze-thaw to improve consistency.
Und weil es hier ja um
geht, sprich um “beste”, oder besser gesagt eher um die “sicherste” Methode, wäre das gem. Proxmox Doku halt der Stop Mode.
stop mode
This mode provides the highest consistency of the backup, at the cost of a short downtime in the VM operation. It works by executing an orderly shutdown of the VM, and then runs a background QEMU process to backup the VM data. After the backup is started, the VM goes to full operation mode if it was previously running. Consistency is guaranteed by using the live backup feature.
Dann kommt noch hinzu das - wenn man ZFS nicht nutzt - beim Snapshot Mode - soweit ich weiß - die in dem Moment sich im RAM befindlichen Daten nicht mit gesichert werden. Dafür gibt es ja - wenn man ZFS nutzt - dort die Option diese Daten auch zusätzlich mitzusichern. Da ich selber aber kein ZFS nutzt weiß ich nicht was der Snapshot Mode dann da genau sichert.
D.h. meiner Meinung nach ist der Stop Mode die sichere Variante die inkonsistente Daten bei der/einer HA VM am ehesten ausschließt. Das während des Stop-Prozesses dann vermutlich keine Daten - z.B. von dem MQTT Broker - erfasst werden dürfte wahrscheinlich der Fall sein, aber das ist bei einer HA bare metal Installation und System neu starten - ja auch nicht anders.
VG Jim
Ich nutze auch bereits seit Längerem HomeAssistant als VM unter Proxmox.
Auch ich nutze “Snapshot” als Backupmethode und habe bisweilen bei meinen wenigen Recovery-Vorgängen keine Probleme gehabt.
Ich betreibe aber auch wissentlich keine zeitkritischen Datenbänke.
“HA” (Hochverfügbarkeit) im Proxmox-Cluster nutze ich ebenfalls, aber auch dabei sind mir bei automatischer Migration auf eine andere Node noch keine Ungereimtheiten untergekommen.
In der Tat scheinen da eigene Erfahrungen, gepaart mit individuell unterschiedlichen Voraussetzungen, keine pauschale Aussage zuzulassen.
Sorry für das Off-Topic, aber:
Wo/Wie kann ich die Option zum zusätzlichen Sichern der aktuellen RAM-Daten bei Nutzung von ZFS einstellen?
Bei einer Replizierung in einem Proxmox-Cluster wird das ja meines Wissens nach automatisch mit synchronisiert, bei Backup habe ich die Option noch nicht gefunden.
Wie gesagt nutze ich ZFS nicht, aber ich meine da mal irgendwo eine Diskussion zu dem Thema gelesen zu haben, in der es um ZFS + Snapshots + Include RAM ging.
Ah u.a. gefunden:
Falls du ZFS nutzt, dann kannst du “include RAM” für das Snapshot aktivieren. Dann wird neben dem Dateisystem auch der RAM-Inhalt gespeichert und wenn du dann zum Snapshot zurückrollst, dann sollte es eigentlich genau zu dem Punkt sein, wo du das Snapshot gemach hast, also auch mitten im laufenden Betrieb.
Aber ok das bezieht sich ja vermutlich nicht auf die Backup-Methode mit dem Snapshot-Mode, sondern auf Snapshots allgemein. Aber da ich ZFS nicht nutze kann ich dazu auch gar nichts weiter zu sagen und somit kann meine Aussage
bezogen auf Backup + Snapshot + ZFS auch falsch sein. Eben weil es ja, auch wenn man so wie ich gar kein ZFS nutzt und einen Snapshot einer VM erstellt, dort ebenfalls die Option “Include RAM”
VG Jim
Trotzdem Vielen Dank für Deine Antwort.
Der Link verweist zwar auf ein Thema, welches über 4 Jahre alt ist, aber ich mach mich trotzdem mal im Netz dazu schlau.
Vielleicht findet sich ja doch noch was Verwertbares.
Nachtrag:
Manchmal sehe ich den Wald vor lauter Bäumen nicht.
Deine Aussage ist korrekt.
“Include RAM” gibt es auch unter ZFS beim Erstellen eines Snapshot, jedoch nicht als Backup-Option.
Gut dann wäre das geklärt. Ohne ZFS konnte ich da schlecht nachschauen.
Somit kann man meine Aussage/Vermutung bzgl. Backup + ZFS + Snapshot und eine “Include-RAM” Option direkt wieder vergessen. 
VG Jim
Moin,
hatte ich ja, im letzten Post geschrieben, ich habe eine Schranke im Kopf, den ich aber durch die Dokumentation etwas auflösen konnte.
Daher ja auch, dass das von Proxmox entwickelte Backup Tool, es so macht, das die VM gestoppt wird, dann wird das Backup auf der gestoppten VM gemacht, alle anfallenden Schreibvorgänge, werden zwischengespeichert und nach dem Backup mit dem original synchronisiert, also gehen auch keine Daten verloren.
Es geht nicht um den Stopp direkt, sondern um die in HA laufenden Add-ons, die eigentlich Daten entgegennehmen sollen, z. B. MQTT-Broker und Zigbee2MQTT, wenn beides als Add-on läuft, dann ein Stopp gemacht wird, werden auch die Add-ons angehalten, ein Hichi-Lesekopf, bekommt aber weiter Daten vom Zähler und versucht die an Zigbee2MQTT weiterzugeben, geht nicht, ist ja down, aber der Hichi merkt sich das nicht, was er gesendet hat, sondern Fire and forget, somit sind diese Werte verloren, was man ja auch bei einem normalen Stopp von HA auch sieht. Auch wenn man Zigbee2MQTT in einem LXC fährt und MQTT als Add-on, werden zwar die Daten noch an Z2M durchgereicht, aber nicht weiter an den MQTT-Broker, auch diese Daten wären verloren.
Wenn jetzt aber der Backupjob in Proxmox, es so macht, dass die gesendeten daten, die ja dann auch auf Platte geschrieben worden wären, eben diese zwischenspeichert und nach dem Backup wieder mit der VM synchronisiert, dann gehen diese nicht verloren und nach einem Backup dürfte man keine Lücke oder gerade, etc. sehen.
Da ich nur Snapshots mache, kann, will ich das jetzt aber nicht wirklich testen
Ein Risiko ist aber etwas anderes, als dass es wirklich passiert, wie ich ja auch schon geschrieben habe, kann ich mir sehr wohl Szenarien vorstellen, in denen es passieren kann, aber in dem Bereich, in dem wir Proxmox nutzen, wird das wohl eher nicht der Fall sein.
Das ist halt wie mit allem, wenn man sich für etwas entschieden hat, muss man auch mit den Konsequenzen leben, ich habe mich entschieden es per Snapshot zu machen und fahre damit gut, ein anderer hat vielleicht Probleme, dann muss man schauen und neu bewerten.
Das ist bei mir der nächste Punkt, ich habe seit zwei Jahren noch nie ein Backup gebraucht, das läuft einfach bei mir und das, obwohl ich hier ständig, um Probleme anderer Forums-User nachzustellen, Dinge installiere und lösche und wieder installiere
Achtung, bitte die zwei Dinge nicht vermischen, Snapshot der Dateisysteme und dem Snapshot beim Backup, der Snapshot beim Backup geschieht Tool intern und es wird aktuell noch nicht auf Dateisystemebene gemacht, soweit ich das heute Morgen in der Dokumentation gelesen habe.
VG
Bernd
Moin Bernd
Alles gut. Wie gesagt kenne ich mich auch nicht mit den “Untiefen” von irgendwelchen Backup-Vorgängen bei Proxmox aus. Ich halte mich da einfach an die Proxmox Doku in der halt steht das der Stop-Mode die “sicherste” Methode wäre bei einem Backup und da dieser Stop-Mode nach meinem Verständnis genau so funktioniert als wenn ich bei HA ein System neu starten nutze, erscheint das für mich die sinnvollste Methode zu sein. Das dann während dieses Vorgangs ggf. irgendwelche Daten - z.B. von dem IR-Lesekopf - im Nirvana landen könnten - sprich Fire and forget - ist dann eben so und wäre bei einer HA bare metal Install mit Addons ja auch nicht anders.
Ebenso ist natürlich denkbar das bei der Snapshot-Methode gar keine Daten im Nirvana landen, eben weil die fortlaufenden Daten des IR-Lesekopfes dann weiterhin ins RAM fließen und alle irgendwie und irgendwo kompl. erhalten bleiben, aber das weiß ich halt nicht und kann ich auch gar nicht beurteilen. Mich hat halt nur ein wenig Deine Aussage
irritiert bzw. “gestört”, weil diese irgendwie so “endgültig und eindeutig” klingt und User ggf. irgendwie verunsichern könnte.
Ich versuche mal so etwas wie eine Zusammenfassung zu erstellen, allerdings ohne die “Untiefen” der Proxmox Backup-Vorgänge zu kennen.
System neu starten bei HA. Dabei könnte es sein das während des Prozesses Daten, die von z.B. einem IR-Lesekopf gesendet werden, im Nirvana verschwinden.Ich nutzt Proxmox hier jetzt seit etwas mehr als drei Jahren und in der Zeit habe ich 3 x Backups von VMs wieder zurückgespielt. 2 x wegen eines Umzuges des Proxmox Host und 1 x hatte ich mir meinen Proxmox Host durch “herumspielen” zerschossen. 
Ob bei dem erstellen der VM Backups per Stop-Mode dann ggf. während des Prozesses irgendwelche z.B. MQTT-Daten im Nirvana gelandet sind? Keine Ahnung und so wirklich interessiert mich das auch nicht, denn die Daten die während der Ausfallzeit des Proxmox Host z.B. ein IR-Lesekopf gesendet hat, sind ja dann auch alle im Nirvana gelandet. Somit spielen die ggf. paar fehlenden Daten während eines Backup-Prozesses des VM für mich nicht wirklich eine Rolle.
Anm.: Das was ich hier geschrieben habe bezieht sich in erster Linie natürlich nur auf meine Proxmox Installation und Nutzung und das in Kombination mit einer HA VM und dem was HA dann für Daten braucht und erfasst. Für andere Proxmox, VM und LXC Installationen mag das alles schon wieder ganz anders aussehen und/oder ganz anders zu beurteilen sein.
VG Jim
Danke für die wirklich interessante Profi Diskussion! 
Hier meine Pragmatiker Beobachtung.
Es dauert bis zur Aufhebung des DB-Locks 23 Sekunden in der nichts geschrieben werden kann. Aber der Recorder hält neue Sensorwerte wahrscheinlich vor und schreibt nach den 23 s.
[08:00:49] INFO: Start MariaDB client (to lock tables for backups)
s6-rc: info: service mariadb-lock-core successfully started
s6-rc: info: service mariadb-lock-post: starting
[08:00:49] INFO: MariaDB tables locked
s6-rc: info: service mariadb-lock-post successfully started
s6-rc: info: service mariadb-lock-post: stopping
[08:01:12] INFO: MariaDB tables unlocked
s6-rc: info: service mariadb-lock-post successfully stopped
s6-rc: info: service mariadb-lock-core: stopping
[08:01:12] INFO: MariaDB client (to lock tables for backups) stopped
s6-rc: info: service mariadb-lock-core successfully stopped
Und jetzt das Backup über Proxmox VM Snapshot. etwas mehr als 1 s!
Wie groß ist da wirklich die Gefahr einer Inkonsistenz.
[21:00:02] INFO: Start MariaDB client (to lock tables for backups)
s6-rc: info: service mariadb-lock-core successfully started
s6-rc: info: service mariadb-lock-post: starting
[21:00:02] INFO: MariaDB tables locked
s6-rc: info: service mariadb-lock-post successfully started
s6-rc: info: service mariadb-lock-post: stopping
[21:00:03] INFO: MariaDB tables unlocked
s6-rc: info: service mariadb-lock-post successfully stopped
s6-rc: info: service mariadb-lock-core: stopping
[21:00:03] INFO: MariaDB client (to lock tables for backups) stopped
s6-rc: info: service mariadb-lock-core successfully stopped
s6-rc: info: service mariadb-lock-core: starting
Die Maschinen werden, wenn der Guest-Agent für die VM in Proxmox konfiguriert ist, aber kein Guest-Agent in der VM installiert ist (oder nicht läuft) nicht richtig runter gefahren.
Wenn KEIN Guest-Agent für die VM in Proxmox konfiguriert ist, werden die virtuellen Maschinen über ACPI runtergefahren, egal ob da schon ein GA drin ist oder nicht.
Moin,
hast Du das alles wirklich gelesen?
Ich habe geschrieben, dass wenn die VM mittels Helferskript installiert wurde, auch der Guest Agent installiert wird, und auch im weiteren Text habe ich geschrieben, dass wenn man selbst VMs erstellt, sich da selbst drum kümmern muss!
Also was willst Du mir mit Deiner Bestätigung zu meinen Aussagen mitteilen?
VG
Bernd
Ich habe allerdings keine Antwort gelesen, die aussagt was passiert wenn kein GA installiert aber konfiguriert ist und anders rum. Falls ich das überlesen haben sollte, entschuldige.