openhabforum.de

Hallo in die Runde!

Ich habe eine endlich funktionierende OH3 Neuinstallation durchgeführt, auf der Basis Raspberry4 mit SD Karte... Nun habe ich in der Zwischenzeit einige Artikel gelesen, dass die SD Karten mit der Zeit Probleme machen, insbesonders wenn man intensiv die Persistenz nutzt um Daten z.B. über Grafana zu visualisieren...
Daher habe ich mich entschieden auf eine SSD umzusteigen, da diese angeblich wesentlich besser mit den schreib-zyklen umgehen kann und die Dinger ja auch mittlerweile fast nix mehr kosten.

Nun wollte ich mal fragen, ob jemand damit schon mal Erfahrungen gemacht hat, eine bestehende Installation auf ein anderes Bootmedium zu übertragen?

Nach meiner Recherche gibt es zwei Möglichkeiten

1) Backup: OH3 Backup von SD, Neusintallation von Openhab auf der SSD und anschliessender Import
2) Klonen: SD karte klonen, SSD PartUUID ändern, boot definition auf SD Karte ändern, root location auf SSD ändern und dann die Partition auf der SSD anpassen/vergrößern

Habt ihr da Erfahrungen/Empfehlungen?

Herzlichen Dank!

hallo,
ist schon ne weile her, da hatte ich openhabian in meinem rpi4 auf sd karte. meine backups mache ich schon immer mit dem linux-befehl "dd". gefällt mir deshalb gut weil wenn die sd karte aus irgend einem grund nicht mehr funktioniert kann ich das gesicherte image mit etcher einfach auf sd zurücksichern und das system läuft wieder.
da ich auch über die probleme bei sd-karten gelesen hatte hab ich dann irgendwann einfach mal so ein backup nicht auf sd sondern auf ssd zurückgesichert, die ssd mit einem billigen usb-sata-adapter an den rpi angesteckt, sd karte raus, eingeschaltet - und funktioniert. seit dem läuft bei mir ne ssd am usb-port. mit der mach ich übrigens auch das backup über den dd-befehl. nur lass ich danach noch pishrink drüber weil die ssd hat 120gb, das hätte das backup sonst auch.
mir hat an dieser lösung gefallen dass sie total ohne risiko ist (zumindest scheint mir das so). wenn das mit der ssd nicht geklappt hätte könnte ich ja einfach die sd wieder reinstecken. hatte die drum auch noch ne weile zur sicherheit aufgehoben.

Hi "bastler" vielen Dank!

Ich habe das jetzt einfach mal probiert und meine SD mit der Openhab Installation per ApplePI-Baker auf die SSD geklont. Dann hab ich eine andere SD in Raspberry mit einer Standard-Buster-Installation + .SSH von der ich gebootet habe. Dann bin ich per

Code: Alles auswählen

sudo raspi-config

in das Config-Programm in "Advanced Options" (6) gegangen, dann - E1 Latest - Use the latest version boot ROM software, auf ok (nicht zurücksetzen) und dann wieder unter "Advanced Options", auf "Boot Order", dann einfach (1) "Boot USB auswählen... und schon hat das Teil von der SSD gebootet mit der geklonten OH3 Installation und alles hat funktioniert!

#

Die ursprüngliche SD hab ich in den Tresor und das mit deinem "dd" backup werde ich auch noch mal testen!

ui, du hast das viel aufwändiger gemacht als ich

ich hab die sd karte aus dem raspi entfernt und nur die ssd angesteckt, und dann hat er direkt von usb gebootet. ich hab also an der sd gar nichts geändert. wenn ich (den raspi runterfahre,) die usb-ssd wieder ausstecke und die sd wieder einstecke läuft er wieder damit.
aber wie auch immer, ist doch cool wenns läuft

Hättest du mal früher geschrieben!

So schlimm war es gar nicht... Deins hört sich aber wirklich eleganter an!

Danke nochmal!

Ich lese gerade aufmerksam euren Gedankenaustausch.
Ich habe gerade meine OH3-Test-System (RasPi 3b+) "getuned" und die SD-Karte auf eine alte 3 1/2" USB-Platte umgezogen. Das hat soweit ganz gut geklappt, auch wenn ich von der ganzen Geschichte wenig Ahnung habe. Und auch die Installation von "influxDB + Grafana" mit "openhabian-config" hat funktioniert.

Was mich interessieren würde, wäre wie du mit dem Befehl "dd" arbeitest und ob da noch eine weitere SSD-Platte mit im Spiel ist um die geklonten Daten zu empfangen. bzw. wie der Backup-Vorgang bei dir abläuft.

hallo,

