[gelöst] RasPi .img lässt sich nicht mehr einspielen

[grappa24]

moin,

meine bisherige Backup/Restore Strategie sah wie folgt aus:

- Backups automatisiert und periodisch mit dd auf einem NAS erstellen
- Bei Bedarf die .img Datei mittels Win32 Disk Imager auf eine (neue) SD-Karte übertragen
- RasPi damit starten -> läuft wieder

Meine aktuelle SD Karte hat wohl nach langer Zeit mal wieder Schreibfehler, was sich dadurch bemerkbar macht, dass z.B. gespeicherte Einstellungen nach einem Neustart verloren sind.

Kein Problem dachte ich, hab ja die .img Sicherungen.

Nur lässt sich leider mein System nicht mehr mit dem Restore-Img (getestet mit 2 verschiedenen SD-Karten) starten.

Welche Möglichkeiten habe ich nun
a) die Korrektheit meiner .img Datei zu prüfen bzw. mir
b) auf einer neuen SD Karte ein funktionierendes System mit dem alten Stand wiederherzustellen?

Ich häng mal die Struktur meiner SD Karte an.

[MadMax-FHEM]

Von autom. Komplett-Image-Sicherungen im Betrieb hab ich noch nie nix gehalten...

q.e.d

Zu a: keine Ahnung, ob das sinnvoll geht...

Zu b: wenn du Glück hast, sind fhem und andere wichtige Daten nicht betroffen. Also neues System und dort die Daten einspielen...

Backup/Restore generell überdenken!

Gruß, Joachim

[grappa24]

Also neues System und dort die Daten einspielen...

Joachim, kannst du mir das bitte kurz skizzieren?

[MadMax-FHEM]

Joachim, kannst du mir das bitte kurz skizzieren?

Schwer.
Weiß ja nicht was auf dem alten System du noch brauchst?

Im Prinzip: neu aufsetzen auf neuer SD -> Internet

Alte Daten: SD mounten (besser halt ein Linux System, geht auch Live-Boot / es geht nat. auch den PI mit neuer SD zu nehmen, alte SD dann per USB-Adapter), Daten z.B. per tar "zusammenfassen" -> man tar (auf der Linux Console) oder Internet / dabei werden Dateirechte etc. "mitgenommen" (sofern das neue System "wie das alte" ist, passen die auch meist wieder)

Dann neue SD mounten (nach erstem Start wg. diverser Dinge die autom. bei einem ersten Boot passieren [können]): per tar Daten zurückspielen

Ausprobieren.
Wenn etwas fehlt -> fehlende Daten halt kopieren, siehe oben (ob dann unbedingt noch mal per tar oder nur per cp oder scp musst du wissen bzw. hängt es von Anzahl der Daten usw. ab)

Gruß, Joachim

[RalfRog]

Hi
Nur mal so nachgefragt.

Die Dateien auf der boot-Partition sind vom Mai 2023. Passen die zur root Partition - falls du zwischenzeitlich OS-Updates gemacht haben solltest?
Keine Ahnung wann beim Raspberry mit Buster das letzte Kernelupdate war (normalerweise wird natürlich die boot-Partition mitgezogen und sollte passen).

Wenn du einen Bildschirm an den PI hängen kannst ist vielleicht auch erkennbar an welcher Stelle der PI hängen bleibt.

Gruß Ralf

[grappa24]

ich hab jetzt mal versucht, die SD-Karte an einem Windows PC mit Win32DiskImager zu kopieren, also nicht im laufenden Betrieb. Da erhalte ich aber die Meldung CRC-Fehler. Fürchte die Karte ist hin ...

[CoolTux]

Auf einem Linuxsystem kann Mann versuchen das img File eventuell zu laden. mount -o loop /mnt /path_to_img

[CoolTux]

https://thomasheinz.net/img-file-disk-image-unter-linux-mounten/

[Wernieman]

Und iso, bzw. die Partitionen darin können dann auch mit fschk geprüft werden. Siehe den von CoolTux geposteten Link.
(Ist allerdings nicht gans Trivial, wenn man wenig Unix-Wissen hat)

[grappa24]

