Problem beim Wiederherstellen des Backups

[mrniceguy]

Hallo zusammen,
gestern hat die SD-Karte im Raspi den Dienst eingestellt Also hab ich mir heute eine neue Karte beschafft und die Basis entsprechend eingerichtet.
Nun wollte ich das Backup von letztem Dezember einspielen, nur leider scheint damit etwas nicht zu stimmen, in der Konsole bekomme ich folgende Meldung

Code Auswählen Erweitern

pi@raspberrypi:~ $ sudo tar -xvzf /home/pi/FHEM-20231230_115626.tar.gz -C /opt/fhem/
gzip: stdin: invalid compressed data--format violated
tar: Child returned status 1
tar: Error is not recoverable: exiting now

Auf dieser Seite habe ich einen Hinweis gefunden, dass das Problem durch die Übertragung per FTP auf einen Windowsclient Zustande kommen könnte. Da ich die Backup-Datei auch per FTP auf meinen Win-Rechner übertragen habe, habe ich noch Hoffnung mein FHEM nicht komplett neu einrichten zu müssen 
Leider kann ich mit dem Lösungsvorschlag zur Reparatur nichts anfangen. Hier bräuchte ich etwas Hilfe, wie ich dies umsetzen könnte.

Schonmal vielen Dank!
VG Andreas

[Otto123]

Hallo Andreas,

das klingt mir nicht so als wäre dein Backup zu retten (Wenn Dein Hinweis stimmt). Aber ich hatte einen solchen Fall noch nie.

Ich meine: wenn die Theorie der Ursache stimmt, ist die Wiederherstellung nicht so trivial wie in deinem Link ausgeführt.
Um die Theorie halbwegs zu belegen könntest Du folgendes unter Linux ausführen:
Die Anzahl der Folgen cr lf ermitteln (Zeilenumbruch Windows)

Code Auswählen Erweitern

hexdump -C /home/pi/FHEM-20231230_115626.tar.gz|grep '0d 0a'|wc -lDie Anzahl lf ermitteln (Zeilenumbruch Linux)

Code Auswählen Erweitern

hexdump -C /home/pi/FHEM-20231230_115626.tar.gz|grep '0a'|wc -lWären diese beiden Zahlen nicht gravierend unterschiedlich könnte es ein Beleg für die erwähnte Theorie sein.
Weiterbringen wird uns das Ergebnis nicht: Da die Folge 0d 0a in jedem Binärfile vorkommen kann. Die einfach zu ersetzen wäre mMn wirklich zu platt.

Was ist mit der alten SD Card wirklich los? Vielleicht ist von der noch alles zu retten?
https://heinz-otto.blogspot.com/2020/08/crash-recovery.html

Gruß Otto

[mrniceguy]

Hallo Otto,

danke für den Tip - werde ich mal prüfen.

Schöne Ostertage!
VG Andreas

[RalfRog]

 Hallo
Du kannst dir ja mal auf dem PC ne zweite Meinung zur Backup-Datei einholen.

Bringt vermutlich nix aber als Versuch (wenn Ottos Vorschläge auch nicht helfen) und letzter Rettungsanker mal mit 7-Zip entpacken und gucken worüber der so meckert.

Gruß Ralf

[Müller]

Hallo,
auch wenn die SD Karte den Dienst eingestellt hat kannst du mal probieren, diese an den Raspi (mit der neuen Karte gestartet) anzuschließen und schauen, ob du die Backupdatei noch lesen kannst.
(Übrigens habe ich meinen Raspi auf eine kleine SSD über USB umgestellt. Das SD Karten Problem kommt immer wieder)

Gruß
Jochen

[Sany]

Moin,

(Übrigens habe ich meinen Raspi auf eine kleine SSD über USB umgestellt. Das SD Karten Problem kommt immer wieder)

das habe ich auch, aber kürzich war mal (ein tatsächlich SEHR seltener) Stromausfall und einer meiner 2 Raspis, die ein fhem beherbergen, hat nicht mehr gebootet (ein Raspi4, sollte aber erst mal nicht wichtig sein).

@mrniceguy: solltest Du noch von der Karte lesen können:
Was habe ich gemacht: die Platte an einen Linuxrechner angeschlossen und geschaut, ob noch irgenwas lesbar ist. Tatsächlich war eigentlich noch alles lesbar, jedenfalls das /opt-Verzeichnis komplett. Dieses habe ich dann komplett auf den Linux-Rechner kopiert.
Habe dann verschiedene "Reparatur-versuche" unternommen, das hat aber insofern nix gebracht, dass der Raspi weiterhin nicht gebootet hat.
Dann habe ich die SSD mit gparted eine neue Partitionstabelle erstellt (das löscht sowieso alles), danach dann mit dem Raspi-imager ein neues Image mit RaspiOS 64 lite (also headless) draufgeschrieben.
Danach das gesicherte /opt-Verzeichnis wieder draufkopiert.
SSD an den Raspi, gebootet, läuft.
Dann eine neue fhem-Installation manuell eingerichtet (debian.fhem.de -> manual install). Beim "Install package" wurde dann bemerkt, dass schon eine fhem.cfg vorhanden ist. Das Überschreiben habe ich verneint, anschliessend fhem gestartet und meine alte Installation ist wieder auferstanden. Dann das Log durchgesucht was angemeckert wurde (z.B. habe ich auf diesem Raspi dblog und HMCCU im Einsatz, die weitere Perl-Module benötigen). Die fehlenden Module installiert, fhem neu gestartet und alles lief genau wie vorher.
Kann natürlich sein, dass ich da insgesamt Glück gehabt habe, vielleicht hats aber auch nur das Booten "kaputtgemacht" und die Daten waren alle noch da. Auch dass nicht etliche Zusätze mit auf dem Raspi liefen hat geholfen (z.B. der SignalBot würde doch einiges an Nacharbeit erfordern.)

Versuch macht kluch.


Viel Erfolg!



Sany