Recent content by Bu66as

Doch, schau nochmal genau: bei || reicht es wenn eine Seite wahr ist. Wenn FORCEFAILOVER == 0 (also Normalzustand), ist die linke Seite schon wahr, damit ist die ganze Bedingung wahr, egal was MASTERGWUP sagt. Der Master-GW-Check wird zwar ausgewertet, ist dann aber egal für das Ergebnis. Mit...

Ja stimmt, guter Punkt. Wenn man nicht grad nen identischen Node auf Lager hat kann das schnell Tage oder Wochen werden bis was geliefert wird. Nen kleinen Standby-Node im zweiten Brandabschnitt vorhalten der im Normalfall idle ist (oder leichte Workloads macht) und im Ernstfall die kritischen...

Stimmt, da hast du recht. Ohne sync testet man primär den Writeback-Cache, nicht die NVMe direkt. Hab mich da zu kurz gefasst.

OK, dann passt das mit dem && erst recht. Deine Beschreibung ("wenn 0, nur bei aktivem Master zurückschalten") ist genau die &&-Logik. Mit dem || im aktuellen Script würde er auch recovern wenn der Master noch down ist, solang FORCEFAILOVER auf 0 steht.

Cooles Projekt, das kannte ich noch nicht! Und was @dcsapak sagt bzgl. upstream würde ich auf jeden Fall überlegen, gerade sowas wie zusätzliche Spalten im Tree wäre super.

Die 69k IOPS ohne --sync=1 zeigen, deine NVMe sind völlig in Ordnung, da ist nix kaputt. Das Problem ist spezifisch der sync-Write-Pfad durch den ZIL auf RAIDZ1.

Das ist in der Regel harmlos. Passiert bei Cloud-Init Images häufig, weil die VM erstmal mit der RTC-Zeit hochkommt und dann systemd-timesyncd (oder chrony) die Zeit korrigiert. Journald merkt den Sprung und rotiert die Logs, das wars.

Das Problem steht in der Fehlermeldung: volume 'zfs2/vm-101-cloudinit' already exists. Beim Failover auf den anderen Node bleibt das alte Cloudinit-Volume auf n2 liegen. Wenn die VM dann zurück migriert werden soll, versucht er das Cloudinit-Image rüberzuschicken, aber da liegt noch das alte...

Das ist im PBS Dashboard direkt angezeigt, oben. Oder auf der Shell: proxmox-backup-manager cert info Da steht der Fingerprint dabei. Am einfachsten ist aber: auf der PVE-Seite beim Hinzufügen des PBS-Storages das Fingerprint-Feld einfach leer lassen, auf "Add" klicken, und dann zeigt dir PVE...

Ja, das lässt sich fixen. Da es ein reines Daten-RAID ist, geht das relativ einfach: Pool exportieren und wieder importieren. Beim Import löst ZFS die Device-Namen neu auf und nimmt dann die by-id Pfade. Erstmal die by-id Bezeichnung der neuen Platte raussuchen: ls -la /dev/disk/by-id/ | grep...

Gute Frage. Das Problem mit "continue" + "keep" auf Dauer ist genau das was du beschreibst: die Abhängigkeit vom ersten Tape wächst immer weiter, weil alle späteren Inkremente auf den Chunks vom ersten Backup aufbauen. Zwei bessere Optionen: Du könntest bei der Allocation Policy auf "always"...

Kein Ding, schade dass es zu spät kam. Aber jetzt wo du frisch aufgesetzt hast: Richte dir direkt vernünftige Backups ein, dann sparst du dir beim nächsten Mal den ganzen Stress. PBS oder notfalls vzdump auf die NAS, Hauptsache es läuft regelmäßig.

Schön dass es wieder läuft! Und lass dich nicht entmutigen, jeder hat mal irgendwo angefangen. Wenns nochmal klemmt, einfach melden.

Interessant, dass der Ping-Check Fehlalarme produziert hat. Die Fritzbox-Auskunft ist eh die zuverlässigste Quelle, die weiß am besten, ob ihr WAN steht. Mir fällt aber ein Logik-Bug in der Recover-Bedingung auf: if [ $FORCEFAILOVER == 0 ] || [ $MASTERGWUP == 1 ]; then Das || sorgt dafür, dass...

Freut mich dass es das war! Falls du ne Idee brauchst fürs Template, ich hab bei Kunden gute Erfahrungen mit nur {{ title }} und {{ severity }} gemacht, das reicht meistens um zu sehen obs durchgelaufen ist. Die Details holt man sich dann eh im PVE/PBS wenn was schiefgegangen ist.