(gelöst) GAU: mit gparted die zu sichernde Platte „geleert“

[fischig]

In der Vorbereitung eines Komplett-backups habe ich gerade den GAU schlechthin produziert.
Statt der Platte, auf die das backup soll, habe ich via grml-live mit gparted die zu sichernde Platte „geleert“, d.h. alle Partitionen gelöscht.
Danach habe ich noch nichts gemacht. Heißt, grml läuft noch. Keine weitere Aktion bisher. Lässt sich der GAU rückgängig machen?

[Tintom]

Wurden die Daten schon von gparted geschrieben?

[fischig]

Ja, das ist ja das Problem. Also, ich habe, nachdem ich die Partitionen zerstört (deleted) habe, „Ausführen“ geklickt. Erst dann ist mir mein Fehler aufgefallen.

[debilian]

ich werfe mal ein ddrescue in den Raum....

[Meillo]

ich werfe mal ein ddrescue in den Raum....

Das macht auf jeden Fall Sinn: Erstmal den aktuellen Zustand sichern und dann schauen was man damit macht. Ein Image kann man dann auch kopieren, um was auszuprobieren und wenn es schief laeuft, faengt man einfach wieder mit dem Ausgangszustand an.


Wenn nur die Partitionstabelle geloescht ist, sind nicht automatisch auch die Daten geloescht. Wenn man eine identische Partitionstabelle baut, ist vielleicht wieder alles wie zuvor.

Falls du noch eine Anzeige der Partitonstabelle hast, dann fotografiere/kopiere diese!

[fischig]

Falls du noch eine Anzeige der Partitonstabelle hast, dann fotografiere/kopiere diese!

Wird wohl weg sein, zumindest weiß ich nicht, wo/wie ich die finden könnte.

Das Schema war nicht kompliziert und habe ich (grob) im Kopf: Kapazität 320GB, 3GB swap, eine erweiterte Partition und der „Rest“: sda5. Alles Linux/Debian-Buster mit ext4.

Erstmal den aktuellen Zustand sichern

Keine Ahnung, wie das zu machen wäre.

Wie gesagt, auf der Maschine läuft z.Z. grml-live (und zwar die vorletzte Version von 2014). Nach dem „Leeren“, habe ich nichts weiter gemacht. Ich traue mich aber auch nicht, grml zu beenden. Das hier schreibe ich von einer anderen Maschine aus.

[Meillo]

Nicht dass ich der grosse Spezialist diesbezueglich waere ... Wer mehr Ahnung hat, bitte korrigieren!


Aus meiner Sicht sollte man zwei Dinge tun:

1) Im laufenden System ggf. eine Moeglichkeit finden wie man die vorige Partitionstabelle noch finden kann. Vielleicht hat gparted ein Undo, oder es schreibt sie in ein Logfile, oder so was. Da habe ich keine Ahnung, aber wenn es etwas in der Art gibt, dann sollte man sie herauszufinden versuchen, bevor man das Livesystem beendet. (Die Partitionstabelle muss exakt stimmen.)

2) Die Festplatte z.B. mit `ddrescue' (oder einem normalen `dd') als Image auf einen anderen (groesseren) Datentraeger schreiben, um den aktuellen Zustand zu sichern. Dann kann man alle weiteren Aktionen auf dem Image (bzw. genauer gesagt auf einer Kopie des Images!) machen. So kann man experimentieren ohne irgendwas kaputt zu machen.

[fischig]

Ich fang mal mit 2. an. Ich habe eine zweite gleich große Platte per USB mit der Maschine verbunden (z.Z. noch nicht eingehängt). Der Plan war ja ein backup anzufertigen. Aber da sind halt noch Daten drauf (die ich nicht mehr benötige, eigentlich löschen wollte.) Kann ich jetzt (immer noch) tun, was ich eigentlich tun wollte: diese zweite Platte „leeren“, und dann mit dd eine Image-Datei der versehentlich „geleerten“ Platte drauf schreiben, ohne die versehentlich geleerte Platte weiter zu „beschädigen“?

[debilian]

ohne die versehentlich geleerte Platte weiter zu „beschädigen“?

wenn du die geleerte Platte mit dd oder sowas sicherst, passiert da nichts - sie hatte ja keine Fehler - ddrescue ist eher für fehlerhafte Platten...
raus kommt ja ein img:

Code: Alles auswählen

dd if=/dev/sdX of=/media/user/usbplatte/alteplatte.img

oder so...

danach kannst du ja mit der geleerten Platte experimentieren, das dd voher ist ja nur eine Absicherung...

ps. guck dir "status" bei dd an, damit du ungefähr weisst, wie lange das dauert - usb ist lahm

[slu]

Ja, das ist ja das Problem. Also, ich habe, nachdem ich die Partitionen zerstört (deleted) habe, „Ausführen“ geklickt. Erst dann ist mir mein Fehler aufgefallen.