nur noch mal zum Verständnis, meine Image-Files habe ich "im laufenden Betrieb" mit dd erstellt; wenn ich die auf eine neue Karte aufspiele startet debian nicht.

Die einzige SD-Karte mit der mein Debian/FHEM noch startet hat die Struktur wie im Ausgangspost, die lässt sich aber mit Win32DiskImager wegen eines CRC-Fehlers nicht klonen.

Welches Image-File soll ich denn jetzt laden/mounten?

[CoolTux]

Erstmal schauen was der letzte Dump sagt. Geht erstmal nur darum an die Daten zu kommen.

[Wernieman]

Das riesen Problem von im laufenden System mit dd erstellten Image sind die "Offenen" Dateien. Es kann funktionieren, muß aber nicht (QED).

Wenn Du jetzt mehrere Images hast, kannst Du ausprobieren welches funzt, oder mit fschk das Image überprüfen, Wenn Du nur ein hast ....

Ansonsten, siehe Post von CoolTux: Neu Installieren (auf neuer SD) und die FHEM-Daten versuchen zu retten

[grappa24]

Code Auswählen Erweitern

fdisk -l /backup/RasPiBackup-20240608-092558.img
Disk /backup/RasPiBackup-20240608-092558.img: 10,1 GiB, 10861293568 bytes, 21213464 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x6721ba43

Device                                   Boot Start      End  Sectors  Size Id Type
/backup/RasPiBackup-20240608-092558.img1       8192    98045    89854 43,9M  c W95 FAT32 (LBA)
/backup/RasPiBackup-20240608-092558.img2      98304 31116287 31017984 14,8G 83 Linux

Die erste Partition lässt sich mounten:

Code Auswählen Erweitern

sudo mount -t auto -o loop,offset=$((8192*512)) /backup/RasPiBackup-20240608-092558.img /mnt/sd1
Bei der zweiten gibts "overlapping loop device":

Code Auswählen Erweitern

sudo mount -t auto -o loop,offset=$((98304*512)) /backup/RasPiBackup-20240608-092558.img /mnt/sd2
mount: /mnt/sd2: overlapping loop device exists for /backup/RasPiBackup-20240608-092558.img.

[grappa24]

oder mit fschk das Image überprüfen, Wenn Du nur ein hast ....

Ich hab schon noch mehrere Images die ich probieren werde, über eines hab ich mal fsck laufen lassen:

Code Auswählen Erweitern

sudo fsck /backup/RasPiBackup-20240521-234537.img
fsck from util-linux 2.33.1
e2fsck 1.44.5 (15-Dec-2018)
ext2fs_open2: Ungültige magische Zahl im Superblock
fsck.ext2: Superblock ungültig, Datensicherungs-Blöcke werden versucht ...
fsck.ext2: Ungültige magische Zahl im Superblock beim Versuch, /backup/RasPiBackup-20240521-234537.img zu öffnen

Der Superblock ist unlesbar bzw. beschreibt kein gültiges ext2/ext3/ext4-
Dateisystem. Wenn das Gerät gültig ist und ein ext2/ext3/ext4-
Dateisystem (kein swap oder ufs usw.) enthält, dann ist der Superblock
beschädigt, und Sie könnten versuchen, e2fsck mit einem anderen Superblock
zu starten:
    e2fsck -b 8193 <Gerät>
 oder
    e2fsck -b 32768 <Gerät>

In /backup/RasPiBackup-20240521-234537.img wurde eine dos-Partitionstabelle gefunden


[Wernieman]

Da ein Image aus mehreren Partitionen besteht, kann fsck nicht funktionieren.

z.B. ein Check auf /dev/sda wird nicht funktionieren, wenn musst Du auf /dev/sda1 gehen. Dein Check ist vergleichbar mit dem auf /dev/sda

Edit:
Und wegen den Loopmount, hast Du versucht, den vorherigen Mount zu unmounten?

[grappa24]

Und wegen den Loopmount, hast Du versucht, den vorherigen Mount zu unmounten?

verstehe, kann immer nur eine der beiden Partitionen gemountet sein

[Wernieman]

