Hallo FHEM-Gemeinde!
nun hat es mich ereilt und bin nun ratlos und blicke in eine leere Gegend.
Seit Mittwochmorgen 03:57 tut es mein FHEM nicht mehr. Es hat sich verabschiedet!
Ich führe jeden Mo, Mit & Fr. eine Sicherung durch. Dazu habe ich immer ein gesamtes Abbild / Image auf meinem NAS abgelegt. Das letzte war von Mittwoch 03:57. Als ich in den frühen Morgenstunden
einen Blick auf die Hausautomation werfen wollte, stelle ich fest, dass FHEM nicht mehr erreichbar ist. Ich ahnte böses.
Ich weiß wo der Fehler liegt, aber ich habe keinen Plan wie ich das jemals wieder ans laufen bekommen soll.
Vor einigen Monaten hatte sich ein SD-Crash schon angekündigt, da das Backup nach kurze Zeit immer wieder abgebrochen wurde. Dann habe ich eine neue SD Karte eingelegt und das letzte Image eingespielt. Das lief eine ganz Zeit gut. Ich gehe nun davon aus, dass der SD Fehler, der ja auch auf dem Image ist sich nun auch auf der neuen Karte befand und ich somit weiter fleißig meine Sicherungen gemacht habe, ohne zu bedenken, dass ich den fehlerhaften Sektor immer artig mit gesichert habe.
Ich wäre ja schon im Ansatz zufrieden, wenn ich irgendwie das Image auslesen könnte um an die Konfiguration ran zu kommen, damit ich nicht gänzlich bei null anfange. Ich bin für jeden
Tipp dankbar!
Hi,
Du konntest jetzt ein altes Image wiederherstellen? Oder ist das aktuelle Image kaputt?
Du kannst das Image doch auch als Datei mounten, ich bin nicht der Linux Spezi aber ich meine das geht direkt? Dann erstmal einfach den Pfad /opt/fhem kopieren
Gruß Otto
leider nicht. Ich kann zwar das alte Image mittel ETCHER wieder auf die SK Karte kopieren, aber ich komme nicht an den Raspberry / FHEM ran!
Ich will nachher mla probieren, ob ich mittels Synology VirtualMaschineManager das Image einbinden kann.
Linuxrechner nehmen. Karte in den SD Slot stecken. mount -o loop /dev/$SDCARDDEVICE /mnt/sd-card
vorher bitte Verzeichnis /mnt/sd-card mit mkdir anlegen
ok.....
ich habe irgendwo noch ein Ubuntu virtuel abgelegt. Das werde ich ausprobieren.
Zwischenfrage:
Kann ich ein SD-Backup auf den USB-Stick legen während das System läuft? Bisher mache ich nur FHEM-Backup, aber jetzt bekomme ich Angst!
Hi bjoernbo,
ich habe hier was gefunden -> http://www.schnatterente.net/software/dd-festplatten-image-mounten
Diese Anleitung kann ich nachvollziehen und die funktioniert bei mir.
@accessburn
Auf alle Fälle das FHEM Backup woanders hinlegen. Von SD Images halte ich nichts - aber das ist meine persönliche Meinung.
Gruß Otto
Man kann ein Disk Image eines laufenden Systems machen, sollte man aber die Finger von lassen. Theoretisch kann dd das aber. Es wird von vielen Stellen aber nicht empfohlen da laufende Dienste zu einer inkonsistens führen können.
SQL Datenbank oder auch andere Formen von Datenbanken. Filesystemaufzeichnungen (Journal) zum Beispiel und so weiter.
Zitat von: Otto123 am 06 Juli 2017, 13:29:33
Auf alle Fälle das FHEM Backup woanders hinlegen. Von SD Images halte ich nichts - aber das ist meine persönliche Meinung.
Ja liegt auf dem USB-Stick, jeden Sonntag. Aber wenn man mal so überlegt, FHEM ist ja nicht alles, die ganzen anderen Einstellungen, Programme und Scripte die irgendwo liegen... Mensch das sammelt sich und jetzt bekomme ich es mit der Angst zu tun. Dann am WE mal Karte raus und durch Win32DiskImager durchjagen :)
Dein Problem ist das Du dich zu wenig mit dem LSB (https://de.wikipedia.org/wiki/Linux_Standard_Base) und dem ihm unterteilten FHS (https://de.wikipedia.org/wiki/Filesystem_Hierarchy_Standard) auskennst.
Denn dann wüstest Du genau wo sich was befindet und was Du davon sichern musst. Es ist nämlich nicht so viel. Wenn Du Deine Linux Config Files sichern willst reicht in der Regel /etc zu sichern. Deine persönlichen Scipte solltest Du entweder in Dein /home/USER legen oder besser da ja vom System ausgeführt in den meisten Fällen unter /usr/local/bin/
Somit weist Du ganz genau was Du mittels tar sichern musst. Ich hatte mal zu meiner Hochzeit einen tar Befehl womit ich in der Tat ein komplettes disaster recovery machen konnte.
Die meisten sachen habe ich schon wegen des wöchentlichen Backups direkt ins FHEM-Verzeichnis verfrachtet. Aber es wäre trotzdem viel Arbeit die ganze Software, alles wieder einrichten und einstellen. mit einem .bin wäre das besser, SD-Karte besorgen => Aufspielen => Fertig!
Das Problem ist jedoch, ich hatte das in meinen Raspianfängen schon versucht. Oft lies sich das Backup nicht zurückspielen weil die SD-Karte(n) andere Werte hatten als die Quellkarte.
Zitat von: CoolTux am 06 Juli 2017, 13:50:34
Somit weist Du ganz genau was Du mittels tar sichern musst. Ich hatte mal zu meiner Hochzeit einen tar Befehl womit ich in der Tat ein komplettes disaster recovery machen konnte.
Ich musste diesen Satz gerade drei Mal lesen, bissi ich erkannt habe, dass du Hochzeit (Oben) und nicht Hochzeit (Heirat) meinst :D
Ich oute mich, dass ich auch keine Ahnung habe. Das heißt, wenn ich Pakte bei Linux installiere und bei einer neuen Version /etc mit dem alten Ordner /etc ersetze, dann sind die installierten Pakete wieder drauf? Gibt es da nicht noch mehr Abhängigkeiten, auf die geachtet werden muss? Eigene Skripte mal ausgenommen.
Zitat von: Amenophis86 am 06 Juli 2017, 14:11:39
Ich musste diesen Satz gerade drei Mal lesen, bissi ich erkannt habe, dass du Hochzeit (Oben) und nicht Hochzeit (Heirat) meinst :D
Ich oute mich, dass ich auch keine Ahnung habe. Das heißt, wenn ich Pakte bei Linux installiere und bei einer neuen Version /etc mit dem alten Ordner /etc ersetze, dann sind die installierten Pakete wieder drauf? Gibt es da nicht noch mehr Abhängigkeiten, auf die geachtet werden muss? Eigene Skripte mal ausgenommen.
Ja natürlich muss man schon auf vieles Links und Rechts acht geben. Aber das kommt von alleine wenn Du Dich um Dein System kümmerst.
Du kannst kein 3 Jahre altes unangetastetes System nehmen, /etc sichern und dann weil Dein System im Po ist ein neues frisch aktuelles installieren und einfach /etc rüber kopieren.
Also System und Backup aktuell halten. Als zweites lohnt es sich sich zu merken in welchen Dateien Du Anpassungen gemacht hast und welche komplett von Dir stammen. Denn nur die brauchst Du auch wirklich zurück kopieren. Die anderen kannst Du aussen vor lassen. Also vielleicht nicht gleich /etc/ komplett zurück spielen sondern einzelne Dateien wo Du weißt da habe ich was gemacht. Linux ist konfigurationsmäßig simpel gestrickt. What you see is what you get.
Grüße
Ich finde es schon interessant wie nun darüber diskutiert, nachdem ein betroffener mal schön ins Klo gegriffen hat. Vielleicht sollten man im WIKI (sofern noch nicht vorhanden) auch mal einen Artikel zur richtigen und regelmäßigen Sicherung integrieren.
Unter UBUNTU konnte nur die BOOT-Partition eingegangen werden. Allerdings gibt es ein Tool unter UBUNTU mit welchem ich nun auf mein Dateisystem zugreifen kann. Dies lässt sich zwar nicht einhängen, aber ich kann ausschließlich vom Dateisystem ein weiteres Images ziehen. Mal sehen ob ich dann weiterkomme.
Kein Bange, diese Diskussionen gibt es regelmäßig. ::)
Das er die Partition nicht einhängen kann klingt nicht gut. Ein älteres Image kannst Du auch nicht direkt öffnen?
Gruß Otto
negativ! ich habe mir diesen sch... Fehler schön mitgesichert!! Irgendwo habe ich noch ein ganz altes Image, aber auch das hatte den Fehler schon.
Zitat von: bjoernbo am 06 Juli 2017, 16:06:34
Ich finde es schon interessant wie nun darüber diskutiert, nachdem ein betroffener mal schön ins Klo gegriffen hat. Vielleicht sollten man im WIKI (sofern noch nicht vorhanden) auch mal einen Artikel zur richtigen und regelmäßigen Sicherung integrieren.
Vielleicht ist ein Forum deswegen hilfreich, weil in verschiedenen Themen Dinge diskutiert werden auf Grund von genannten Problemen. Manchmal halt auch nur, dass Personen zukünftig nicht das Gleiche widerfährt.
Und wer ist dieser "man", der Wiki Artikel erstellt?
Aber Hey, widmen wir uns wieder ganz deinem Problem, ist ja auch dein Thread :)
Versteh ich jetzt als Linux-Amateur auch nicht, warum man an die gesicherte Partition nicht dran kommt. :-\ Aber probier es doch mal mit dem "Diskinternals Linux Reader" damit kann ich unter Windoof problemlos auf Partitions, SD-Card etc. zugreifen, so dass man wenigstens an das FHEM-Verzeichnis kommt.
Grüße Markus
Hallo,
Ich hatte so ein Problem auch mal. Ich muss gestehen hab jetzt nicht alles gelesen
Bei mir war der Fehler das die SD Karte voll war. Ich machte auch ein Image auf meine NAS. Die Nas war aber nicht erreichbar und trotzdem wurde das Image erstellt auch in das Verzeichnis wo es hin sollte. Also den Pfad der NAS. Weil die NAS aber nicht da war wurde das Image auf die SD Karte geschrieben in dem Verzeichnis. Mein RasPi startete noch und ich konnte mich auf der Konsole einloggen. Hab dann das Verzeichnis welches eigentlich zur NAS führt aufgerufen und alles Dateidn dort gelöscht. Nach einen reboot lief alles wieder.
Gruss
Jörg
Gesendet von meinem GT-N8010 mit Tapatalk
Hi,
Also um wirklich helfen zu können, bräuchten wir mal die konkreten Fehler!
Was genau sagt Dein UBUNTU wenn Du die Datenpartition mounten willst?
Was sagt ein fsck /dev/sd?2, wobei ? mit dem richtigen Buchstaben Deiner SD-Karte zu ersetzen ist?
Was schreibt dmesg -w während Du die SD-Karte einsteckst?
Und bitte keine Screenshots sondern Texte in CODE Tags ;-)
Gruß Arnd
Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Erstmal vielen Dank für eure Unterstüzung. Ich habe es am Ende geschafft wieder auf das Dateisystem zugreifen zu können um mir die Konfiguration und andere HTML Datein von FTUI zu sichern. Dennoch habe ich mich nun entschieden, alles nochmal von Grund auf NEU einzurichten.
Da ich nun eine "böse" Überraschung erlebt habe, treibt mich der Gedanke der Sicherung nun weiter voran. Eigentlich war mein Konzept bis zu einem bestimmten Zeitpunkt gar nicht verkehrt.
Was sollte man in regelm. Abständen prüfen?
Eine Art chkdsk für UNIX regelm. ausführen?
Welche FORM der Sicherung würdet ihr denn bevorzugen?
Nur einzelne Datein oder ein gesamthaftes Images?
Hi,
Für FHEM reicht eine Kopie von
/etc und /opt/fhem,
es sei denn man hat dblog aktiv oder Sonderthemen wie Scripte in anderen Bereichen/Ordnern.
Gruß Arnd
Gesendet von meinem SM-G800F mit Tapatalk
Und ganz wichtig, die Pakete, die man installiert aufschreiben!
Habe das leider vor einigen Monaten zu spät gelesen, somit bei mir nicht angewandt.
Bei einem Neu aufsetzen des Systems kann man somit ganz einfach alle nötigen Pakete für die Perl Module nach laden, ohne anschließend Fehler zu bekommen!
Zitat von: Fixel2012 am 07 Juli 2017, 11:36:19
Und ganz wichtig, die Pakete, die man installiert aufschreiben!
Habe das leider vor einigen Monaten zu spät gelesen, somit bei mir nicht angewandt.
Bei einem Neu aufsetzen des Systems kann man somit ganz einfach alle nötigen Pakete für die Perl Module nach laden, ohne anschließend Fehler zu bekommen!
dpkg -l > /list.txt
Zitat von: CoolTux am 07 Juli 2017, 11:38:39
dpkg -l > /list.txt
Kann es gerade nicht ausprobieren aber sollte das gehen, ist das mega! Danke für den Tipp!
Ich nehme an, der command packt alle installierten Pakete in eine txt datei namens list.txt?
nachteil, es werden immer noch keine mit cpan installierten Pakete angezeigt, oder?
Nein werden nicht. Wobei ich versuchen würde weitestgehend das Packetsystem der Distrie zu verwenden.
Es gab da noch eine bessere Möglichkeit wo man direkt den install Befehl machen konnte. Ich such das mal. Bei dem was ich oben geschrieben hate muss man noch etwas nacharbeiten.
Zum sichern einer Packetliste
dpkg --get-selections | awk '!/deinstall|purge|hold/ {print $1}' > packages.list.save
Zum installieren von Packetenaus einer Packetliste nach einer Neuinstallation und dem Updates
xargs -a "packages.list.save" sudo apt-get install
Werden so auch die bei der Installation getätigten Einstellungen gesichert und wieder aufgespielt? Und ich meine nicht die von Hand geänderten Dateien.
Zitat von: Amenophis86 am 07 Juli 2017, 12:58:29
Werden so auch die bei der Installation getätigten Einstellungen gesichert und wieder aufgespielt? Und ich meine nicht die von Hand geänderten Dateien.
Nein. Das Packetsystem der Distribution legt beim installieren eine interne Datenbank an welche Packete es gibt und welche installiert sind. Welche installiert sind ließt der Befehl aus.
Beim Rückspielen wird alles versucht zu installieren was auf der Liste steht, was bereits installiert ist wird übersprungen. Bei der Installation von nicht vorhandenen Packeten wird natürlich auch die Config der/des Anwendung/Packetes wenn benötigt mit installiert. Aber halt die Config des Maintainers und nicht Deine vielleicht mal veränderte. Das muß dann aus einem Backup zurück gespielt werden.
Es ist wirklich nicht mehr wie eine Liste der installierten Packetnamen.
Zitat von: bjoernbo am 07 Juli 2017, 10:12:56
Was sollte man in regelm. Abständen prüfen?
Eine Art chkdsk für UNIX regelm. ausführen?
man badblocks
Zitat von: bjoernbo am 07 Juli 2017, 10:12:56
Welche FORM der Sicherung würdet ihr denn bevorzugen?
Mein FHEM-Konfiguration ist in einem Git-Repo welches offsite liegt, dreifach gesichert wird und auf zwei Computern zum Entwickeln nochmals liegt. Die Logdaten von FHEM werden auf einem zentralen Logging-Server gesichert und liegen nicht auf dem RPi, auf dem FHEM läuft. Das Raspbian-System an sich wird nicht gesichert, denn ich habe das Setup mit Puppet soweit automatisiert, dass ich eine lauffähige FHEM-Installation innerhalb von einer Stunde frisch erzeugen kann. Dazu muss ich nur eine Vanilla-Raspbian-Installation erstellen, Puppet draufmachen und warten. Die Backups, die von FHEM selbst erzeugt werden, werden auf einen NFS-Share gesichert, der auf meinem NAS liegt (und dort rotiert).
Zusätzlich habe ich mehrere Raspbians im cold standby, ebenso mehrere SD-Karten etc.
Mein FHEM-Raspi bootet aber auch nur von SD-Karte und macht den Rest über HDD.
Zitat von: bjoernbo am 07 Juli 2017, 10:12:56
Nur einzelne Datein oder ein gesamthaftes Images?
Images von 64GB-SD-Karten sind zu groß ;-)