openhabforum.de

vielen dank für die tollen informationen @udo1toni! nur hört sich das für mich auch nach mehrmaligem durchlesen ziemlich komplex an genau darum bin ich bis heute beim dd geblieben. dauert zwar lange dafür total simpel in der bedienung und auch das zurücksichern völlig easy.

aber da ich als laie mich immer über tips von profis freue und die sachen gern ordentlich mache würde ich das gerne probieren so umzustellen.

hab ich das richtig verstanden: für das "grundsystem" muß ich auf jeden fall die partitionen klonen, die dateien in den einzelnen ordnern werden dann zusätzlich in kürzeren abständen über rsync gesichert? ich sichere aktuell mit dd auf mein qnap-nas, da hab ich einen rsync-server dabei, rsnapshot leider nicht. aber das wäre eh der zweite schritt. kann ich tatsächlich meine bestehende partition (mit openhabian) nachträglich noch auf mehrere partitionen aufteilen? und mit welchem programm sichere ich die dann die partitionen so dass sie bei der wiederherstellung auch wieder booten?

besten dank!

Umpartitionieren geht am komfortabelsten natürlich über eine grafische Oberfläche mit gparted.
Aus dem laufenden System heraus ist es im Übrigen nicht in einem Schritt zu erledigen, da die laufende Systempartition nicht verkleinert werden kann. gparted lagt zu dem Zweck ein Script an, bootet das System temporär in eine andere Umgebung, verkleinert die Partition und rebootet (wenn ich ich es richtig im Kopf habe).
Einfacher ist es, die Platte an ein laufendes System zu hängen und dann von dort umzupartitionieren. Das geht mit dem Raspberry, indem man eine SD-Karte mit dem Standard Raspberry Pi OS bootet (in die grafische Oberfläche), dann die SSD anschließt und anschließend gparted aufruft. Die SSD auswählen und die bestehende 2. Partition verkleinern sollte kein Problem darstellen. Je nach Belieben kannst Du nun eine weitere Partition anlegen, auf die Du dann auch direkt die Daten eines Teils des Systems verschieben kannst. Wie weit man das Aufteilen der Partitionen treibt, bleibt einem selbst überlassen, es muss also gar nicht das ganz große Besteck sein.
Anschließend muss man noch die Datei /etc/fstab anpassen, damit die ausgelagerten Daten beim Booten an die richtige Stelle gemountet werden. Die Datei muss natürlich die von der SSD sein , d.h., Du musst dazu die 2. Partition einhängen (die 1. Partition ist /boot).

Man kann das Umpartitionieren auch ohne gparted machen. Ich gebe aber gerne zu, dass ein Anfänger (oder auch jemand, der sich noch nicht intensiv mit GNU/Linux beschäftigt hat) sich da leicht überfordert fühlen kann. Mit gparted von einem anderen System aus (Pi OS von SD-Karte) sollte es aber keine große Herausforderung sein.

rsnapshot sollte auf dem qnap auch leicht einzurichten sein. Schau mal z.B. hier: https://www.onesystems.ch/blog/rsnapsho ... tallieren/ da wird das erklärt (war jetzt nur auf die Schnelle recherchiert, kann sein, dass es noch andere mögliche Quellen gibt).

bastler hat geschrieben: ↑15. Okt 2021 11:56 das timestamp hab ich im netz gefunden,

Hallo Stefan,
Ich habe auch nach dem "timestamp" gegoogelt und das hier gefunden. Es handelt sich hierbei wohl um eine Funktion innerhalb von Bash, mit der man, in diesem Falle einen Zeitwert zurück geben kann. Also wieder was dazu gelernt.

Das mit dem "pishrink-Script" hab ich jetzt auch verstanden. Das gibt es wohl "fertig" im Internet.

Danke erstmal und Gruss - Peter

udo1toni hat geschrieben: ↑15. Okt 2021 15:10 Es gäbe da im Ablauf ein paar Optimierungsmöglichkeiten. Allerdings gäbe es zuerst die Frage, warum alle Welt immer auf Imaging setzt.

