Umzug auf OH4 => Fragen zu externer SSD, Persistence etc

[Jensemann_P]

Hi Leute,

bei mir steht ja noch das update/Neuinstallation auf OH 4 aus.
Welche Fallstricke sind denn allgemein zu erwarten, was muss man evtl an Rules/conversions etc anpassen?
Werden denn alle Geräte (Enocean-Stick usw) auch wieder erkannt oder muss man die dann neu einbinden? Bleiben die Things erhalten?

Und vor allem: Ich hab ja auf externer SSD am Raspi laufen (nachträglich umgezogen). Nach verschossener Installation durch falsches Upgrade, zurücksopielen einer raspi-backup sicherung hat das nie wieder so 100% gepasst. z.B. geht Raspibackup nicht mehr gescheit. Ist also ein bisschen verbollert.

Wie gehe ich da bei der Neuinstallation am besten vor? Auch erst mal auf SD Karte und dann verschieben? Zweite externe SSD hab ich leider nicht. Werd ich aber vlt anschaffen um auch ab und an ein Vollbackup fahren zu können. Macht das Sinn? Bzw hätte auch ne mechanische in ähnlicher Größe die für Backupzwecke herhalten könnte (und z.B. als Zwischenmedium bis alles läuft bevor ich die Produktive von jetzt überschreibe).

Ich habe bisher meine Persistence auf Mariadb laufen. Merke nun aber, dass mir ne Round Robin-Variante völlig ausreicht. Die einzigen Daten die ich so detailliert sehen will im Nachhinein sind die von der PV und die hab ich über Solar Assistant eh nochmal einzeln Vorliegen und mache da ab und an n Backup. Vorteil von der integrierten PErsistence ist ja, dass es dann in nem normalen OH Backup alles mit drin ist wenn ich das richtig verstehe?
Wenn ich nun von Mariadb zu RRD4j wechsle, fängt dann alles von 0 an oder können da die Bestandsdaten übernommen werden?

Hoffe auf ein wenig Input und vor allem wünsche ich allen erst mal einen guten Rutsch ins neue Jahr!

[udo1toni]

Ob Du bei der SSD bleibst oder wieder einer SD-Karte verwendest, ist letztlich Geschmacksache, notwendig ist es nicht.
ZRAM schützt die Karte vor Wearout, das einzige, was man als Argument heranziehen könnte, wäre die höhere Geschwindigkeit, die aber keine echte Relevanz hat.
Was das Backup betrifft, so möchte ich eher das openHAB Backup empfehlen (Auf Wunsch auch mit rrd4j und mapDB). Das Backup nur der Konfiguration und Persistence hat den Vorteil, dass man nicht ständig die Kapazität der SD-Karten erhöhen muss - das passiert nämlich gerne bei einem Vollbackup von SD-Karten. Natürlich kann man auch dafür sorgen, dass es hier keine Probleme gibt indem man die Partitionsgröße bewusst nicht auf die ganze SD-Karte ausweitet, sondern etwas Platz frei lässt, so dass alle Daten sicher auf eine nominell gleich große SD-Karte passen. Dieses Problem trifft im Übrigen auch auf SSDs zu, und sogar auf gewöhnliche Festplatten
Du kannst natürlich auch Vollbackups machen, dann wäre aber eine der wenigen sinnvollen Strategien, ein Vollbackup zu erstellen und anschließend die Karten zu tauschen, denn nur so kannst Du Dir sicher sein, dass die gerade nicht genutzte Karte (also die bis zuletzt aktive) intakt ist. Und natürlich, dass das Backup (welches nun die aktive Karte ist) ebenfalls ok ist. Der Aufwand ist aber zu hoch, um das täglich zu erledigen, deshalb ist es sinnvoller, per openhab-cli Backups zu erstellen (mit Persistence gewöhnlich weniger als 150MByte pro zip-Datei) und davon vielleicht auch mehrere aufzubewahren, das geht auch täglich, per Script auch automatisch.

Mit dem Pi Imager kann man innerhalb weniger Minuten eine SD-Karte mit dem jeweils aktuellen openHABian Image versehen, ein aktuelles Backup mit auf die Karte kopieren und anschließend richtet das Image vollautomatisch die aktuelle Version samt Datenübernahme ein, dauert etwa 30 Minuten (alles inclusive) und das System ist dann sauber eingerichtet. Das schleißt natürlich nur openHAB selbst ein, nicht aber Sekundärsoftware (mosquitto usw.), aber zumindest ein Standardsystem ist so schneller wider betriebsbereit als wenn man ein Vollbackup zurückspielen muss.

