int5749 hat geschrieben: ↑15. Mär 2023 20:47
Benötigt es unbedingt ZFS oder kann ich die Verzeichnisse auch so auf ein anderes System mappen?
Grundsätzlich geht das mappen auch, wenn Du kein ZFS einsetzt. ZFS bringt halt ein paar Vorteile, die mit anderen Dateisystemen nicht zur Verfügung stehen. Beispiel Snapshot: Grundsätzlich geht das auch mit LVM (Logical Volume Manager), aber hier handelt es sich nicht um ein Dateisystem. In der Folge muss LVM echten Platz für den Snapshot zur Verfügung stellen. In ZFS ist es so, dass ein Snapshot lediglich einen Vektor aufbaut. Es bleiben einfach alle Dateien erhalten, es werden lediglich Änderungen an einen anderen Ort geschrieben. Will man zu einer früheren Version einer Datei zurück, so verfolgt man die Vektorkette der Änderungen. Man kann einzelne Snapshots herauslösen und auch löschen, ohne dass die Vektorkette bricht.
In LVM erzeuge ich einen (relativ kleinen) Snapshot, dabei passiert erst mal nichts. Sobald nun Schreibzugriffe stattfinden, werden diese in den Snapshot geschrieben. Ich kann also mit dem Snapshot eine bestehende Partition "einfrieren", um diese zu sichern. Anschließend wird der Snapshot gelöscht, womit die zwischenzeitlich geschriebenen Daten in die bestehende Partition hineingebaut werden. Das Vorgehen ist auf den ersten Blick recht ähnlich, aber in ZFS kann ich ohne Probleme hunderte oder gar tausende Snapshots eines einzelnen Datasets verwalten (natürlich wird das Dateisystem irgendwann langsam), weshalb überhaupt kein Problem ist, zyklisch Snapshots zu erstellen. Und jeder Snapshot ist ein möglicher Punkt, um dorthin zurückzukehren.
Update des OS ist schief gegangen? Sch..ß drauf, Nachschauen, wann das Update ausgeführt wurde, Container anhalten, zfs rollback -r <snapshot kurz vor dem Zeitpunkt> Container starten, Bääm, System läuft wieder (natürlich ohne das Update...).
Und der Vorgang dauert (systemabhängig) nur wenige Sekunden.
Nächtliches Backup aller Änderungen? Auf dem Zielsystem befindet sich ein Snapshot, der auch auf dem Quellsystem vorhanden ist. zfs weiß um die beiden Snapshots und muss nur die Vektorkette zum aktuellen Zustand übertragen. Dabei spielt es keine Rolle, ob zwischenzeitlich andere Snapshots dieses Datasets erstellt oder auch wieder gelöscht wurden.
Man muss natürlich Platz für die Snapshots einplanen. Außerdem mag ZFS es gar nicht, wenn das Dateisystem zu mehr als 80 % gefüllt ist. Das heißt, wenn Du eine 2,5 TByte Platte hast, dürfen dort nur insgesamt 2 TByte Daten drauf, mitsamt der Änderungen, die durch Snapshots gesichert vorliegen. Hast Du insgesamt 50 TByte Platz, darfst Du davon nur 40 TByte füllen, usw. 20 % "ungenutzter" Platz ist ein Haufen Zeug, vor allem, wenn man den Platz eigentlich bräuchte, Aber dafür hat man halt auch ein wirklich robustes System.
Da ZFS stark mit Caching arbeitet, sollte man pro TByte Plattenplatz etwa 1GByte RAM reservieren, auch das ist eine Kröte, die unangenehm im Hals steckt (vor allem, wenn es dann doch um "etwas mehr" Platz geht...) Dennoch ist es für mich aus meiner Konfiguration nicht mehr wegzudenken, auch vor dem Hintergrund, dass ich eine Zeit lang massive Probleme mit Aussetzern auf einzelnen Laufwerken hatte (Wackelkontakt im Laufwerkskäfig, hat ewig gedauert, das zu finden), und ich hatte keinerlei Datenverlust, weil ZFS das einfach weggesteckt hat.
openHAB4.3.3 stable in einem Debian-Container (bookworm) (Proxmox 8.3.5, LXC), mit openHABian eingerichtet
openHABain ist dafür optimiert, auf einem Raspberry zu laufen, entsprechend sind etliche der Funktionen auch nur dort sinnvoll.