Hallo Udo,
Danke das du dich auch dazu gesellt hast. Aber wie Stefan bereits erwähnte, das ist ziemlicher "Stoff". Das muss man (ich) erst mal verdauen (verstehen).
Das mit dem Image war für mich bisher als "Gelegenheits-openHAB'ler" und "Linux-Noob" die einfachste Möglichkeit eine Sicherung der SD-Karte per "Win32Imager" zu machen.
Jetzt habe ich aber eine alte USB-Platte (3 1/2" 1 TB) mit einem OH3-Image lauffähig gemacht, influx und Grafana zu installieren(openhabian-config), eine weitere Partition zu erstellen und dort "influxDB"-Daten zu schreiben, usw. Und es werden auch tatsächlich Daten in die Datenbank geschrieben, obwohl ich noch gar nicht richtig weiss, was man damit machen kann und wie man die auswertet .

Auf jeden Fall stellt sich die Frage der Sicherung hier dann etwas anders .

So sieht meine SD-Karte aus: und so die Terra-Byte-Platte: Aber jetzt werde ich mich wieder auf den "Hosenboden setzen" um deine und Stefan's Tipps und Infos zu verinnerlichen und für mich selbst zu nutzen.

Danke erst mal euch beiden.

Gruss - Peter

P.S.: Ich weiss zwar, dass die 1TB-Platte ein "Riesen-Ding" ist, aber ich hab noch mal zwei so alte Platten hier ausgemustert rumliegen und einen RasPi b+ hatte ich auch noch, da hab ich halt meinem Spieltrieb freien Lauf gelassen

An der 1 TByte Platte kann man aber ganz gut erklären, warum Images irgendwann nicht mehr praktikabel sind.

Das Vollbackup ist ja auch nur bedingt hilfreich. Wobei mit pishrink tatsächlich schon mal das größte Problem aus dem Weg geräumt ist, nämlich, dass man so ein Image praktisch nie auf eine Karte gleicher Größe auspacken kann (weil sich die Karten bei nominal gleicher Größe eben dennoch minimal unterscheiden. Man müsste die Karten dann vorher nach echter Größe sortieren...)

Aber wie oben beschrieben, ist es eigentlich kein Problem, die eine große Partition in mehrere kleine Partitionen zu zerlegen und die Teile über Mountpoints virtuell zu einer großen Partition zusammenzufügen. Gewöhnlich wird man halt keinen Mountpoint /mnt/sda3 anlegen, den kann man nur als Datenhalde verwenden - allenfalls könnte man über symbolische Links Verzeichnisinhalte "umbiegen".
/mnt/ ist eigentlich nur dazu gedacht, temporär ein einzelnes Device einzubinden, nicht regulär, um ein Device fest einzubinden. Machen kann man das natürlich. aber normalerweise erzeugt man für das Device ein Unterverzeichnis in /media/

Da ein Vollbackup einer TByte-Platte nicht sinnvoll ist (also zumindest mit dem Raspberry...) ist es da dann unumgänglich, rein die Daten zu sichern, was mit rsync echt einfach ist. Notfalls kann man auch selbst ein Script schreiben (das macht aber Arbeit...) wenn man rsnapshot nicht laufen lassen kann oder will.
Der große Vorteil von rsnapshot ist natürlich, dass man sich nicht mehr drum kümmern muss. Ein manuelles Backup ist lästig, man macht es grundsätzlich zu selten und nach Murphys Law wird das Rückspielen gerade des letzten Backups sicher versagen.
Die über rsync erstellten Backups der wichtigen Daten lassen sich jederzeit leicht überprüfen, sind allzeit aktuell und man kann sie einfach in ein neues System einpflanzen, in dem man nur vorher alle Abhängigkeiten installiert hat.

Noch eine Sache: So ein Image ist zwar schön, aber wenn man im System ein Problem hat, welches im Image vorhanden ist, nutzt einem das Image auch nichts mehr, denn der Fehler wird auch im Backup vorhanden sein. Das Image hilft nur beim Ausfall der SD-Karte. Schon wenn man aus Versehen eine einzelne Datei gelöscht hat und diese wiederherstellen will, macht das mit einem Image keinen Spaß - man muss entweder das Image auf eine SD-Karte entpacken, oder man muss es über loop lesbar einhängen, was dann langsamer ist als nötig.

entschuldigung für die späte rückmeldung, waren das wochenende unterwegs.

besten dank für die vielen interessanten tips und infos, ich möchte gerne probieren mein backup system zu veressern, werd ich aber nicht so schnell realisiert bekommen weil mir da zu viel background wissen (linux) fehlt. zum glück gibts ja das openhab-cli backup - damit hab ich zumindest das wichtigeste (things, items, rules...) wenigstens manuell gesichert. ev versuch ich mal parallel mit einer neuen platte ein neues system so aufzusetzen mit mehreren partitionen und dann dort meine daten aus dem openhab-cli backup zurückzusichern.

bastler hat geschrieben: ↑18. Okt 2021 09:44 besten dank für die vielen interessanten tips und infos

..das Gleiche gilt für mich. Vielen Dank, dir und Udo, für eure Tipps. Da hab ich jetzt, wenn die Tage kürzer werden, mehr Zeit um die Infos zu verinnerlichen und damit zu spielen. Da komm ich dann bestimmt nochmal auf euch zu.

Immer gerne!

Und wie so oft, gilt auch hier: das beschriebene erhebt keinen Anspruch auf Vollständigkeit. Man kann es aber als Anreiz verstehen, sich mal näher mit den verschiedenen Aspekten zu beschäftigen um evtl. anschließend zu einer anderen Lösung zu kommen (oder auch beim bestehenden System zu bleiben, dann aber aus wohlüberlegten Gründen. )

Hallo,
ich oute mich auch als Freund von dd

Amanda hab ich mir auch angeschaut, aber noch nicht versucht - klingt "komplex" und mir ist unklar, was es alles wie/wo macht ...
Bei dd weiß ich es !

Kurze Frage zu diesem Teil von deinem Script:
> dd if=/dev/sda of=/mnt/smb/$(timestamp)/USB-SSD-$(timestamp).img bs=1MB

Du stoppst Openhab, aber das Raspbian läuft ja auf dieser zu sichernden Platte (auf /dev/sda2 wohl) weiter und hat Dateien geöffnet usw. ....
Ist dieser dd denn konsistent?

Bislang stecke ich meine USB-SSD Festplatte ab, stecke sie an einen anderen Linux Rechner und sichere da mit dd meine zwei Partitionen (/dev/sdb1, /dev/sdb2). Damit ist ja sichergestellt, das dieses dump konsistent ist, denn diese Partition ist ja nicht im Benutzung.

(mit #gparted hab ich meine /dev/sdb2 auf 10GB verkleinert, die Sicherung dauert keine 10 Minuten)

Genau... Das dd ist nur dann konsistent, wenn das System readOnly betrieben wird (das ist ja kein Problem mit ZRAM)