Was die Persistence betrifft, so gibt es keine Möglichkeit, Daten aus MariaDB nach rrd4j zu schaffen (es sei denn, Du schreibst dafür selbst ein Programm). Allerdings stellt sich nicht unbedingt die Frage "entweder oder", Du kannst mehrere Persistence Services parallel betreiben, und zwar pro Item das macht evtl. etwas mehr Arbeit, am Ende hast Du aber das Beste aus beiden Welten - vielleicht auch nur übergangsweise, bis Dir die "neue" Historie ausreicht.

Was notwendige Anpassungen betrifft, so hast Du leider verschwiegen, von welcher (exakten) Version Du kommst. Grundsätzlich: je älter die Quellversion, umso mehr Arbeit kommt auf Dich zu.

[Jensemann_P]

Danke für die ausführliche Antwort.

Ich komme derzeit von openhabian 3.4.2

Wenn sich das mit dem wearout in Grenzen hält werde ich wohl auch wieder mit ner (diesmal hochwertigen) SD Karte weiter machen. Die asd war damals über und durch mariadb und die Vollbackups war mir das auch lieber.

[Jensemann_P]

Ich hab noch n rpi da, wenn ich eh auf SD gehe kann ich mir ja schon Mal ne gute besorgen und das parallel aufsetzen und schauen wie die Migration läuft.

So wie ich mir bisher die Vollbackups aufs Nas geschoben habe kann ich das ja dann auch mit der internen tun und nach größeren Änderungen vlt zusätzlich die Karte komplett klonen und rotierend weiter arbeiten. Das kommt ja auch nicht sooo häufig vor.

[Jensemann_P]

Mein sonstiges "Nebenzeug" ist eigentlich nur pihole, aber das wäre ja auch schnell wieder eingerichtet.

[Jensemann_P]

Ah, wobei. Ich hab Tablets mit habpanel am laufen. Sind nachinstallieren controls in der oh Sicherung mit drin?

Gibt's denn besonders zu empfehlende Micro SD Karten?
Ich kenne aus dem Foto/Filmbereich natürlich ein paar gute bis professionelle Modelle, aber ehrlich gesagt weiss ich nicht ob die Optimierungen von dort (konstant hohe Datenraten bei großen Dateien) auch auf dem rpi was bringen oder auf was es da sonst noch an kommt. Normal greife ich zu EVO plus oder hoherwertig, aber vlt ist ja was ganz anderes der heilige gral. Was nimmt man größentechnisch? 64gb?

[udo1toni]

Ein zweiter Pi ist eine sehr gute Sache, um schon im Vorfeld zu testen - natürlich immer mit Datenübernahme aus dem Produktivsystem über sudo openhab-cli backup --full

Die HABPanel controls werden vermutlich nur insofern mitgesichert, wie sie auf dem openHAB Server liegen, HABPanel läuft ja zumindest in Teilen auf dem Client.

Ach so... SD-Karte... Also meine Empfehlung geht eher in Richtung 16 GByte. Nach der Installation und damit verbundener Vergrößerung der 2. Partition auf die Restkapazität wäre meine Empfehlung, die 2. Partition auf 15 GByte zu verkleinern - das geht leider nicht im laufenden Betrieb, da es sich ja um die root Partition / handelt, aber wenn Du einen Micro-SD-Card Reader hast, den Du per USB am Pi anschließen kannst, dann kannst Du das aus einem anderen laufenden System heraus machen. Oder Du startest den Pi über die alte SSD und steckst erst danach die Micro-SD-Karte wieder in den dafür vorgesehenen Slot, wichtig ist halt, dass die 2. Partition nicht eingebunden ist, dann kannst Du z.B. mit parted die 2. Partition verkleinern, so dass sie eben klein genug ist, um sicher auf eine andere 16 GByte Karte kopiert werden zu können. Es empfiehlt sich immer, das gleich nach dem Vergrößern durch den ersten Start zu erledigen, weil zu diesem Zeitpunkt fast sicher keinerlei Daten verschoben werden müssen, also geht das auch schnell vonstatten.
Da ZRAM die Anzahl der Schreibzugriffe auf ein Minimum senkt, gibt es keine außergewöhnlich hohen Ansprüche an die SD-Karte, vielleicht nicht gerade vom Grabbeltisch oder als No-Name-Import aus China...
Es gibt übrigens noch eine weitere Variante, die auch interessant sein kann, und zwar das OS von SD-KArte zu betreiben, die Daten aber auf einem anderen Datenträger (z.B. SSD) auszulagern. Dabei kann man es so drehen, dass die SD-Karte tatsächlich ro gemountet wird. Man muss dann allerdings bei Upgrades zunächst mit rw remounten und anschließend neu starten, damit man überhaupt erfolgreich updaten kann, das ist aber eine gute Option, um absolut sicher vor Wearout der SD-Karte zu sein. Für die Daten erstellt man dann auf der SSD verschiedene kleine Partitionen, die man an der betreffenden Stelle ins Dateisystem einhängt, so dass die Schreibzugriffe auf z.B. $OPENHAB_CONF (/etc/openhab/) dann auf der SSD in einer eigenen kleinen Partition landen, genau wie $OPENHAB_USERDATA und evtl. auch /var/lib/mysql/, und wenn man die SSD mit lvm einrichtet, kann man gar mit Snapshots arbeiten, um im laufenden Betrieb jederzeit Backups ziehen zu können, ohne Angst haben zu müssen, anschließend vielleicht ein inkonsistentes Dateisystem zu haben.

