Richtiges Backup und vor allem richtiges Restore

[Ajuba]

Hallo
Nach einigem Herumprobieren am PC habe ich nun meinen neuen Raspi als Produktivsystem installiert.
Bevor ich aber voll loslege beschäftigen mich am meisten die Themen

   
• Richtiges Installieren
• Richtiges Backup und vor allem richtiges Restore im Fall eines Problems.

Soweit ich es verstehe, kopiert Backup schlicht und einfach alle Dateien des Fhem Verzeichnisses. Heißt das, dass ich als Restore einfach auf die SD Karte wieder das Raspian Image drauf kopiere und dann noch das letzte Backup und alles läuft wieder? Oder passiert da bei den ganzen Repository Downloads gefolgt vom notwendigen Update so viel im Hintergrund, dass das zu einfach gedacht ist?
Wo steht, wie man Restore ganz richtig macht?


Ehrlich gesagt macht mir das Repository-Installationsverfahren auch in anderer Hinsicht Gedanken. Nennt mich jetzt bitte nicht gleich einen Ketzer aber was wäre wenn es in einigen Jahren den Fhem Server aus irgendeinem Grund nicht mehr geben würde. Das könnten finanzielle, technische, politische oder sonstige nicht vorhersehbare Gründe sein. Dann hätte ich gerne Offline eine lauffähige Installationsvariante mit allem was ich benötige inklusive aktuellem Fhem Stand und Frontend ohne der Notwendigkeit ein Update machen zu müssen. Also versteht mich nicht falsch, ich finde Fhem super, wünsche ihm ein langes "Leben" und danke allen Entwicklern. Aber wenn ich in Infrastruktur investiere und viel mehr Zeit zum Aufbau einsetze muss ich auch an die Zukunft mit allen Eventualitäten denken.
Also steinigt mich bitte nicht aufgrund meiner kritischen Frage.
Danke im voraus für konstruktive Antworten.

[viegener]

Ich denke zum Thema Backup / restore gibt es vermutlich genügend Informationen hier im Forum, deshalb lasse ich diese Frage mal zur Übung offen.

Zur Installation:
- Wenn Du mal im fhemwiki schaust wirst Du feststellen, dass FHEM auch auf anderen Plattformen (z.B.) Windows läuft.
- In der Installation für Windows ist erkennbar, dass FHEM eigentlich "nur" ein Perlskript und eine Verzeichnisstruktur ist, die sich manuell aus dem tar file installieren lässt. -> Voila, das geht so auch so ähnlich auf dem Raspberry (m.a.W. das debian package ist ein Komfortgewinn), damit ist dein Problem gelöst, denn es gibt eine offline Variante
- Warum sich diese Variante vom debian package, dass man auch offline speichern kann unterscheiden soll ist mir unklar
- Wie willst Du diese Frage denn für perl, Raspberries, Arduinos, AVR microcontroller, etc beantwortet bekommen

Ich verstehe Deine Bedenken also nicht und kann auch die Argumentation nicht nachvollziehen. Es gibt hier sehr viele die sehr viel Zeit in ihre Installation von FHEM hereingesteckt haben, die haben bestimmt alle diesen Punkt übersehen?

Achso und es gibt den fhem e.V.

[Ajuba]

OK, ich hatte schon befürchtet, dass die Frage trotz vorsichtiger Formulierungen kritisch ankommen könnte.
Ich habe halt für wirklich wichtige Dinge am liebsten eine Installations-CD in der Hand ohne Abhängikeiten vom Internet. Aber das ist hier wohl nicht so einfach möglich.
Nichts für ungut und bitte mich nicht gleich blacklisten wegen dieser Frage.

[Brice]

Installations-CD 

Das /opt-Verzeichnis kannst du automatisiert regelmäßig sichern. Dazu gibt es im Wiki Anleitungen. Ich sichere dazu regelmäßig die SD-Karte und schreibe diese ggfls. als Image zurück.

[abc2006]

kopiere dir /opt/fhem auf eine CD 