ich hab mir da ne kleine datei gebastelt, die liegt im homeordner vom user openhabian. ich hab keine automatik für das backup, gehe mit putty per ssh auf den raspberry und rufe die datei dann manuell mit "./dasi" auf. muss dann noch das sudo password eingeben und damit sichert er einmal das komplette image (früher der sd karte, jetzt das der ssd) auf meinen nas-server. schade dass mit dd immer erst mal die kompleet größe gesichert wird, ich hab ne 120gb ssd drin. das image ist also erst mal 120gb, wird aber ja direkt dann geshrinkt und hat danach noch ca 12gb.

der grund warum ich das so gemacht hab ist dass ich mit amanda nicht zurecht gekommen bin, hab das nie zum laufen gebracht. vor allem nicht so einfach wie hier: wenn aus irgend einem grund das system zerschossen ist sichere ich einfach mit etcher das image vom nas auf eine ssd zurück und schon läuft alles wieder.

sei noch erwähnt dass das nicht zur sicherung der täglichen änderungen taugt weil der vorgang ja doch lange dauert. das mach ich indem ich vor ich anfange was zu ändern den kompletten openhab-conf ordner über den windows-explorer als zip wegsichere. dadurch hab ich auch ältere stände noch aufgehoben falls ich nochmal was nachsehen will.

zur info, so sieht meine sicherungsdatei aus:

Code: Alles auswählen

#!/bin/bash
#!/usr/bin/env bash

# timestamp funktioniert nur wenn er vor sudo -s gesetzt wird!
timestamp() { date +"%Y-%m-%d"; }

sudo -s <<EOF

echo "################################"
echo "### datensicherung gestartet ###"
echo "### (dauert gute 80 minuten) ###"
echo "################################"

#sudo systemctl stop openhab2.service

echo "backup laufwerk anschließen ..."
mount -t cifs -o user=my_username,password=my_password,rw,file_mode=0777,dir_mode=0777 //my_nas_ip/my_nas_share /mnt/smb/

echo "ordner für sicherung erstellen ..."
mkdir /mnt/smb/$(timestamp)
mkdir /mnt/smb/$(timestamp)/influxdb-dasi

#echo "komplette sd-karte in voller größe sichern..."
#dd if=/dev/mmcblk0 of=/mnt/smb/$(timestamp)/SD-Karte-$(timestamp).img bs=1MB
#echo "und jetzt das image komprimieren ..."
#pishrink.sh /mnt/smb/$(timestamp)/SD-Karte-$(timestamp).img

echo "komplette usb-ssd-festplatte in voller größe sichern ..."
dd if=/dev/sda of=/mnt/smb/$(timestamp)/USB-SSD-$(timestamp).img bs=1MB
echo "und jetzt das image komprimieren ..."
pishrink.sh /mnt/smb/$(timestamp)/USB-SSD-$(timestamp).img

echo "openhab-backups sichern ..."
openhab-cli backup
find /var/lib/openhab/backups -cmin -33 -exec cp {} /mnt/smb/$(timestamp) \;

echo "influxdb datenbanken sichern ..."
influxd backup -portable /mnt/smb/$(timestamp)/influxdb-dasi

echo "diverse konfigurationsdateien sichern ..."
cp /etc/hosts /mnt/smb/$(timestamp)
cp /etc/dhcpcd.conf /mnt/smb/$(timestamp)
cp /etc/owfs.conf /mnt/smb/$(timestamp)
cp /etc/samba/smb.conf /mnt/smb/$(timestamp)
cp /etc/influxdb/influxdb.conf /mnt/smb/$(timestamp)
cp /etc/grafana/grafana.ini /mnt/smb/$(date +%Y-%m-%d)

echo "###############################################################"
echo "### grafana dashboards bitte manuell als *.json exportieren ###"
echo "###############################################################"

umount /mnt/smb
EOF

Hallo @bastler,
erstmal vielen Dank für deine Rückantwort.

Ich habe das Script mal schnell überflogen und gleich ein paar "Fragezeichen

" gesehen. Das muss ich mir mal genauer anschauen und komme dann bestimmt noch mit ein paar Fragen um die Ecke.
Eine Frage gleich!!! Das Shell-Script "pishrink.sh" ist das ein Standard, den es im Netz gibt oder ist das was von dir und was ist "timestamp() { date +"%Y-%m-%d"; }"?

Grüssle aus dem Schwabenland - Peter

oh auch ein schwabe, ich auch

das pishrink hab ich mir so installiert:

Code: Alles auswählen

sudo wget https://raw.githubusercontent.com/Drewsif/PiShrink/master/pishrink.sh -P /usr/bin
sudo chmod +x /usr/bin/pishrink.sh

das timestamp hab ich im netz gefunden, damit wird der ordner der auf meinem sicherungs-nas erstellt wird nach dem datum benannt. ganz praktisch weil so sind die sicherungen ordentlich nach datum "sortiert"

grüße stefan

