[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?