Dann solltest du soweit alle Dateien haben, die du benötigst.
Oder du speicherst dir das .deb-Paket. Das kannst du ebenfalls bei Bedarf installieren (ist aber nicht immer auf dem neuesten Stand).

Grüße

Stephan

[Brice]

Die Frage ist ok und auch nicht doof

Ich habe keine große Lust, meine Systeme im Falle eines Defekts der SD-Karte "from scratch" neu aufzusetzen. Gerade weil ich bei den verschiedenen FHEM Instanzen noch Sonderfälle habe, die aufgrund der Vielzahl von benötigten Perl Libraries nur unter erheblichen Zeitaufwand neu aufzusetzen sind (z.B. FHEM für Gäste-WC mit mpd/mpc als WiFi-Radio, GPIO-PIR-Bewegungsmelder, dazu die Überwachung der Techem Sachen). Oder die Integration der Jawbone Fitness Armbändern , da kämen schon einige Viertelstunden zusammen.

Für meinen Fall habe ich mir angewöhnt, die SD-Karten zu sichern und zurückzuspielen. Danach ein update/upgrade und ggfls. die letzte Sicherung von /opt/fhem einspielen.

Und alle wichtigen Änderungen/Erweiterungen der Systeme zu dokumentieren. Hat mir zumindest bisher ungemein geholfen.

[Wernieman]

Code Auswählen Erweitern

Und alle wichtigen Änderungen/Erweiterungen der Systeme zu dokumentieren.

Das dürfte das Wichtigste Backup sein!
Auch ein Dump der SD ist, gerade für Anfänger, eine super Möglichkeit des Backups! Bei einem HW Wechsel könnte es aber zu Problemen führen ....

Leider sollte aber ein Backup automatisch sein, da man es sonst vergisst. Automatisch die "/opt/fhem" wegzusichern ist eine optimale Möglichkeit.

@Brice:
Du brauchst kein FHEM Backup, sondern ein Systembackup .. bei der menge von zusätzliche "Produkten" ;o)

Nur bevor ich noch mehr über backup schreibe .... suche mal im Forum. Haben hierüber schon in mehr als einem Thread diskutiert!

Ergänzung:
FHEM bassiert auf perl. Das es kurzfristig perl mit seinen Paketen nicht mehr geben wird, glaube ich nicht. Es ist möglich, das z.B. das "dieses Internet" nicht mehr existiert, aber dann haben wir andere Probleme als die Funktionsfähigkeit von FHEM

[viegener]

OK, ich hatte schon befürchtet, dass die Frage trotz vorsichtiger Formulierungen kritisch ankommen könnte.
Ich habe halt für wirklich wichtige Dinge am liebsten eine Installations-CD in der Hand ohne Abhängikeiten vom Internet. Aber das ist hier wohl nicht so einfach möglich.
Nichts für ungut und bitte mich nicht gleich blacklisten wegen dieser Frage.

Nein, ich denke nicht an kritisch oder blacklisten aber ich finde die Assoziation einer "Installations-CD" mit einem im Netz geplegten Open-Source-produkt nicht klar. Trotzdem habe ich Dir beschieben, wie Du zu einer Offline-Installation kommen kannst und das war doch die ursprüngliche Intention

Backups halte ich für extrem viel wichtiger, sind aber auch nach meiner Sicht sehr gut dokumentiert für FHEM (und auch für das darunterliegende System). Die eingebaute Backupfunktion in FHEM halte ich für sehr simpel (und das meine ich im positiven Sinne) - Sie ist weitgehend vollständig, einfach zu automazisiern und mit wenigen Werkzeugen auch wiederherzustellen. Das ist aus meiner Sicht extreme Sicherheit - und die Dokumentation der Installationsänderungen, Erweiterung etc gehört am besten ins Backup

[Ajuba]

Danke mal für die vielen Antworten.
Ich werde jetzt mal mehrere Varianten durchspielen, damit ich sicher sein kann dass es funktioniert wenn ich es brauche.
Übrigens wirft die Forensuche für "backup restore" genau 127 Ergebnisse aus mit Problemen, die mich eher verunsichert hatten als beruhigt. Daher kam ja meine Frage, weil offensichtlich das Zurückspielen öfters Probleme machte.