Eigentlich Nein ... aber bevor ich versuche es Dir zu erklären ... s.o. es ist kein Einfaches Thema ...

Und fürs Debuggen ist es einfach die simpelste Möglichkeit. Eigentlich zählt immer das KISS Prinzip: "keep it simple (and) stupid"

[Otto123]

Ich hatte das hier Mal im Detail beschrieben: https://heinz-otto.blogspot.com/2020/08/crash-recovery.html
Lässt sich mMn auch auf diesen Fall anwenden. Vielleicht hilft es.

[grappa24]

Teilerfolg: Ich konnte jetzt "die letzte funktionierende" img-Datei einspielen, leider von Dez-22 

Als nächstes spiele ich dann die fhem.cfg von gestern wieder ein, Daumendrücken dass das dann funktioniert.

P.S. Hätte mir zu denken geben sollen, dass sich nach Dez-22 die Größe der img-Datei fast halbiert hat
Aber: Das o.a. Image von Dez-22 war noch mit dd erstellt ...

[MadMax-FHEM]

Aber: Das o.a. Image von Dez-22 war noch mit dd erstellt ...

Die Bemerkungen haben ja nicht/nie geheißen, das klappt nie...

Aber es ist (wie du siehst) auch nicht (immer) verlässlich...

Ich würde daher meine Backup-/Restore-Strategie überdenken...
Bzw. mache ich ja eh (genau deshalb) nix Komplett-Image im Betrieb...

Dann noch viel Erfolg!

Gruß, Joachim

[grappa24]

Nach dem Einspielen meiner aktuellen fhem.cfg auf das "alte" Backup läuft mein FHEM wieder 

Danke für eure Unterstützung.

Gibts denn eine Möglichkeit, ein sicheres Backup automatisiert durchzuführen, ich möcht nur ungern "ständig" das System stoppen, die SD-Karte rausnehmen, kopieren, ....

Schönen Sonntag
Dieter/grappa24

[MadMax-FHEM]

Gibts denn eine Möglichkeit, ein sicheres Backup automatisiert durchzuführen, ich möcht nur ungern "ständig" das System stoppen, die SD-Karte rausnehmen, kopieren, ....

Kommt drauf an was alles drauf läuft...

Wenn nur fhem:

- fhem backup per at
- entweder umkopieren auf ein NAS etc.
- oder direkt auf eine gemountete Freigabe

Merken/notieren, welche (Perl) Pakete manuell (nach) installiert wurden...

Restore: PI (oder andere HW) neu aufsetzen, Pakete installieren (siehe "Notizen") und dann fhem installieren, Backup einspielen und tut (sollte: wenn nicht, dann fehlt bestimmt ein Paket o.ä. -> Log prüfen und nachinstallieren und v.a. notieren!)

So mache ich das und tut seit fast 10 Jahren und hat diverse Plattform-Wechsel und OS-Wechsel mitgemacht/ermöglicht...
(Ein Komplett-Image bringt dich nur zurück von wo GENAU das Image stammt. Evtl. vielleicht noch auf einen neueren PI aber sicher nicht auf eine andere Plattform oder gar OS / und sooo viel schneller geht es mit einem Komplett-Image auch nicht)

Andere PI mit anderen (Server) Diensten: je nachdem was diese Dienste für Backup/Restore anbieten und wie dynamisch die Daten sind...

Gruß, Joachim

[grappa24]

Als nächstes spiele ich dann die fhem.cfg von gestern wieder ein, Daumendrücken dass das dann funktioniert.

Allein die fhem.cfg zurückzuspielen erfordert ja noch einiges an Nacharbeit 

Sehr viel besser hat nun das FHEM backup (und restore) funktioniert 
... und da meine SD Karte noch lief (klonen geht nicht mehr) konnte ich ein sauberes backup erzeugen 

Gruß,
Dieter

[MadMax-FHEM]

Ja, mind. statefile -> letzte Zustände

uniqueID -> credetials...

Wenn du alexa-fhem (o.ä.) nutzt oder auf andere Rechner per ssh ohne PW verbindest, dann auch noch /opt/fhem/.ssh (nicht im backup)...

Gruß, Joachim