openhabforum.de

Gewöhnlich kannst Du ein jungfräuliches openHABian System nehmen und das Backup des "Altsystems" auf der ersten Partition unter dem Namen initial.zip abspeichern (oder den entsprechenden Eintrag in der openhabian.conf anpassen).
openHABian wird dann beim Einrichten des Systems automatisch das Backup einspielen. Ansonsten kannst Du das natürlich auch selbst manuell machen, ob nun über openhabian-config oder über openhab-cli restore und wenn alle Stricke reißen (sprich, Du musst unbedingt ein selektives restore ausführen) kannst Du natürlich auch Datei für Datei austauschen.

Jetzt bin ich doch tatsächlich mal endlich dazu gekommen und kann positiv berichten, dass die ganze Aktion in ca 3 Stunden durch war.

Ich hab nochmal eine SD Karte frisch erstellt, wollte das Backup dass ich noch hatte aufspielen => zu groß (mit knapp 500MB) um auf die WIN-lesbare Partition zu passen. Hmm. Hatte ich mal per Kommandozeile mit der Option full erstellt. Vielleicht wird da noch der ganze Cache o.ä. mit genommen?

Also nochmal eines über das Openhab-Textmenü erstellt, das war dann mit um die 30MB deutlich handlicher.

Also dann als Zip unter dem entsprechenden Namen drauf gepackt, die Karte in den Produktiv-Raspi, die USB-SSD abgezogen und gebootet. Erst mal ne Weile geschäftig wursteln lassen, Passwörter wieder angepasst und es lief schon erstaunlich schnell erstaunlich viel. Die Blockly-Rules musste ich alle 1x öffnen und speichern, die paar JS und XSL-Transformations hat es automatisch mitgenommen und sind jetzt auch im entsprechenden Punkt unter Settings sichtbar. Ich muss noch ein Javascript-Modul nachinstallieren und in den wenigen JS-Textrules ein bisschen was anpassen.
Im Header folgende Variable anlegen: var runtime = require('@runtime');
und vor restlos jeden aufruf der auf OH-Objekte zugreift "runtime" setzen. Hier ein angepasstes Beispiel:
Ein paar Fehler hatte ich noch vom Shelly Binding, das hat sich aber mit einem Neustart der ganzen Maschine gegeben.
Da das handling der Einheiten jetzt anders aber dafür konsistenter zu laufen scheint, war an der ein oder anderen Stelle noch in den items etwas anzupassen (Einheiten bzw State descriptions), weil ich an ein paar Stellen sowas wie "2300%" hatte.

Ich hab jetzt noch nicht ganz nahcgelesen/nachvollzogen was sich da genau getan hat, habe aber das Gefühl, dass man jetzt auf einen Einheitlichen Pfad "gezwungen" wird. 1x Arbeit, dafür passts danach auch. Einige Rules musste ich dann noch anpassen, weil dann eben keine reinen Zahlenwerte mehr aus den items zurück kommen. In den entsprechenden Fällen zum Rechnen in Blockly also "get numeric state of item" anstatt wie vorher einfach get state of item abrufen.

Es war also schon ein bisschen Arbeit und knobeln und kann auch sein, dass an der ein oder anderen stelle mal nochw as auftaucht, aber insgesamt gings doch vergleichsweise gut über die Bühne und ich hab jetzt mal wieder eine aktuelle Version auf einem nicht halb zerschossenen Grundsystem laufen. Schon ein besseres Gefühl.

Was mich gewundert hat: Ich hatte ja vorher mariaDB und bin nun wieder auf rr4dj. Dennoch kann ich in den Grafen zu z.B. verbräuchen monatelang zurück schauen. Darauf konnte ich mir noch keinen großen Reim machen, ich wäre jetzt davon ausgegangen dass die Persistence jetzt erstmal genullt ist.

Danke auf jeden Fall für die Hilfestellungen hier, ich hab schon gesehen dass es viele interessante neue bindings gibt, konnte schon neuere Shellys einbinden die vorher gezickt haben usw. Jetzt bring ich noch n automatisiertes OH-Backup mit ablage auf der NAS ans laufen und gut ist. Da das mit dem Grundsystem und einlesen so geflutscht ist und ansonsten auf der Maschine ja nur pihole läuft, werde ich mir die Idee mit dem Vollbackup dann auch kneifen und nur die OH Eigene Funktion nutzen.

Liebe Grüße
Jens

Das klingt ja prima!

