Ich habe mich entschlossen, mein Haus mit dem Raspberry zu automatisieren. Nun bin ich ab und zu auf Dienstreise und nach Murphy fällt genau dann etwas aus. Gut wenn man Vorsorge getroffen hat und die liebe Ehefrau das ganz allein wieder inbringt, nur aufgrund eines Telefongesprächs.
Mein Ansatz:
Irgendwann hat man ja mal alle Linux-Programme installiert und alle weiteren Änderungen liegen dann in /opt/fhem. Zu diesem Zeitpunkt kann man ein Image der SD erstellen und auf eine 2.SD bringen, die griffbereit neben dem Raspberry liegt.
Fällt nun die SD aus, kann man einfach den kleinen USB-Stromversorgungsstecker ziehen, die SD tauschen und wieder einstecken.
Vermutlich hat man aber in FHEM inzwischen etwas geändert. Also sollte per at regelmäßig gesichert werden - bei mir auf einen USB-Stick am Raspberry - und bei Power-on sollte dann /opt/fhem aktualisiert werden.
Im schlimmsten Fall tauscht man halt den ganzen Raspberry mit schon richtiger SD und steckt alles vom alten auf den neuen um, einschließlich des USB-Sticks.
Die Theorie hat meine liebe Ehefrau sofort begriffen, nun muss ich es umsetzen.
Image von SD habe ich erfolgreich gemacht:
SD vom Raspberry in einen USB-Adapter und an den Linux-PC angeschlossen
mit
blkid die SD identifiziert, bei mir sdb
/dev/sdb1: LABEL="RECOVERY" UUID="D2D0-A9DC" TYPE="vfat"
/dev/sdb3: LABEL="SETTINGS" UUID="b2953f0a-dee7-452e-9443-85c034c463dc" TYPE="ext4"
/dev/sdb5: LABEL="BOOT" UUID="012D-34EC" TYPE="vfat"
/dev/sdb6: LABEL="root" UUID="80ac98e0-4a37-4154-8ccb-c6961c314f5e" TYPE="ext4" mit
sudo dd if=/dev/sdb of=/home/user/MyImagesudo dd if=/home/user/MyImage of=/dev/sdbeine leere SD beschrieben
Der Raspberry läuft mit beiden einwandfrei.
Wenn ich mit über ssh auf dem Raspberry einlogge, dann kann ich ohne sudo(!) das Kommando
rsync -av /opt/fhem /media/usb/syncabsetzen und bekomme dort den aktuellen Inhalt. Wenn ich etwas ändere und das Kommando nochmals absetze, dann klappt das auch. Wenn ich aber aus FHEM heraus
{system("rsync -av /opt/fhem /media/usb/sync")} absetze, dann funktioniert das leider NICHT.
Hat jemand eine Idee, woran das liegt?
Weiterhin möchte ich beim shutdown von fhem ebenfalls sichern und beim start von fhem die Sicherung zurückspielen. Kann mir jemand einen Tipp geben wie ich das in das in die Befehle
sudo /etc/init.d/fhem start
sudo /etc/init.d/fhem stopeinbauen muss?
Hallo ujaudio,
das der rsync Befehl unter FHEM nicht klappt, kann daran liegen, dass FHEM als User fhem läuft und dann möglicherweise keine Zugriffsrechte auf das sync Verzeichnis hat. Beim "normalen" Anmelden an den PI bist du als User pi unterwegs und hast wahrscheinlich auch FHEM als solcher installiert. In diesem Fall könnte es helfen, fhem in die Gruppe pi aufzunehmen. Allerdings entsteht dadurch auch ein Sicherheitsproblem, da so die gesamte FHEM-Installation bei einem Angriff von außen manipuliert werden kann. Generell ist es problematisch Backup/Restore-Abläufe einer Anwendung über die Anwendung selbst abzuwickeln.
Ein besserer Ansatz ist das Runlevel-Script. Wenn du ein bisschen Shell-Programmierung nicht scheust, kann Du den rsync vor dem Start und nach dem Stop in das Skript /etc/init.d/fhem einbauen. Das ist auch nur eine Textdatei, die du mit einem Texteditor deiner Wahl bearbeiten kannst. Solange du den Befehl nicht von Bedingungen abhängig machen willst, musst du ihn nur an der richtigen Stelle einfügen. Orientiere dich an den Strings im Skript ('start', 'stop' und echo ...), dann findest du schnell die geeigneten Stellen. Ein Abschnitt in einer case-Anweisung beginnt mit dem Schlüsselwort (z.B. 'start') und geht bis zum nächsten Doppel-Semikolon. Zeilen die mit # anfangen sind nur Kommentare.
jensb
Danke Jensb,
das rsync Kommando werde ich mal in das start/stop einbauen. Dann müsste ich regelmäßig FHEM einen Restart machen lassen. Für das reine Backup wollte ich das gerne vermeiden. Vielleicht muss ich mich doch nochmals mit dem "sudoer" befassen und FHEM gezielt das rsync zulassen.
Hallo ujaudio,
wenn du sudo verwenden willst, probier mal folgendes:
- als User pi "sudo visudo"
- in der letzen Zeile "fhem ALL= NOPASSWD:/usr/bin/rsync" einfügen
- mit "Strg+X Y" speichern
Damit sind die Ausnahmen für fhem auf rsync beschränkt und du kannst das Backup regelmäßog aus FHEM heraus aufrufen, ohne neu starten zu müssen.
jensb
Danke für den Hinweis, habe ich gemacht und rsync funktioniert.
Die oben erwähnten
sudo /etc/init.d/fhem start
sudo /etc/init.d/fhem stop
werden aber beim FHEM-Befehl "shutdown restart" nicht ausgeführt, sondern nur bei Poweroff/on.
Wie kann ich das lösen?
Hallo ujaudio,
beim Shutdown gibt es ein global notify, an das man sich dran hängen kann:
DoTrigger("global", "SHUTDOWN", 1);
Ähnliches gilt für den Startup:
DoTrigger("global", "INITIALIZED", 1);
Versuchs etwa so:
define ShutdownHook notify global:SHUTDOWN ....
Habe das selbst so noch nicht gebraucht. Hoffentlich klappt es bei dir.
jensb
Hallo,
prima das funktioniert, aber wie kann ich so etwas selbst herausfinden? Google findet nicht sehr viel zum Thema Dotrigger. Und das was ich nun gefunden habe, bringt mich nicht auf die richtige Spur.
Hallo ujaudio,
es gibt u.a. die FHEM Wiki, die Commandref Dokumentation und - das ist das schöne an Open Source - den Quellcode. Ein HowTo für jedes Thema kann es leider nicht geben, aber dafür gibt es auch das Forum.
Wenn dich die Details hinter DoTrigger interessieren, schau in die Datei fhem.pl, dort wirst du die von mir erwähnten Trigger finden.
jensb
Ich geb's zu: den Quellcode habe ich mir noch nie angesehen.
Auf alle Fälle aber vielen Dank für deine Hinweise, die mir sehr geholfen haben.
Hallo ujaudio,
war mir eine Freude zu helfen. Viel Spaß bei deinen Experimenten,
jensb
So, ich habe nun alles soweit am Laufen, aber eine Unsicherheit bleibt noch: ich kann das rsync-Kommando auch ausführen während FHEM läuft - es scheint alles bestens. Beim Ausschalten habe ich die /etc/init.d/fhem wie folgt geändert:
'stop')
echo "Stopping fhem..."
rsync -av /opt/fhem /media/usb0/sync
perl fhem.pl $port "shutdown"
RETVAL=$?
Damit wird zuerst das Backup gemacht und anschließend FHEM gestoppt, somit können ein paar letzte Änderungen durch FHEM verloren gehen. Dies sind:
log/eventTypes.txt
log/fhem-2015-06.log
log/fhem.save
Das erscheint mir unkritisch, sauber wäre aber die Reihenfolge umzudrehen.
'stop')
echo "Stopping fhem..."
rsync -av /opt/fhem /media/usb0/sync
perl fhem.pl $port "shutdown"
RETVAL=$?
rsync -av /opt/fhem /media/usb0/sync
Wäre das so ok?
Hallo ujaudio,
ich verstehe nicht ganz, warum du das rsync beim Stop zweimal kurz hintereinander ausführen willst - wahrscheinlich hast du nur vergessen, den Aufruf vor dem Stop zu löschen.
Das rsync nach dem Shutdown von FHEM auszuführen, dürfte am besten sein, da dann im Normalfall alles konsistent ist.
Wichtig beim Backup ist meines Wissens nach vor allem die fhem.cfg und die fhem.save. Beide können mit save jederzeit von innerhalb FHEM gesichert werden. Letztere enthält den aktuellen Zustand der Readings und wird auch so gelegentlich aktualisert, zuletzt beim Shutdown. Wenn FHEM crasht, geht dann ein Teil des aktuellen Zustands verlohren. Ansonsten sollte man seine Messwertaufzeichnungen im log-Verzeichnis sichern. Die restliche Installation lässt sich aus dem Internet neu aufsetzten.
Mir ist es bei der Modul-Entwicklung schon einige Male passiert, dass FHEM die Konfiguration für ein fehlerhaftes Modul beim Starten aus der fhem.cfg gelöscht hat. Dann ist es gut, wenn man kurz vorher ein Backup gemacht hat. Ein Problem, das rsync allein nicht löst, ist eine Versionierung des Backups, gerade für die Konfigurationsdatei. Deshalb verwende ich bei bestimmten Dateien rsnapshot und bekomme so eine Änderungshistorie, die nach konfigurierbaren Regeln die alten Versionen irgendwann verwirft, damit nicht beliebig viel Platz benötigt wird.
jensb
Auf meinem Linux-Laptop verwende ich auch rsnapshot. Vielleicht werde ich es am Raspberry auch noch machen.
FHEM in allen Ehren, aber weshalb du FHEM über die INIT-Scripte wie ein Karusell hoch und runterfährst nur um eine Sicherung zu bekommen erschließt sich mir nicht. Warum nicht ein hundsordinärer Cronjob und alles ist gut?
Um ehrlich zu sein: weil ich einfach nicht weiß, wie es geht. Ich versuche Linux so peu à peu zu begreifen. Auf meinem Laptop habe ich kaum etwas damit zu tun: Ubuntu installiert, Anwendungen wie Email und Bürosoftware - fertig. Die Datensicherung habe ich mit Mühe über rsnapshot hinbekommen.
Aber ich fahre FHEM gar nicht dauernd rauf und runter: normal läuft es non-stop. Ich will 1x täglich ein Backup von /opt/fhem machen und gut ist es. Beim Start von FHEM soll dieses das neueste Backup nutzen: Annahme SD-Karte geht kaputt, ich nehem eine neue, auf der vor x Monaten ein FHEM installiert wurde, stecke diese und schalte den Rspberry ein - dann soll das Backup verwndet werden. So meine Überlegung.
Dass ich beim Ausschalten ein Backup anlege hat damit zu tun, dass ich momentan teste, ob alles so tut wie es soll - und da bin ich noch nicht am Ziel. Einiges funktioniert noch nicht, aber ich will nicht alle meine Linux-Probleme hier im FHEM-Forum vorbringen.
Ich kann nur lernen...
Ubuntu hat ein klasse Wiki: http://wiki.ubuntuusers.de/CRON :)
Ja, das nutze ich auch die ganze Zeit!
So einen Aufwand nur wegen einer möglicherweise defekten SD-Karte ist Unsinn.
Besser: Logging und Backup von der SD-Karte wegverlagern, dann hält sie (fast) ewig.
LG
pah
Also bei FHEM reicht es:
1. FHEM save aufrufen
z.B. mit:
echo -en "set ${1} ${2}\nquit\n" | $nc fhem.maxel.home 7072 >/dev/null
Wenn in FHEM für telnet kein Passwort, sonst müsste dieses mit übergeben werden
2. FHEM (opt/fhem) sichern
Da FHEM seine Dateien nicht "blockt", könntest Du über rsync (rsnapshot, dirvish o.Ä,) eine Kopie anfertigen
Und "fedisch is"
Hallo Forum, hallo pah
so ein kleiner Tip wäre schön, was man den dann am besten alles auf, z.B. eine SD- Festplatte, verlagern sollte?
und vor allem, wie man das auch Update sicher einrichtet.
Damit wäre einem Neuling schon unheimlich viel weiter geholfen :-)
Schöne Grüße
NewRasPi
Zitat von: Prof. Dr. Peter Henning am 17 Juni 2015, 06:09:21
So einen Aufwand nur wegen einer möglicherweise defekten SD-Karte ist Unsinn.
Besser: Logging und Backup von der SD-Karte wegverlagern, dann hält sie (fast) ewig.
LG
pah
Zitat von: ujaudio am 13 Juni 2015, 16:11:21
...wenn man Vorsorge getroffen hat und die liebe Ehefrau das ganz allein wieder inbringt...
Wenn Du ihr erklärt hast, wie sie dann aus dem Backup eine neue SD-Karte beschreibt, dann brauchst Du den ganzen Aufwand nicht.
Mach Dir nach der Grundeinrichtung und/oder wesentlichen Änderungen eine Kopie der SD-Karte als Reserve und sicher Dir ab und zu mal die Konfiguration (z.B. per cron-Job auf einen USB-Stick). Alles andere ist m.E. viel Aufwand für nix. Es sei denn, Du hast die passende Infrastruktur sowieso am Laufen.
Das meiste ist doch Panikmache...
Du kannst viel Glück oder total Pech haben, und dazwischen ist reichlich Spielraum.
sicher doch Deine Config in einer Datenbank ...
Pi defekt --> anderen Rechner nehmen und die Datenbank verbinden ...
selber schon gemacht und hat sofort funktioniert
die DB zu sichern ist dann auch kein Hexenwerk mehr
Unstrukturierte Datenbanktabellen .... na ja. Man kann auch den Suppenwürfel mit dem Tieflader holen.
Und für alle Neulinge:
- Verzeichnis für Fhem logs auf einer NAS/Fritzbox o.ä. mounten, Verzeichnis für sytemlogs auf einer Ramdisk.
LG
pah
Hallo zusammen,
Zitat von: Prof. Dr. Peter Henning am 17 Juni 2015, 22:31:33
Und für alle Neulinge:
- Verzeichnis für Fhem logs auf einer NAS/Fritzbox o.ä. mounten, Verzeichnis für sytemlogs auf einer Ramdisk.
-> siehe z.B. http://www.ideaheap.com/2013/07/stopping-sd-card-corruption-on-a-raspberry-pi/
Zitat von: Prof. Dr. Peter Henning am 17 Juni 2015, 06:09:21
So einen Aufwand nur wegen einer möglicherweise defekten SD-Karte ist Unsinn.
Besser: Logging und Backup von der SD-Karte wegverlagern, dann hält sie (fast) ewig.
IMHO stimmt das so einfach nicht: die SD-Karte kann doch immer noch kaputt gehen und dann ist man wieder "ewig" beschäftigt mit neu installieren/einrichten (bootstrap, IP einrichten, alle Packages installieren/aktualisieren, Perl-Pakete kompilieren, usw.)
Ein Full Backup & restore macht also durchaus Sinn...
mfg
micha
@micha: Noch einmal: Unsinn.
Zitatdie SD-Karte kann doch immer noch kaputt gehen
Soso. Und wovon, wenn auf sie nur in größeren Abständen geschrieben wird ?
Natürlich macht man von jeder seiner SD-Karten ein Backup. Indem die komplette Karte (bei mir einmal pro Halbjahr) mit dd als image auf einen Server geschrieben wird - das ist der schnellste Weg zur Wiederherstellung, und zwar ohne ein "restore". Sondern ebenfalls mit dd auf eine neue SD-Karte.
Natürlich macht man bei jeder Änderung des FHEM-Systems ein Backup der Konfigurationen. Aber nicht auf die SD-Karte, sondern auf eine NAS. Aber von dort gibt es bei mir kein automatisches "Restore" - das ist viel zu riskant. Sondern, wenn nötig, hole ich mir einzelne Teile davon zurück.
LG
pah
@pah:
- hast du deine SD-Karte read-only gemountet oder wie erreichst du, dass nur in größeren Abständen geschrieben wird?
(Falls du ein gutes Tutorial hast, poste es doch bitte)
- du machst also full-backup mit dd (und halbjährlicher Kalender-Erinnerung)
- restore manuell
- inkrementelles Backup mit rsync(snapshot), dirvirsh, "hand gestrickt"?
Hier mal mein 3 Zeiler, mit dem ich auf meinem Spielsystem sporadisch meine Konfig sichere:
#!/bin/sh
set -x
cd /opt/fhem
./fhem.pl 7072 "save"
BCK="restoreDir/$(date +%Y-%m-%d_%H-%M-%S)"
mkdir $BCK
cp -r log $BCK
cp fhem.cfg $BCK
cp FHEM/99_myUtils.pm $BCK
mfg
micha
Alle Logs gehen entweder auf die Ramdisk, oder auf die NAS. Nur Editieren von Konfigurationen oder Updates schreiben auf die SD-Karte.
Gutes Tutorial ? Erscheint im Herbst im Buch "Hacks für das SmartHome"... ;D
LG
pah
Ich habe mir die Sache noch etwas leichter gemacht, und das FHEM Verzeichnis einfach in meinen Dropbox-Ordner gepackt.
Würdest du das mit einer Backup-Karte machen die du passend konfiguriert hast, würde sich das System von selbst wieder auf den aktuellsten Stand bringen, sobald du sie tauschst.
Durch die Versionierung hast du auch mehr Sicherheit gegen Updates etc.
ZitatIch habe mir die Sache noch etwas leichter gemacht, und das FHEM Verzeichnis einfach in meinen Dropbox-Ordner gepackt.
Das ist kreativ :)
Von der Sache her nicht anders, als auf der Fritzbox. Aber problematisch - wenn die Internetverbindung ausfällt, macht FHEM was ?
LG
pah
Zitat von: Prof. Dr. Peter Henning am 19 Juni 2015, 10:54:51
Von der Sache her nicht anders, als auf der Fritzbox. Aber problematisch - wenn die Internetverbindung ausfällt, macht FHEM was ?
Keine Backups, bis die Verbindung wieder da ist.
Da ich FHEM auf einem Laptop laufen habe und mich daher nicht mit Ramdisks etc. rumschlagen muss, ist das auch kein Problem.
Und es ist nicht das gleiche wie mit einem NAS, da ich mir Dateien nicht in ihrer einzigen Ausführung kaputtschreiben kann und auch gleich noch eine automatische Versionierung jeder noch so kleinsten Änderung mit dabei habe.