Es gäbe da im Ablauf ein paar Optimierungsmöglichkeiten. Allerdings gäbe es zuerst die Frage, warum alle Welt immer auf Imaging setzt.

Mein Vorschlag zur Optimierung wäre ein hybrides Verfahren.
Punkt 1: Aufteilung der SSD in mehrere kleinere Partitionen (das ist unter GNU/Linux sehr üblich, eine überschaubar kleine / Partition, eine weitere Partition, die unter /var eingebunden wird, eine für /tmp, eine für /boot, eine für /home. Man kann die Aufteilung auch beliebig anders gestalten.
Typisch wäre aber, die / Partition ca. 8 GByte groß zu machen, /var vielleicht auch noch mal 8 GByte, /boot vielleicht nur 500 MByte usw.

Nun kann man die einzelnen Partitionen in kürzerer Zeit klonen. Eingehängte Partitionen werden dabei nicht mit geklont, denn sie sind ja nicht Bestandteil der Partition.
Sinnvoll ist das Klonen vor allem für /boot, / und /var. /tmp kann man getrost weg lassen. /home könnte man auch über klonen sichern, einfacher wäre es aber, die entsprechenden Verzeichnisse mit rsync bzw. mit rsnapshot zu sichern.
Man richtet auf jedem Rechner, von dem Backups gezogen werden sollen rsync ein. Auf dem Rechner, der die Backups speichern soll, richtet man zusätzlich zu rsync noch rsapshot ein. Dort hinterlegt man auch die Informationen, welche Verzeichnisse auf den jeweiligen Systemen gesichert werden sollen.
Der Sicherungsvorgang wird dann z.B. viertelstündlich, stündlich, täglich, wöchentlich und monatlich ausgeführt. Beim Backup werden aber nur die Dateien übertragen, welche sich seit dem letzten Backup geändert haben. Initial dauert ein solches Backup also z.B. bei 8 GByte und 8 MByte/s etwa 20 Minuten, anschließend aber, bei typischerweise Änderungen von wenigen KByte auch nur wenige Sekunden.

Auf dem Backup Server gibt es dann pro System ein Verzeichnis, in dem Verzeichnis pro Snapshot ein weiteres Verzeichnis, und in jedem dieser Verzeichnisse ein vollständiges Backup des Zeitpunkts. Dabei nehmen aber nur die Dateien "zusätzlich" Platz weg, die sich geändert haben (das geht mit Hardlinks extrem elegant).
Als Lohn der Arbeit hat man also vollständige Backups für die z letzten Viertelstunden, für die y letzten Stunden, die x letzten Tage, die w letzten Wochen und die v letzten Monate. Man kann also notfalls sehr alte Stände von Dateien wiederherstellen, ist aber auch bei mehreren Änderungen in kurzer Zeit noch in der Lage, Zwischenstände zu nutzen. Und das mit minimalem Platzbedarf.

Da der Backup Server die Daten im Pull-Verfahren zieht, ist diese Vorgehensweise sogar hilfreich bei Verschlüsselungstrojanern (vorausgesetzt, das Backupsystem ist nicht selbst kompromittiert).

Die Sicherung mit rsnapshot bietet sich dann durchaus auch für ganz bestimmte Verzeichnisse auf den Partitionen an, die man komplett klont, also z.B. /etc/openhab/ oder /var/lib/openhab/.
So kann man dann die entsprechenden Partitionen in längeren Abständen klonen und in erträglicher Zeit dennoch zum aktuellen Stand zurück kommen.

Ein kompletter Restore läuft dann so ab, dass man die letzten Partitionen über den konventionellen Weg zurück spielt und anschließend einmal die Dateien aus den Snapshots über die vorhandenen Dateien (gerne mit der Option, nur ältere Dateien zu überschreiben, womit die Übertragung nochmals kürzer läuft)

Imaging mit großen Partitionen ist in den seltensten Fällen wirklich sinnvoll

Ach so... Es ist natürlich wichtig, da hier nur Teile der Platte geklont werden, die Partitionsliste ebenfalls zu sichern. Die muss dann bei neuen Platten zuerst aufgepielt werden (oder man muss alternativ manuell eine Partitionsliste erstellen, in der jede der Partitionen mindestens so groß ist, wie die Quellpartitionen.

openhabforum.de

Openhab3 von SD auf SSD?

Openhab3 von SD auf SSD?

Re: Openhab3 von SD auf SSD?

Re: Openhab3 von SD auf SSD?

Re: Openhab3 von SD auf SSD?

Re: Openhab3 von SD auf SSD?

Re: Openhab3 von SD auf SSD?

Re: Openhab3 von SD auf SSD?

Re: Openhab3 von SD auf SSD?

Re: Openhab3 von SD auf SSD?

Re: Openhab3 von SD auf SSD?