NyoMic
xepera-xeper-xeperu
|
Snapshots != Backup RAID != Backup
RAID ist für Ausfallssicherheit im Betrieb, Platte geht ein, Zero downtime (zumindest bei 1/5/10 usw.) Wenn die Platte eingeht hast du grundsätzlich mit Snapshots ein Problem da die in der vm-disk gespeichert werden (CoW) und somit auch weg sind. Wenn du ein RAID hast dann läuft der Proxmox, bzw. dort wo die vm-disk gespeichert ist, normal weiter und du tauscht die Platte, rebuildest das RAID und hoffst das alles gut geht.
Im Idealfall, sollte nämlich was anderes für einen Ausfall sorgen, bspw. du selbst, hast du auch noch auf einem NAS oder sonstwo zusätzlich zum RAID ein Backup dass du wiederherstellen kannst.
Ob der Aufwand der Ausfallssicherheit für einen selbst SInn macht oder nicht darf jeder selbst entscheiden.
|
hynk
Super Moderatorlike totally ambivalent
|
Hier ein paar hilfreiche Scripts: Proxmox VE Helper-ScriptsScripts for Streamlining Your Homelab with Proxmox VE Link: helper-scripts.com Vorsicht mit dem Monitor All Script. Das kann zu unerwarteten Shutdown und Restarts führen, wenn man an den Ressourcengrenzen ist. Nervig wenn man vergisst, dass man es hat Bin sehr zufrieden mit Proxmox bisher. Ich habe kürzlich um einen produktiven Server (Intel) auf 8.x zu aktualisieren (Gab außerdem Probleme mit der Bootpartition nach einem Stromausfall...) einen Replikaserver aus einer alten Workstation (AMD) gezaubert und trotz der unterschiedlichen CPUs ist das astrein gelaufen. Bisher macht mir Proxmox um so viel weniger Probleme als HyperV und ist mir weit symphatischer als ESXi. Im Homelab entsteht auf zwei Nodes aktuell ein Kubernetes Cluster (dont ask me why), aber da komm ich zeitbedingt nur sehr mühsam voran... Irgendwie ist immer etwas anderes wichtiger oder lauter. @Viper780 Woran scheitert es bei HASS? @NyoMic Ich denke kruzFX meinte eh die Backup Funktion von Proxmox und nicht die eigentlichen Snapshots. Aber sonst full ack. Unbedingt VMs und Configs wegsichern, oder überhaupt über ein externes Storage einbinden und von dort weg sichern. Spart auch beim Rebuild Arbeit, wenn man nur noch die Configs auf den Server laden muss und fertig.
|
KruzFX
8.10.2021
|
Man kann das auch gleich ausweiten auf ein HA-Cluster samt Proxmox Backup Server.
|
NyoMic
xepera-xeper-xeperu
|
Genau, dann aber bitte entweder 3 Nodes oder mit Quorum (und wenns nur so wie bei mir ein Raspberry-Pi-Zero-2-W ist) - ich spreche aus Erfahrung
|
Viper780
Er ist tot, Jim!
|
@Viper780 Woran scheitert es bei HASS? Home Assistent kann immer nur eine aktive Instanz und hat kein primary / secondary Konzept
|
spunz
Super ModeratorSuper Moderator
|
warum nicht einfach eine Replikation auf die zweite Kiste einrichten?
|
Viper780
Er ist tot, Jim!
|
Hat mir bisher immer erfolgreich die DB zerschossen.
Müsste mir dafür mal einen MariaDB Galera Cluster anschauen.
Mit dem Autobackup täglich in die Google Cloud bin ich zwar nicht glücklich habe aber in kurzer Zeit wieder eine lauffähige Instanz
|
spunz
Super ModeratorSuper Moderator
|
das klingt eher nach zusätzlichen Problemen wenn simple Snapshots schiefgehen.
|
Viper780
Er ist tot, Jim!
|
Eine Datenbank Snapshoten ist halt nicht ganz trivial
|
spunz
Super ModeratorSuper Moderator
|
Eine Datenbank Snapshoten ist halt nicht ganz trivial Eigentlich ist es super trivial, du musst deiner DB halt schon vorher noch "jetzt kommt der Snapshot, saycheeeeeese" sagen?
|
COLOSSUS
AdministratorGNUltra
|
Eigentlich ist es super trivial, du musst deiner DB halt schon vorher noch "jetzt kommt der Snapshot, saycheeeeeese" sagen? Nicht mal das unbedingt in Wahrheit, weil wenn eine Datenbank einen spontanen power cut nicht ueberleben kann bzw. nicht crash-consistent ist, ist ihre Resilienzstrategie bzw. deren Umsetzung einfach ungenuegend.
|
KruzFX
8.10.2021
|
Nicht mal das unbedingt in Wahrheit, weil wenn eine Datenbank einen spontanen power cut nicht ueberleben kann bzw. nicht crash-consistent ist, ist ihre Resilienzstrategie bzw. deren Umsetzung einfach ungenuegend. Stimmt natürlich, aber es ist trotzdem ratsam die Datenbank zu stoppen vor einem Backup. Mach ich mit Prometheus in der Firma per cronjob bash-Skript täglich um Mitternacht. Datenbank stoppen, Backup und wieder starten.
|
COLOSSUS
AdministratorGNUltra
|
Ja eh klar - aber noch ratsamer waere es, welches Backup auch immer gar nie aus Notwendigkeit restoren zu muessen Aber es wuerd mich trotzdem wundern, wenn man eine HASS-Installation mit so einer Backup- bzw. Failover-Strategie tatsaechlich umbringen kann; das meinte ich
|
daisho
SHODAN
|
Nicht mal das unbedingt in Wahrheit, weil wenn eine Datenbank einen spontanen power cut nicht ueberleben kann bzw. nicht crash-consistent ist, ist ihre Resilienzstrategie bzw. deren Umsetzung einfach ungenuegend. Hatte das schon 2x (VM Disk unterm Hintern weggebrochen) bei einem (möchtegern Enterprise) Produkt mit der mitkommenden eingebauten MongoDB War in einem Testszenario dann egal wenn man "reset" macht, produktiv stell ich mir das wie ein Horror vor
|
COLOSSUS
AdministratorGNUltra
|
MongoDB ist halt etwas weniger DB, dafuer etwas mehr M... Zumindest war es ganz am Anfang so, dass das Geraet ack'd Writes nicht per fsync() ans OS durchgeflusht hat, und dann sind natuerlich *ALLE* Garantien beim Teufel. Releases, in denen das (und das Verlieren von ack'd writes im replizierenden Mehrknoten-Betrieb) behoben worden ist, sind ggf. nur noch unter der unfreien Phantasielizenz verfuegbar. Ich wuerde dem Ding kein Darum anvertrauen. Ich weisz nicht, was heute unter HASS als DB werkt - aber bei etablierten RDBMS (MySQL, PostgreSQL, SQLite) muss man sich wirklich absichtlich anstrengen, auf diese Weise Daten zu verlieren.
|