Mit dd Partition kaputt gemacht

  • Hallo zusammen!

    Ich hatte mir einen nagelneuen Raspi 4b mit nagelneuer SD-Karte eingerichtet und darauf eine Steuerung programmiert. Leider hat die SD-Karte nach ein paar Tagen schon beim Booten "kernel panic" gebracht und war auch nicht zu reparieren. So habe ich mir mit dd die beiden Partitionen auf einem anderen Raspi als sda1.img und sda2.img gesichert. Hat funktioniert, alle Daten waren noch da. Juchhu!
    Dann habe ich mir eine SSD gekauft, weil die gehen ja nicht so schnell kaputt, und wollte die beiden IMG-Dateien auf neu eingerichtete Partitionen kopieren. Hatte schon mal ausprobiert, wie man den Raspi 4 von Festplatte bootet und das klappt ja jetzt.

    Jetzt kommts: Ich wollte eingeben "dd if=/media/pi/extern/sda1.img of=/dev/sdb1" war aber kurz abgelenkt und habe als Ziel sda1 eingegeben und "Enter". Gemerkt habe ich das zwar sofort, aber.... PUFF!

    Jetzt sind also die ersten 256 Megabyte einer 1,8 Terrabyte großen Partition überschrieben.

    Hat vielleicht irgend jemand eine Ahnung, wie ich an meine Daten drankommen? Angezeigt wird nämlich gar nichts mehr.

  • Tja, leider wars die Backup-Platte, und ein Backup vom Backup habe ich nun nicht vorrätig. Ausserdem ist es noch ein wenig komplizierter.

    Es ist eine externe Festplatte, was bei einem Raspi normal ist. Und fertige Platten sind ja schon formatiert, meist in exFat. Ist bei einer Backup-Platte sinnvoll, weil man sie einfach an irgend einen Rechner anstecken kann und kopiert seine Dateien drauf. Sogar ein Handy kommt damit klar.
    GParted sieht das Ding als ext4 Dateisystem, (?sda1.img ist fat32?), fdisk -l zeigt dagegen "HPFS/NTFS/exFAT".

    Hach, ist das schön.

    Windows will neu formatieren, die Macs sehen eine schicke leere Platte, ganz wie die Raspis.

    Ich dachte halt, sowas wäre auch schon mal einem Anderen passiert und ich müsste nicht das Rad neu erfinden.

  • Es gibt auf dieser externen Platte nur eine Partition. Beim Raspi ist das dann /dev/sda1, weil er meist von der Partition /dev/mmcblk0p1 bootet. Da ich aber schon lange mit Linux arbeite, nur mit dem Raspi noch nicht, nenne ich die Bootpartition gewohnheitsmäßig sda1. Und so habe ich das Backup von mmcblk0p1 mit dem Namen sda1.img benannt.

    Als ich dann das Backup sda1.img auf eine SSD kopieren wollte, die ich an den Raspi gehängt habe, an dem auch die Backup-Platte dran ist, wollte ich das Backup auf die Bootpatition der SSD kopieren, welche, weil sie ja die zweite Platte ist, den Namen sdb1 trägt. War mir ja auch klar, nur..., und so habe ich sda1 eingetippt und "Enter" gedrückt. Und schon ist der Anfang der 1,8 GB großen Partition mit dem Inhalt der kleinen Bootpartition überschrieben worden.

    Das bischen Daten am Anfang wäre ja nicht schlimm, wenn ich noch irgendwie an den Rest käme. Das Meiste sollte ich auch irgendwie wieder zusammen kriegen, weil es ja Backups sind. Aber ein Teil war Backup von nicht mehr vorhandenen Geräten. Und das ist irgendwie dann doch zum rummuffeln.

  • Ist es eine GPT-partitionierte Platte? Dann kannst du am Ende der Platte die Partitionstabelle finden und sie nach vorne kopieren.

    Wenn das nicht geht (MBR-Partition) =>

    War nur eine Partition auf der Platte? Dann könntest du mit dd die ersten 4k überschreiben:

    dd if=/dev/zero of=/dev/sda count=4096

    Danach rufst du fdisk auf und legst eine Partition an, die über die gesamte Platte reicht.

    Diese Partition wird NICHT formatiert,

    ab Byte 4097 ist sie formatiert, jetzt kannst du versuchen, die Daten danach zu lesen, es gibt Kopien des letzten Inhaltsverzeichnisses an den Stellen, in denen die Superblock gehalten werden.

    Ein fsck auf das Dateisystem sollte funktionieren.

    Computer ..... grrrrrr

  • dd if=/dev/zero of=/dev/sda count=4096

    ...


    ab Byte 4097 ist sie formatiert,

    Nö, da die default Blocksize bei dd idR. 512 Byte beträgt nullst du damit (count*bs: 4096 * 512Byte) 2097152 Byte (2MB).

    Wenn du nichts zu sagen hast, sag einfach nichts.

    Einmal editiert, zuletzt von llutz (10. November 2020 um 10:57)

  • Wenn auf /dev/sda1 geschrieben wurde, ist die Partitionstabelle/MBR/GPT nicht weg. Es wurden nur die ersten 256 MB des (EXT4 ?) Filesystems überschrieben.

    Wenn es ein EXT4 Filesystem ist, könntest Du mit Glück noch den unzerstörten alternativen Superblock erreichen.

    Hast Du mit < sudo dumpe2fs -o superblock=32768 -o blocksize=4096 /dev/sda1 > eine Gruppen- Block- Inode- Anzeige ?

    Sonst musst Du die Dateiwiederherstellung mit https://de.wikipedia.org/wiki/TestDisk , oder https://de.wikipedia.org/wiki/The_Sleuth_Kit , oder sonstigen forensic Tools versuchen.

    Servus !

    RTFM = Read The Factory Manual, oder so

    • Offizieller Beitrag
    Zitat

    Und fertige Platten sind ja schon formatiert, meist in exFat.

    Ich bekam bisher nur NTFS-formatierte externe HDDs zu kaufen.

    Zitat

    war aber kurz abgelenkt und habe als Ziel sda1 eingegeben

    Die "1" möchte ich nur nochmals hervorheben um Missverständnisse bezüglich Partitionstabelle zu vermeiden, aber RTFM hat es erkannt. ;)

  • hast Du kein Backup?

    Nein, ein Backup gab es nicht :( Darauf befanden sich verschiedene Backups von diversen Raspberian OS Versionen und Konfigurationen (SD only, SD boot, ext root und USB boot only) aber auch anderen OSen wie ubuntu et al. Die waren nuetzlich wenn Probleme mit den OSen gemeldet wurden. Ich musste dann keine Installation vornehmen sondern konnte das OS einfach restoren und dann das Problem versuchen nachzustellen. D.h. es ist kein Beinbruch - nur bedeutet es Mehraufwand da wenn ich ein Problem reproduzieren muss erst einmal das OS wieder installieren und konfigurieren muss :( Ein Restore des Backups geht schneller.

    Shit happens,

    Jupp, da das gerade Thema hier ist konnte ich nicht umhin dem TE ein wenig Trost auszusprechen - er ist beileibe nicht der Einzige dem sowas passiert :shy:

    Zitat

    Hoffentlich ist das nicht das Ende vom raspiBackup.

    Nein, der Code ist bei mir lokal auf einem git Server der regelmaessig mit raspiBackup gesichert wird. Ausserdem steht der Code im github - wenn auch etwas Backlevel.


    Die Regressiontestumgebung wird noch nicht gesichert und das war eine ziemliche Arbeit die aufzusetzen. Ich nehme den Vorfall mal als Anlass die auch zu sichern.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!