Also ich verstehe das jetzt so.
Zum Sichern meines Fhem Projekts inklusive Web-Frontend nehme ich den "Backup" Befehl
Das Restore kann ich machen indem ich "/opt/fhem"vom Raspi  lösche und das entpackte Backup wieder drauf kopiere.
Es wird nämlich so oft das Wort Restore verwendet, ohne es zu erklären. Ich komme halt aus der Windows Welt und bin mir noch nicht ganz sicher wie ich das bei einem headless Raspi anpacke. Aber wenn dieses einfache Zurückkopieren mit Restore gemeint ist werde ich es schon irgendwie schaffen.

Bezüglich Image sichern bin ich im Forum auf "Win32DiskImager" bzw. "dd" gestoßen.
"Win32DiskImager" scheint klar zu sein, da ich die Raspi Installation damit gemacht habe.
"dd" habe ich bis jetzt noch nicht wirklich durchschaut.
Da scheint es teilweise Probleme mit der SD Karten/Image -größe geben aber wenn das Zurückspielen problemlos funktioniert sollte ja alles sofort wieder voll einsatzfähig sein (System inklusive Fhem Projekt).

Also dann, sobald ich Zeit habe probier ich mal rum.

[Brice]

Das Sichern kannst du automatisieren. Um es dir zu erleichtern

Code Auswählen Erweitern

define SYS_Backup dummy
attr SYS_Backup webCmd Ausführen
define SYS_BackupRun notify SYS_Backup:* backup
define BackupRun at *04:00:00 set SYS_Backup Ausführen

"Hübsch machen" kannst du selbst  Backupverzeichnis in global setzen. Hilfreich ist auch immer ein

Code Auswählen Erweitern

attr global backup_before_update 1

Für ein Restore ist kein Löschen von /opt/fhem notwendig, einfach das tar.gz drüberbügeln (oder korrigiert mich jemand?)

Dump der SD-Karte per dd kannst du automatisieren, wenn der Pi nicht gerade per WLan im Netz hängt. Kann je nach Größer der Karte länger dauern. Ich mache es nicht, sondern entnehme die Karte nach shutdown des RPi und dann per "Win32DiskImager" ein "read". Auf ein paar Minuten ohne FHEM kann ich verzichten.

Obwohl... wäre auch mal eine Übung.

Viel Spaß weiterhin.

[abc2006]

Nur um mal das Programm (naja, wenn mans genau nimmt eher script) rsnapshot in den raum geworfen zu haben.
leistet bei mir seit Jahren treue Dienste und verbraucht in Summe weniger Speicher als Images...

Grüße
Stephan

[Wernieman]

alternativ dirvish oder andere auf rsync basierende Derivate .. hat noch den Vorteil, das man verschiedene "Versioenn" hat. Und die Platzersparnis kommt durch das Incrementelle Sichern, d.h. nur die Änderungen, trotzdem ist jedes wie ein "FULL" zu betrachten.

Ist aber ein FHEM und kein Systembackup!

(Ich sichere aber bei mir /etc/ fhem und Datenverzeichnisse auf extern angeschaltete/gemountete Festplatten als "die Backup Lösung". Bei mir ist aber auch ein Linux-System schneller aufgesetzt als ein Full-Restore eingespielt ...)

[UlfS]

Also ich habe meine Synology in FHEM gemounted und schiebe dort auch ältere Logs per FHEM weg, Parallel dazu ein Verzeichnis, wo ich per RaspiBackup.sh (google) automatisch eine wöchentliche dd und tar Sicherung mache. Von dd behalte ich drei Versionen, von tar mehr.

Bei Problemen - schon häufiger passiert - kann ich das dd-Backup auf eine SD schmeissen und mit den Stand vom letzten Sonntag weiter machen. Wenn die Probleme es zulassen, kann man auch die logs übernehmen oder aus der tar-Sicherung nur die fhem.cfg ziehen. Hängt halt davon ab, was schiefgelaufen ist.

