Punkt 2 (!): Die drei Volumes enthalten sämtliche Nutzdaten von openHAB. Dabei haben die Volumes unterschiedliche Aufgaben.
conf (entspricht /etc/openhab/): hier werden die Textdateien vorgehalten, wenn jemand "oldschool" das System per Textdateien konfigurieren möchte. Nach alter Lehre ist das Format XText, aber seit openHAB5 kann man hier auch yaml nutzen. Die Textdateien sind aber in jedem Fall für openHAB nur lesbar. openHAB wird selbst
niemals in diese Dateien schreiben. Wenn Du also nicht gezielt Änderungen mittels Texteditor vornimmst, ist die Ordnerstruktur unterhalb des conf-Ordners so, wie bei einer frischen Installation, d.h. es gibt in jedem Ordner eine README Datei und unterhalb services diverse cfg-Dateien, deren Inhalt fast komplett auskommentiert ist.
userdata (entspricht /var/lib/openhab/ - das home-Verzeichnis des Users openhab): Dieses Verzeichnis enthält die gesamte Konfiguration des laufenden openHAB Servers. Wenn Du über den conf-Ordner Änderungen vornimmst, erkennt openHAB das und übernimmt diese Änderungen nach userdata, allerdings in einem anderen Format (abhängig vom Bereich, auf den die Änderung wirkt). Teile der Änderungen unterhalb conf/ werden gar nur im RAM eingelesen
und tauchen nicht unterhalb userdata/ auf.
Nimmst Du Änderungen über die MainUI vor, so findest Du die betreffenden Einstellungen unterhalb userdata/jsondb/. In diesem Ordner gibt es noch einen Ordner backup/, der die letzten fünf Versionen jeder Datei enthält, die durch die Konfiguration geändert wurde.
addons (entspricht /usr/share/openhab/addons/): In diesem Ordner kann man .jar Dateien ablegen, welche (für die Version passende) Bindings enthalten, die nicht über die MainUI installiert werden können - diese manuelle Installation ist dabei als Notbehelf zu verstehen, wenn irgendmöglich sollte man sie vermeiden, auch wenn sie vollkommen zuverlässig funktioniert (für openHAB1 war das die einzige Möglichkeit, Bindings zu installieren, und sie existiert immer noch).
Punkt 3:
userdata/backups/. Bei einem docker Container sollten sich in diesem Ordner
gar keine Dateien befinden. openhab-cli erzeugt beim Backup in diesem Ordner ein zip Archiv mit dem Inhalt der Ordner conf/, userdata/ und addons/ (wobei der Unterordner userdata/backups/ davon ausgenommen wird). In früheren Versionen von openHAB wurde der backup-Ordner fehlerhaft mit archiviert, was dann zu explodierenden Archivgrößen führte. Mit einer aktuellen Version sollte dieser Fehler nicht mehr auftreten.
Falls Du Dein System irgendwann mal von "nativ" auf docker umgestellt hast, hast Du evtl. die Daten in diesem Ordner mit kopiert. Du kannst (und solltest) sie einfach löschen. .tar Backups haben in diesem Ordner nichts zu suchen
Es ist natürlich möglich, dass Du zusätzliche Software installiert hast, welche diesen Ordner missbraucht.
Punkt 1: Neu Aufsetzen von openHAB mit docker... Dazu ist zu sagen, dass die Idee von docker gerade ist, dass ein Container grundsätzlich immer identisch startet, und zwar jedes einzelne Mal, egal, ob frisch installiert oder "seit ewig" in Betrieb. Insofern kannst Du jederzeit ein "jungfräuliches" System erhalten, indem Du den Container löschst, die Volumes leerst und anschließend den Container neu erzeugst. Aber eigentlich möchte man ja eben nicht, dass man jedes Mal wieder alles von vorne einrichten muss, deshalb werden die Nutzdaten ja auch in den Volumes gespeichert. Diese verlieren ihren Inhalt nicht beim Reboot.
Wenn das System rumzickt, wäre der erste Ansatz, die unnötigen Dateien zu entfernen (alles im Ordner userdata/backups/, alles im Ordner userdata/jsondb/backup/).
Weiterhin könntest Du den Cache und das temporäre Verzeichnis leeren (unterhalb userdata die Verzeichnisse cache und tmp), aber Achtung, dazu sollte der Container zunächst gestoppt werden. Beim nächsten Start wird openHAB dann ungewöhnlich lang für den Start benötigen, es kann sogar sein, dass es im log zahlreiche Fehlermeldungen gibt, die minutenlang andauern. Das System lädt alle Addons erneut in den Cache, dabei können wegen des asynchronen Designs teilweise Addons nicht rechtzeitig zur Verfügung stehen, wodurch dann die Fehler auftreten.
So oder so sollte nach dieser Entschlackungskur das System stabil laufen und (70 GByte sind schon ein Brocken) eventuell auch perfomanter agieren.
openHAB5.0.1 stable in einem Debian-Container (trixie, OpenJDK 21 headless runtime) (Proxmox 9.0.6, LXC)
