openhabforum.de

Das sieht doch schon mal sehr gut aus.

Was meinst Du damit, Du kannst es nicht hochfahren? Gibt es Fehlermeldungen?

udo1toni hat geschrieben: ↑28. Sep 2021 00:53 Das sieht doch schon mal sehr gut aus.

Ja, somit ist das Script doch so schlau die Pfade anzupassen

udo1toni hat geschrieben: ↑28. Sep 2021 00:53 Was meinst Du damit, Du kannst es nicht hochfahren? Gibt es Fehlermeldungen?

Jain
Ich wollte dies nur nicht mehr gestern Abend machen und somit evtl wieder eine Nachtschicht machen.
Erwartungsgemäß kamen dann heute Morgen beim starten einige Meldungen

a) Die Uhrzeit spinnte, wahrscheinlich weil zwei OH Instanzen mit der gleichen Konfig - wenn auch unterschiedlichen IPs - liefen
b) Es fehlten die manuell installierten Add-Ons, die musste ich manuell kopieren
c) Die Pfade zum MQTT Broker und der DB waren noch veraltet, diese hatte ich bei der Aktion auf ein anderes System umgezogen
d) Die hart verdrahteten Pfade für Ephemeris Dateien in einer Rule
e) Es kamen einige Validation Meldungen aus diversen Rules

Ich werde mir dies dann noch einmal in Ruhe anschauen und berichten.

Uhrzeit:

Hast Du mittels dpkg-reconfigure tzdata die Systemzeit auf eingestellt? Der LXC bezieht seine Clock gewöhnlich aus dem Host System. Es hilft nicht, einen ntp Client zu installieren, da der Container keine eigene Uhr hat. Auch im Host sollte also die Uhrzeit korrekt eingestellt und der eingebaute NTP Client aktiv sein.

Der Proxmox Host nutzt timesyncd um die Uhrzeit zu stellen. Du kannst die zu verwendenden Server in der Datei /etc/systemd/timesyncd.conf angeben. Falls Du nichts konfigurierst, verwendet Debian die debian Timeserver.

Wenn Du etwas an der Konfiguration änderst, musst Du den Dienst systemd-timesyncd.service neu starten (systemctl restart systemd-timesyncd.service).
Ob der ntp Client aktiv ist, kannst Du mit timedatectl timesync-status anzeigen lassen.

Da Rechner im gleichen Netzwerk nur dann sekundengenau synchron laufen, wenn man extra Hand anlegt (und Windows nur mit Zusatzsoftware dazu zu bewegen ist, sich zuverlässig zu synchronisieren), ist es sehr wahrscheinlich, dass Du zumindest Abweichungen im Bereich mehrerer Sekunden hast, was dann natürlich zu Kuddelmuddel führt, zumal alle openHAB Instanzen, die auf die gleichen Geräte schauen, alle Änderungen aller anderen openHAB Instanzen mitbekommen

Finally

DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
iiiiiiiiiiiiiii Skynet iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
ggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggg
DD Ip -> yy.xx.cc.vv
DD Release -> Debian GNU/Linux 11 (bullseye)
DD Kernel -> Linux 5.11.22-4-pve
DD Platform -> lxc
DD Uptime -> 0 day(s). 0:36:33
DD CPU Usage -> 6.19% avg over 2 cpu(s) (4 core(s) x 1 socket(s))
DD CPU Load -> 1m: 0.50, 5m: 0.39, 15m: 0.39
DD Memory -> Free: 2.20GB (55%), Used: 1.79GB (45%), Total: 4.00GB
DD Swap -> Free: 4.00GB (100%), Used: 0.00GB (0%), Total: 4.00GB
DD Root -> Free: 28.94GB (89%), Used: 3.44GB (11%), Total: 34.15GB
DD Updates -> 0 apt updates available.
DD Sessions -> 1 session(s)
DD Processes -> 36 running processes of 4194304 maximum processes
SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS

Dies ist nun ein von scratch aufgesetztes System, somit sollten viele mögliche Fehlerquellen eleminiert sein.
Ich habe direkt bei der Installation von openHABian ein aktuelles Backup zurückgespielt und somit war openHAB nach der Installation direkt betriebsbereit. Die Rules (war nur 1 Datei) habe ich von "C:/" bereinigt, die Pfade zu den Hintergrundbildern mit der neuen IP angepasst und derzeit läuft das Log wie ein Kätzchen schnurrt. Ich hoffe, dies bleibt erst einmal so und ich kann mich nun um "automatische" Backups etc kümmern.

Ich hätte nicht gedacht, dass ich diesen Schritt (Windows => Linux) mache aber die ungeplanten Reboots (nicht nur nach Updates) waren schlicht nicht haltbar.

VIELEN DANK für die Unterstützung und Geduld!!