Letztens bin ich von raspi2 auf 3 umgezogen, und meine Linux-Basis war korrupt (beim Update honterher unbrauchbar). Da konnte ich alles neu installieren, aber fhem und logs hinterher übernehmen und auch crontab etc auf der Syno checken und die notwenidigen Zeilen auf dem Raspi nachziehen.

Kann ich nur empfehlen.

Lg, Ulf

[Puschel74]

*persönlicheMeinungEin*
Anfangs die komplette SD zyklisch sichern macht vermutlich Sinn.

Später kommen nur noch selten Linux(Perl)-Pakete dazu und FHEM wird vermutlich auch nicht so oft per update auf den neuesten Stand gebracht.
Mein Cubie bootet aus dem NAND und der Rest liegt auf einer SSD.
Wenn ich ein

Code Auswählen Erweitern

apt-get update/upgrade am Cubie einwerfe landet alles auf der SSD (hoffe ich zumindest  ).
Bevor ich ein

Code Auswählen Erweitern

updatein FHEM einwerfe schaue ich erstmal im Forum ob sich jemand über ein fehlerhaftes Update beschwert, wenn nicht
dann mache ich in FHEM ein save und sicher mir danach /media/hdd/fhem auf meine Netzwerkplatte und lass FHEM ein update durchführen.
Wobei ich FHEM-Updates erst auf einem meiner "Satelliten-RasPi" einspiele bevor mein Produktivsystem dran kommt.
Produktiv ist zu Zeit:

fhem.pl              12729 2016-12-09 12:48:50Z rudolfkoenig

also recht "frisch".
Im Heizraum ist ein

# $Id: fhem.pl 6080 2014-06-07 16:12:09Z rudolfkoenig $

installiert und läuft und läuft und ...
Ok, da hängen nur 5 I2C-LM75-Sensoren dran und er hat sonst nichts zu tun (war ein Spassprojekt damals)

Also wozu immer alles updaten wenn der vorhanden Stand zufriedenstellend läuft?
*persönlicheMeinungAus*

[Ajuba]

Danke für die vielen Rückmeldungen
Ich habe mich nun nach Testläufen für folgendes Prozedere entschieden

   
• Immer Mitschreiben was ich installiere und ändere
• Fhem regelmäßig und vor allem vor einem Update mit "Backup" sichern (wahrscheinlich auch automatisiert)
• SD Karten-Image mit Win32DiskImager sichern. Damit sollte auch mein Wunsch erfüllt, dass ich ohne Abhängigkeit vom Internet wieder ein laufendes System bekomme

Das Zurückspielen des Fhem Backups mache ich mit puTTY

   
• Fhem stoppen mit "sudo /etc/init.d/fhem stop"
• Restore mit ,,sudo tar -xvzf /opt/fhem/backup/FHEM-201xxxxx_xxxxxx.tar.gz -C /opt/fhem/"
• Fhem starten mit "sudo /etc/init.d/fhem start"

Zum SD Karten-Image mit Win32DiskImager sichern habe ich noch eine Frage bzw. eine Idee zur Optimierung:
Bei der Erstinstallation habe ich - wie im Wiki empfohlen - meine SD Karte mit "sudo raspi-config" auf die vollen 32 GB aufgeblasen.
Beim Sichern werde ich jetzt natürlich auch (nach 40 Minuten ) mit einem 32 GB Image beglückt - welch Freude.Ich frage mich nun, ob es nicht sinnvoller wäre eine z.B. 4 GB Partition für Raspian+Fhem zu machen und die restlichen 28 GB als eine zweite Partition zu definieren wo dann Logfiles und Backups hinwandern. Die 4GB Partition ergibt ein leichtes Image und die Logfiles und Backups sollten sowieso regelmäßig aufs NAS wandern.

   
• Warum wird im WIKI und in Blogs die volle SD Karten Nutzung favorisiert und nicht die Aufteilung in "Betriebssystem" und "Nutzdaten"?
• Falls die Aufteilung machbar und sinnvoll ist, wie macht man das richtig?
• Wie gibt man dann dem Backup directory und FileLog den richtigen Pfad auf der anderen Partition mit? (Sorry bin noch sehr Linux unerfahren)