testdisk kann auch Partitionen suchen, wie schon geschrieben aber auf jeden Fall ein Image machen und daran üben...

[mludwig]

Es gibt noch gpart welches versucht, anhand typischer Partitions-Signaturen eine defekte/gelöschte Partitionstabelle zu erraten. Das hat bei mir auch schon mal geklappt.

[Meillo]

Btw: Bei dd eine ordentliche Blockgroesse angeben, sonst dauert es ewig.

[fischig]

Btw: Bei dd eine ordentliche Blockgroesse angeben, sonst dauert es ewig.

Ging mir auch schon durch den Kopf. Welche? (Ich habe das zwar im Hinterkopf, aber als Laie mache ich das zu selten).

edit:
bs=1M, richtig?

[fischig]

Der (neu gstartete) grml-mc zeigt mir noch die beiden (eigentlich nicht mehr vorhandenen) Partitionen (sda1,swap und sda5,buster,ext4, besser gesagt die Einhängepunkte) der „geleerten“ Platte, ohne Inhalt. Kann man das irgendwie nutzen?

[fischig]

So, dd läuft. Ich schreibe das Bild auf eine Partition einer Platte, die noch ca 680 GB freien Platz bietet. Dateisystem dieser Partition ist ex2. Ich geh' mal davon aus, dass das nicht stört.

Wenn ich recht sehe, ist das Hauptproblem, alle Dateien und Verzeichnisse in der ehemaligen Partition /dev/sda5 wieder zu reaktivieren. testdisk und gpart sind die mir in diesem Zusammenhang mittlerweile bekannt gewordenen relevanten Pakete. Welches soll ich versuchen? Gelingt das, kann ich wohl mittels chroot und Bootloader-Konfiguration den Inhalt von ehemals /dev/sda5 irgendwo bootfähig hinkopieren.

[slu]

Welches soll ich versuchen?

Wenn Du ein Image hast probiere was die besser gefällt, funktioniert es nicht kannst Du immer noch das nächste probieren...

[Meillo]

Welches soll ich versuchen?

Wenn Du ein Image hast probiere was die besser gefällt, funktioniert es nicht kannst Du immer noch das nächste probieren...

Aber moeglichst auf einer *Kopie* des Images, weil sonst muesstest du es ja neu erstellen.

[fischig]

Nun, das kann noch heiter werden:

Code: Alles auswählen

dd bs=1M if=/dev/sda of=/media/[Einhängepunkt]/buster.img

läuft seit ca 3 1/2 Std. und ist erst bei knapp der Hälfte der 320GB. Lässt sich eine Kopie des Images schneller erstellen?

edit: code-tags ergänzt

[hikaru]

Nun, das kann noch heiter werden:
dd bs=1M if=/dev/sda of=/media/[Einhängepunkt]/buster.img läuft seit ca 3 1/2 Std. und ist erst bei knapp der Hälfte der 320GB. Lässt sich eine Kopie des Images schneller erstellen?

Das sind 13MB/s. Selbst USB 2.0 sollte etwa das Doppelte liefern. Die HDD(s) selbst sollten mindestens 60MB/s schaffen. Irgendwo ist da ein Flaschenhals.

Was die Partitionstabelle angeht:
Zeig mal die Ausgabe von:

Code: Alles auswählen

fdisk -l /dev/sda

Manchmal braucht der Kernel einen Reboot um eine geänderte Partitionstabelle zu lesen. Falls er noch die Alte hat, ließe sich damit das Partitionsschema schnell wiederherstellen.

[fischig]

Keine Partitionstabelle mehr gefunden mit

Code: Alles auswählen

fdisk -l /dev/sda

Ich schrieb ja oben schon: Die Einhängepunkte sind noch da. Unter /dev zeigt auch der mc lediglich sda, keine Partitionen.

Für die Fortsetzung denke ich (unter Verweis auf Meillos Insistieren auf der Arbeits-*Kopie*) an Folgendes: Die Image-Datei schreibe ich .Z. auf eine 1TB-große Platte, also nicht auf die eigentlich vorgesehene Backupplatte, die mit 320GB genauso groß ist wie das Original. Ich stelle mir vor, diese 320er Platte „platt“ zu machen, also alle Partitionen samt Inhalt zu löschen, keine Partitionen und kein Dateisystem anzulegen und mit

Code: Alles auswählen

dd if=/media/[Einhängepunkt]/buster.img of=/dev/Gerätedatei

dann die Orignalplatte zu klonen. Bis dahin ließe sich diese Kopie/dieser Klon auch auf einer anderen Maschine durchführen - richtig? Und auf dieses /dev/Gerätedatei würde ich dann gpart loslassen. Einwände?

[Livingston]

Du kannst das Image auch in eine virtuelle Maschine klemmen und dort stressfrei rumtüfteln.