Super! Ich drücke Dir die Daumen, dass Du nun erst mal Ruhe vor ungeplanter Downtime hast.

Wegen Upgrades unter Proxmox: Proxmox selbst lässt sich ja sehr bequem über die GUI upgraden. Einen Reboot kannst Du dabei immer auf einen Dir genehmen Zeitpunkt verschieben. Natürlich sollte man damit nicht ewig warten, schließlich möchten man den neuen Kernel möglichst nativ laufen lassen. VM oder Container sollte man möglichst nach dem Host upgraden, insbesondere, wenn ein Versionswechsel ansteht, denn der Container läuft ja auf dme Host Kernel. eine VM kann Treiber enthalten, die dann eventuell einen neueren Kernel im Host benötigen. Wobei da die Gafehr nicht so groß ist, solange man nicht Jahre mit den Updates hintendran ist - die Treiber und Kernel sind allgemein immer über ein paar Versionen kompatibel.

Was Backups betrifft, empfehle ich Dir zfs autosnapshot. Damit legt das Host in einstellbaren Intervallen Snapshots der Datasets und/oder Zvols an, mit einstellbaren Aufhebezeiten. Dabei benötigt ein Snapshot nur den Platz der Differenz zum vorherigen Snapshot. Man kann zu jedem Snapshot zurückkehren, man kann aber auch sehr bequem auf einzelne Dateien zugreifen, also um z.B. gezielt auf eine alte Konfiguration zuzugreifen.
z.B. hebt man die letzten 12 Snapshots im 15-Minuten-Rhythmus auf, die letzten 8 stündlichen Snapshots, die letzten 7 täglichen Snapshots, die letzten 5 wöchentlichen, die letzten 6 monatlichen Snapshots. Macht dann insgesamt 38 Snapshots mit der Möglichkeit, den jeweiligen Stand wiederherzustellen. Dabei wird im Normalfall der Speicherbedarf vielleicht gerade mal auf das doppelte ansteigen. Und weil das Ganze automatisch abläuft, kann man es nicht vergessen.

Das ist natürlich kein echtes Backup, weil die Daten ja nicht auf einem anderen Laufwerk liegen. ein solches sollte man also trotzdem ab und zu anfertigen. Falls Du aber ein Spielkind bist (wie ich...), kannst Du noch ein zweites System aufsetzen, welches automatisch nachts startet, ein Diff zieht und sich wieder schlafen legt. Das geht dann mit zfs backup. Dabei ist diese Variante sogar trojanersicher, weil der Backupserver die Daten anfordert. Selbst wenn jemand also das Hauptsystem kompromittiert, kann er nicht auf die Backups zugreifen.
Für ein solches Backupsystem könnte man sogar einen Raspberry nutzen, NasBeery wäre da ein Stichwort (wobei der sich nicht gut schlafen legen lässt...)

Spielkind?? Ich?? NIEMALS Wo ist meine Märklin??

zfs auto snapshot scheint aber nicht mehr supported bzw. bald nicht mehr. Eine Alternative scheint hier => https://github.com/Corsinvest/cv4pve-autosnap Habe ich über Tante Google und dem Link https://ask.linuxmuster.net/t/proxmox-w ... howto/7357 gefunden. Mal sehen, ob dies etwas für mich tun kann.

Backup habe ich gelesen, könnte ich evtl. auch mein 7*24 QNAP heranziehen. Aber one step after the other

cv4pve-autosnap sieht nicht uninteressant aus. Insbesondere, dass die Snapshots in der GUI von Proxmox auftauchen sollen, ist natürlich schick.

Allerdings... zum einen klingt Corsinvest für mich nicht nach Open Source... Mag aber sein, dass ich da falsch liege.

Die andere Sache ist, zfs-auto-snapshot ist ein Bash Script. Es nutzt native Funktionen von ZFS, da kann gar nichts "nicht unterstützt" werden, weil es komplett unabhängig von Proxmox ist.

udo1toni hat geschrieben: ↑29. Sep 2021 20:48 Es nutzt native Funktionen von ZFS, da kann gar nichts "nicht unterstützt" werden, weil es komplett unabhängig von Proxmox ist.

Hmm, hätte ich den Proxmox dann mit ZFS installieren müssen?? Ich habe dies nur durchgeklickert und meine da war kein ZFS.
Zur Not müsste ich den halt noch einmal neu aufsetzen, kann von den Containern ja ein Backup machen.

Proxmox nutzt normalerweise ZFS das Dateisystem. Du kannst leicht prüfen, welches Dateisystem Du nutzt, schau einfach auf dem Knoten auf die Disks.

Hmm, da bin ich wohl falsch abgebogen. Bei mir steht bei der Hauptpartition LVM.
Ich habe ja "nur" 1 256GB SSD eingebaut