[Jensemann_P]

Hallo nochmal, das klingt mir dann doch auch wieder nach recht vielen Schritten. Mein halbdisaster hat mich zu keep it simple ab der Ecke gepusht. Ich hab mir jetzt zwei gleiche SD Karten besorgt und werde zusätzlich zu den oh eigenen Backups die ich aufs Nas schiebe ab und an rotierend spiegeln, das sollte dann passen.

Mit was hab ich denn rule/thingseitig oder treibermäßig an Nacharbeit zu rechnen bzw auf was besonders achten? Von 3.4.2 kommend?

Installiere ich dann ein aktuelles openhabian neu und lese ein oder macht es Sinn ein oh3.4 auf aktuelleren linux als Grundstock zu nehmen, einzulesen und danach upgraden?

[udo1toni]

Von 3.4.2 kommend sollten keine größeren Probleme auftreten.
Zieh Dir ein Backup (openhab-cli backup) und speichere die zip-Datei unter dem Namen initial.zip auf die erste Partition der openHABian SD-Karte, dann wird openHABian Deine Konfiguration automatisch einlesen und im Zweifel auch anpassen (nur, was über die UI angelegt wurde).

Wichtigste Änderung 3.4 -> 4.x: Es gibt kein Script Transformation Addon mehr. aber keine Angst (falls Du das genutzt hast), die Funktionalität ist immer noch gegeben, nur kümmert sich nun die installierte Script Engine darum. Das bedeutet, Du musst JavaScript Scripting installieren, falls Du eine JS Transformation nutzt. Hintergrund dazu: Du kannst nun jede Script Engine nutzen, um Transformations durchzuführen, z.B. auch die DSL.
Außerdem ist nun Graal die aktuelle JS Engine, nicht mehr Nashorn, daraus ergeben sich etliche Änderungen am Code. Es sollte aber reichen, die JS Rules einmal zu öffnen und neu zu speichern, openHAB sollte den Code dann selbständig anpassen (immer vorausgesetzt, Du hast Graal auch installiert...)

Es gibt etliche Dinge, die in der UI nun an anderer als der gewohnten Stelle zu finden sind - schau Dich einfach aufmerksam um Insbesondere kannst Du direkt in der UI die Log Level für Addons manipulieren und auch die Persistence in jedem Detail konfigurieren (welches Item wann wie persistieren)

Und natürlich solltest Du ein besonderes Augenmerk auf Deine verwendeten Addons haben, am besten schaust Du in die Release Notes, dort sind alle Änderungen gelistet.

[Jensemann_P]

Ich wäre nun soweit das mal durchspielen zu können. Wie spiele ich das backup dann ein? Einfach über die bestehenden Ordner drüber bügeln, bevor ich am neuen OH irgendetwas einrichte?
Oder erst Grundeinrichten und dann irgendeine Art Import ausführen? Bekomme ich auf die Art irgendeine Migration und Ausgabe hin wie wenn ich aus dem laufenden heraus upgrade, oder muss ich dann einfach alles durchschauen wo es klemmt?

Transformation hatte ich nur eine einzige, sollte dann ja nicht der riesige Aufwand sein.