Jensemann_P hat geschrieben: ↑6. Feb 2024 09:00 Was mich gewundert hat: Ich hatte ja vorher mariaDB und bin nun wieder auf rr4dj. Dennoch kann ich in den Grafen zu z.B. verbräuchen monatelang zurück schauen. Darauf konnte ich mir noch keinen großen Reim machen, ich wäre jetzt davon ausgegangen dass die Persistence jetzt erstmal genullt ist.

Das ist in der Tat etwas seltsam... In dem Backup, welches Du nicht mit in die erste Partition packen konntest (also das mit der Option --full erstellte), sind mit Sicherheit auch rrd4j Daten enthalten, und je nachdem, was im alten System konfiguriert war, können dort die fraglichen Daten parallel abgespeichert vorliegen. Nur hast Du dieses Backup ja gar nicht eingespielt...

Vollbackup vs. explizites Backup: Grundsätzlich ist es eine gute Idee, ein funktionales Backup rumliegen zu haben, für den Fall, dass der Datenträger komplett ausfällt.
Auf der anderen Seite ist das neu Erstellen eines Raspberry Pi Systems mit openHABian keine zeitraubende Angelegenheit mehr, viel wichtiger ist also eine feingranulare Sicherung der Konfiguration (bestenfalls mehrfach täglich), so dass man von einem neu aufgesetzten System sehr schnell wieder auf den aktuellen Stand kommt. Diese explizite Sicherung muss also so oder so erfolgen, da es nicht sinnvoll erscheint, täglich Vollbackups durchzuführen.
Und noch ein sehr wichtiger Punkt: Selbstverständlich muss man nach jedem Vollbackup sicherstellen, dass das Backup auch funktional ist. Ein guter Weg (gibt hier im Forum dazu einen Thread) ist, das Backup zu erstellen, anschließend das System herunterzufahren und den Rechner vom Backup zu booten und auch zu betreiben.
Nachteilig daran ist die erzwungene Downtime, dafür weiß man aber sicher, dass der in der Schublade liegende Datenträger beim letzten Einsatz funktional war und das System ordnungsgemäß heruntergefahren wurde.

Blick über den Tellerrand: In Sachen Komfort, das Backup betreffend, ist Virtualisierung ein wichtiges Stichwort. Direkt auf einem Raspberry als Host wäre hier Docker zu nennen, es gibt für alle Funktionen, die openHABian mitbringt auch Docker Container.
Man setzt also einen Docker Stack auf (eine Kopmbination mehrerer Container), der openHAB, frontail, samba usw. enthält. Sämtliche Konfiguration wird in sogenannten Volumes gespeichert, die sich prima per Cron-Job sichern lassen. Funktioniert etwas nicht mehr, wirft man den Container weg und lässt ihn neu erzeugen. Die Konfiguration wird dabei automatisch übernommen. Auch Updates/Upgrades sind so einfach möglich - wobei man natürlich die notwendigen Änderungen an der Konfiguration selbst vornehmen muss, falls das Upgrade dies nicht automatisch erledigt.
Docker aufzusetzen geht innerhalb weniger Minuten (von einem fertig eingerichteten Raspberry Pi OS lite ausgehend), die ersten Container in Betrieb zu nehmen dauert nicht länger, und man kann die entsprechenden Scripte bequem sichern und beim nächsten Mal einfach zurückspielen - dann geht das komplette Setup locker in einer halben Stunde über die Bühne.
Nachteil der Docker-Lösung: direkter Hardware Zugriff (GPIO) und Shell-Scripte müssen anders gestaltet werden, als man das von openHABian gewohnt ist.
Ich habe so viele Dienste in meinem Netzwerk, (darunter auch komplette Windows Systeme, auf die ich dann remote zugreife), dass ich keinen Pi dafür einsetze und entsprechend mit der potenteren Hardware auf Proxmox als Virtualisierungsumgebung zurückgreifen kann. Da läuft das Backup dann über das Filesystem ZFS mit viertelstündlichen Snapshots und einem täglichen Backup auf ein externes System - Bei einem kompletten Crash (da müssten dann zwei Datenträger innerhalb sehr kurzer Zeit ausfallen) bekomme ich den Stand von... Ähh.. ca. 4 Uhr früh des aktuellen (vor 4 Uhr den des Vor-) Tages, lösche ich versehentlich eine Datei so bekomme ich sie von der letzten Viertelstunde zurück - sehr nett bei System Upgrades, die etwas zu viel upgraden... Rollback ist innerhalb von Sekunden(!) erledigt.