[fischig]

Ich betreibe keine VMs.

Also, die Image-Datei ist geschrieben. Ich schreibe jetzt dieses Image via grml-live auf einer anderen Maschine auf eine unpartitionierte Platte.

Code: Alles auswählen

dd bs=1M status=progress if=media[Einhängepunkt]/buster.img of=/dev/[Gerätedatei]

Macht das Sinn beim Verfolgen meines Ziels: auf diese Weise die ursprünglichen Partitionen und Daten wiederherstellen zu können?

[Livingston]

Damit hat du 1:1 die Daten rübergespült. Bis auf die Gesamtgröße der "neuen" Platte ist alles identisch.
Wenn es Dir also hier gelingt, die Partitionstabelle zu rekonstruieren, dann geht das mit den identischen Schritten auch auf dem Original.
Ich empfehle, das ganze jetzt mit testdisk/gpart mehrmals durchzuspielen (also in der Kopie rekonstruieren und wieder löschen), bis es sitzt.
Mach Notizen. kann man gar nicht genug von haben
Wenn Du meinst, es passt, dann kannst Du Dich ans Original wenden.

Mehr kaputtmachen geht nicht, Du hast ja noch das Image.
Viel Glück, ich drück Dir die Daumen.

[fischig]

So, Ich habe jetzt mit dd das Image auf eine leere Platte geschrieben. Obwohl die Größe der Platte identisch zu der des (versehentlich „geleerten“) Originals sein sollte (320GB), kam es zu einem Fehler.

Code: Alles auswählen

dd error writing '/dev/sdb': no space left on device
305245+1 records in
305245+0 records out
320072932864 bytes (320 GB, 298 GiB) copied, 10603.9 s, 30.2 MB/s

Kann ich den Fehler ignorieren?

gpart auf /dev/sdb losgelassen bringt:

Code: Alles auswählen

possible Partition (Linux swap): Size 3000mb, offset (1mb)
possible Partiton (Linux ext2): 302243mb offset (3002mb)
End scan.

Warning: Partition (Linux swap or Solaris/x86) starts beyond disk end.

Warning: Partition (Linux ext2 filesystem) starts beyond disk end.
Partition (Linux swap or Solaris/x86): invalid primary
Partition (Linux ext2 filesystem): invalid primary
...

Hinter den Auslassungszeichen verbergen sich dann noch vier „Guessed primary partition tables“ vom „type unused“, die ich hier ausgelassen habe abzutippen.

Ich sehe das erst mal so, dass die beiden „possible Partitions“ tatsächlich die sind, die im Original auch vorhanden waren. Größenmäßig sollte es passen, so meine Erinnerung.
Allerdings: Linux-Filesystem war nach meiner Erinnerung ext4, nicht ext2, und nicht gelistet wird die erweiterte Partition, in der das Linux-Dateisystem steckte.

Soll ich jetzt versuchen, via cfdisk die ursprüngliche Partitionierung (einschließlich der nicht gelisteten erweiterten Partition) neu anzulegen? Sind die Größenangaben von gpart dafür exakt genug?

Wenn das schief geht, muss ich vermutlich weitere 3 Stunden (10603.9 s, s.o.) zusehen, wie die Platte erneut von Image geschrieben wird.

[MSfree]

Obwohl die Größe der Platte identisch zu der des (versehentlich „geleerten“) Originals sein sollte (320GB), kam es zu einem Fehler.

Code: Alles auswählen

dd error writing '/dev/sdb': no space left on device

Dann war die Größe nicht identisch.
Es reicht ja schon, wenn die Platte nur einen Sektor (512 Bytes) weniger Platz bietet als das Image benötgt.Du kannst das Image aber immer auf eine größere Platte schreiben, du mußt nur aufpassen, daß du eine Platte nimmst, die 512Byte große physikalische Sektoren hat. Moderne Platten haben hier 4096Bytes, ältere Platten bis 750GB hatten auf jeden Fall noch 512Bytes Sektorgröße, einige ältere 1TB Platten ebenfalls. Das kann man aber leicht mit fdisk herausfinden.

Aber warum wurschtelst du überhaupt so rum? Du hast doch jetzt einen Imagedatei, die kann man doch direkt als Storagedevice im Kernel einbinden. Mit losetup läßt sich die Datei als Festplatte simulieren, auf die du dann auch testdisk und ähnliches loslassen kannst. Wenn du ganz sicher gehen willst, machst du von der Imagedatei halt noch eine Kopie, aber das Image kannst du ja auch jederzeit wieder von der Platte ziehen.

Letzten Endes würde ich ohnehin nur meine Daten von dem Image retten und dann auf der 320er-Platte neu installeiren, bzw. die uralte Platte entsorgen, weil deren Zuverlässigkeit mit den Jahren auch nicht besser wird.