Die Frage an dieser Stelle wäre zunächst: Muss dass wirklich sein? Die meisten Systeme (auch etablierter Hersteller) sind vom Sicherheitsniveau kurz vor dem Supergau. Du kannst dann quasi den Ersatzschlüssel unter die Fußmatte legen, ist etwa das gleiche...
Selbstbaulösungen, die mechanisch zuverlässig funktionieren können ebenso eine Herausforderung darstellen wie die Softwareseite, die man aber wenigstens ein bisschen sicherer gestalten kann, als per Zwangscloud und Vollzugriff für eine unbestimmte Anzahl Personen (gerade gestern ein Kurzvideo gesehen von einem System, welches angeblich mit rolling Code arbeitet - dummerweise reichte ein einfaches Replay, um das Schloss zuverlässig mit einem unberechtigten Sender zu öffnen - traue keinem Hersteller...).
So, genug Rant
Ich nutze bei mir einen selbstgebauten "großen" Server, der freilich mehr Aufgaben übernimmt als nur openHAB. Auf diesem Server läuft Proxmox, welches Virtualisierung und Container bietet - leider nicht mit Docker, aber dafür läuft bei mir in einem LX-Container eine Docker Instanz
Proxmox bringt als Dateisystem ZFS mit, welches für wirklich große Speicher ausgelegt ist - passende Vorsilben gibt es da nicht mehr, aber Exabyte oder Petabyte könnte man bequem als einzelnes Volume verwenden (wäre natürlich nicht sinnvoll, aber darum soll es hier nicht gehen).
Und man könnte Abermilliarden solche Volumes parallel... egal...
Der eigentliche Punkt bei ZFS ist aber, dass es sich um COW (Copy On Write) Dateisystem handelt, das heißt, ein Schreibzugriff auf eine bestehende Datei wird ausnahmslos durch Kopieren der Datei ausgeführt - jede noch so kleine Änderung erzeugt eine Kopie der bearbeiteten Datei, anschließend wird das Original als gelöscht gekennzeichnet - natürlich werden nur die Blöcke geschrieben, die auch verändert wurden, wenn ich also in einer 10 MByte mp3 Datei Tags ändere, werden eben nur die paar KByte geschrieben, die davon betroffen sind, alles andere bleibt unveändert.
Deshalb ist es (vorausgesetzt die Hardware ist intakt) nicht möglich, ein solches Dateisystem versehentlich zu korrumpieren.
Weiterhin legt ZFS auf Wunsch regelmäßig Snapshots an und löscht diese auch wieder, alles automatisch und ohne dass man davon etwas mitbekommt.
Und Schließlich kann man ein zweites System mit ZFS dazu überreden, in regelmäßigen Abständen ein differenzielles Backup der Snapshots zu ziehen. Dabei werden also nur die Unterschiede seit dem letzten Backup auf das Zweitsystem gezogen.
Proxmox kann selbstverständlich so konfiguriert werden, dass beim Ausfall eines Knotens bestimmte Container oder virtuelle Maschinen vollautomatisch auf einen anderen Knoten umziehen - Stichwort High availability.
Umgesetzt habe ich das bei mir aber nicht, denn wenn auch bei mir genug Dinge über openHAB laufen, dass es schon zu merklichem Komfortverlust führt, wenn openHAB nicht zur Verfügung steht, so kann ich doch das System jederzeit binnen weniger Minuten wieder an den Start bringen.
Die USV steht allerdings immer noch neben dem Serverschrank - nicht angeschlossen, versteht sich. Das wäre noch am ehesten eine Sache, die ich mal in Angriff nehmen müsste.
Aber gerade die USV-Nummer wäre auch mit einem Pi 4 sehr leicht umsetzbar, dafür gibt es extra HATs die alles beinhalten, die Stromversorgung wird dann am HAT angeschlossen, der zum Einen einen kleinen Akku lädt und zum Anderen den Pi auffordert geordnet herunterzufahren, sollte mal der Strom ausfallen. Und im Zweifel bleibt dann auch noch genug Zeit, vorher über openHAB einen Alarm abzusetzen.
Für den Schutz gegen ein defektes Dateisystem gibt es mehrere Optionen, meine Lösung dazu wäre eine andere als von openHABian vorgegeben.
Wenn openHAB bei mir auf einem Raspberry liefe, würde ich das Betriebssystem auf eine SD-Karte speichern und diese nur lesbar mounten (dazu gibt es in raspi-config(?) einen eigenen Menüpunkt). Damit ist es nicht nur ausgeschlossen, dass die Karte durch zu viele Schreibzugriffe zerstört wird, es ist auch so, dass das System nach einem Reboot immer in einem unveränderlichen definierten Zustand ist. Damit dennoch Daten gespeichert werden können würde ich eine SSD mittels USB anschließen und dort Partitionen ablegen, die man dann ins root Dateisystem einbinden kann.
Eine weitere Option wäre natürlich, Freigaben auf einem NAS einzurichten und dort Daten zu speichern - allerdings müssen dann beide Systeme funktionieren und z.B. bei einem Stromausfall auch das NAS bis zum letzten Moment verfügbar sein.
Ich habe seit Jahren keine Abstürze mehr gehabt (die nicht gut durch... Ähm... äußere Umstände erklärbar waren), aber für die eigene Beruhigung gibt es im Raspberry einen eingebauten Watchdog, der mit wenigen Handgriffen aktiviert werden kann. Ab dann muss ein Programm regelmäßig ein Lebenszeichen geben (einstellbar...) sonst löst der Watchdog einen Neustart des Rechners aus. Auf diese Weise kann man sicherstellen, dass ein hängendes openHAB-System von selbst wieder startet - vorausgesetzt natürlich, es hängt nicht weil jemand Dummheiten gemacht hat...
Für ein regelmäßiges Backup der Konfiguration und evtl. anderer Daten braucht es dann ein zweites System, welches diese Daten auch selbst abholen sollte (Pullverfahren), statt dass der Rechner seine Daten dort abliefert. Vorteil: Das Backupsystem muss vom Normalsystem nicht erreichbar sein, ein Angreifer kann also vielleicht das Normalsystem korrumpieren, hat aber keine Möglichkeit, alte Backups zu zerstören. (wie oben erwähnt mache ich das per ZFS, das geht aber auch mit anderen Werkzeugen, nur nicht so komfortabel)
openHABian als Image ist sehr komfortabel, hat aber leider inzwischen einige ernsthafte Probleme (nur meine persönliche Einschätzung). Deutlich besser beherrschbar wäre das Ganze mit Docker (welches auch auf dem Raspberry eine gute Figur macht) - und man kann so gut wie alles, was über ein "konventionelles" System geht, auch mit Docker abbilden, sei es die Freigabe verschiedener Bereiche des Dateisystems (conf, userdata, addons), sei es frontail, seien es zusätzliche Dienste wie ein mqtt Server, für ziemlich alles gibt es inzwischen Docker Container - und auch für eine Menge Software, die man über openHABian gar nicht oder nur mit hohen Hürden an den Start bringt.
Es gibt im englischen Forum sogar schon ein paar "Kochrezepte" welche Container man denn so brauchen könnte.
Natürlich muss auch ein Docker System regelmäßig gewartet werden und schon gar nicht läuft es ohne eigenes Zutun, aber insgesamt erscheint mir der Ansatz deutlich flexibler, es ist eben hochgradig modular. Man benötigt einen Fileserver, bitte, samba-container, danke. Men möchte Logs über die Websschnittstelle, bitte, frontail container, danke (die Konfiguration dafür kann man leicht aus einem openHAB System entnehmen, so dass man keinen Unterschied zu openHABian bemerkt). Update des openHAB Containers? bitte, openhab-down openhab-recreate, danke. (zumindest wenn man es über Portainer macht, das ist eine Weboberfläche um docker zu administrieren) Es ist echt erschreckend simpel (man sollte sich natürlich in die Materie einarbeiten...)
Natürlich kann ein Pi auch tatsächlich kaputt gehen, wobei das eher die absolute Ausnahme sein dürfte - am ehesten wird es die SD-Karte sein, wenn sie nicht ReadOnly betrieben wird, oder meinetwegen auch eine SSD oder ein USB-Stick. Insgesamt kann man aber mit überschaubarem finanziellen Aufwand Reserve Hardware bereithalten - und die muss nicht mal in der Ecke verstauben, man kann sie für Tests regelmäßig nutzen (nur sollte man sie nicht für dauerhafte Nutzung zweckentfremden...)
All das geht natürlich auch mit anderen Hardware Plattformen, aber gewöhnlich ist der Pi 4 mit openHAB nicht ansatzweise ausgelastet. Und inzwischen sollten die Lieferengpässe auch langsam zurückgehen - ich habe sogar meinen Pi Zero W bekommen, fast zu dem Preis, den er eigentlich kostet, und das schon vor Monaten...