Proxmox VMs, Storage, usw. - Seite 4

Seite 4 von 12 - Forum: Linux and other OS auf overclockers.at

URL: https://www.overclockers.at/linux/proxmox-vms-storage-usw_263133/page_4 - zur Vollversion wechseln!

NyoMic schrieb am 29.05.2024 um 22:30

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 schrieb am 29.05.2024 um 23:17

Hier ein paar hilfreiche Scripts:

Proxmox VE Helper-Scripts

Scripts 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 schrieb am 29.05.2024 um 23:27

Man kann das auch gleich ausweiten auf ein HA-Cluster samt Proxmox Backup Server.

NyoMic schrieb am 30.05.2024 um 00:36

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 schrieb am 30.05.2024 um 01:51

Zitat aus einem Post von hynk
@Viper780
Woran scheitert es bei HASS?

Home Assistent kann immer nur eine aktive Instanz und hat kein primary / secondary Konzept

spunz schrieb am 30.05.2024 um 08:48

warum nicht einfach eine Replikation auf die zweite Kiste einrichten?

Viper780 schrieb am 30.05.2024 um 09:49

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 schrieb am 30.05.2024 um 09:55

das klingt eher nach zusätzlichen Problemen wenn simple Snapshots schiefgehen.

Viper780 schrieb am 30.05.2024 um 10:25

Eine Datenbank Snapshoten ist halt nicht ganz trivial

spunz schrieb am 30.05.2024 um 12:49

Zitat aus einem Post von Viper780
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 schrieb am 30.05.2024 um 13:43

Zitat aus einem Post von spunz
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 schrieb am 30.05.2024 um 14:10

Zitat aus einem Post von COLOSSUS
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 schrieb am 30.05.2024 um 14:35

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 schrieb am 30.05.2024 um 14:36

Zitat aus einem Post von COLOSSUS
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 :eek:

COLOSSUS schrieb am 30.05.2024 um 14:40

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.