(gelöst) GAU: mit gparted die zu sichernde Platte „geleert“
-
- Beiträge: 3721
- Registriert: 24.12.2019 12:25:08
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: z.Z. Palermo
(gelöst) GAU: mit gparted die zu sichernde Platte „geleert“
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?
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?
Zuletzt geändert von fischig am 30.10.2021 16:19:24, insgesamt 2-mal geändert.
Re: GAU
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!
Use ed once in a while!
-
- Beiträge: 3721
- Registriert: 24.12.2019 12:25:08
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: z.Z. Palermo
Re: GAU: mit gparted die zu sichernde Platte „geleert“
Wird wohl weg sein, zumindest weiß ich nicht, wo/wie ich die finden könnte.Meillo hat geschrieben:Falls du noch eine Anzeige der Partitonstabelle hast, dann fotografiere/kopiere diese!
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.
Keine Ahnung, wie das zu machen wäre.Meillo hat geschrieben:Erstmal den aktuellen Zustand sichern
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.
Re: GAU: mit gparted die zu sichernde Platte „geleert“
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.
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.
Use ed once in a while!
-
- Beiträge: 3721
- Registriert: 24.12.2019 12:25:08
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: z.Z. Palermo
Re: GAU: mit gparted die zu sichernde Platte „geleert“
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“?
Re: GAU: mit gparted die zu sichernde Platte „geleert“
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...ohne die versehentlich geleerte Platte weiter zu „beschädigen“?
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
-- nichts bewegt Sie wie ein GNU --
Re: GAU
testdisk kann auch Partitionen suchen, wie schon geschrieben aber auf jeden Fall ein Image machen und daran üben...fischig hat geschrieben:27.10.2021 12:16:37Ja, 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.
Gruß
slu
Das Server Reinheitsgebot:
Debian Bookworm, sonst nichts.
Stolzer Gewinner der Jessie Release Wette:
https://wiki.debianforum.de/Jessie_Release_Wette#SIEGER
slu
Das Server Reinheitsgebot:
Debian Bookworm, sonst nichts.
Stolzer Gewinner der Jessie Release Wette:
https://wiki.debianforum.de/Jessie_Release_Wette#SIEGER
Re: GAU: mit gparted die zu sichernde Platte „geleert“
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.
Re: GAU: mit gparted die zu sichernde Platte „geleert“
Btw: Bei dd eine ordentliche Blockgroesse angeben, sonst dauert es ewig.
Use ed once in a while!
-
- Beiträge: 3721
- Registriert: 24.12.2019 12:25:08
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: z.Z. Palermo
Re: GAU: mit gparted die zu sichernde Platte „geleert“
Ging mir auch schon durch den Kopf. Welche? (Ich habe das zwar im Hinterkopf, aber als Laie mache ich das zu selten).Btw: Bei dd eine ordentliche Blockgroesse angeben, sonst dauert es ewig.
edit:
bs=1M, richtig?
-
- Beiträge: 3721
- Registriert: 24.12.2019 12:25:08
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: z.Z. Palermo
Re: GAU: mit gparted die zu sichernde Platte „geleert“
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?
-
- Beiträge: 3721
- Registriert: 24.12.2019 12:25:08
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: z.Z. Palermo
Re: GAU: mit gparted die zu sichernde Platte „geleert“
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.
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.
Re: GAU: mit gparted die zu sichernde Platte „geleert“
Wenn Du ein Image hast probiere was die besser gefällt, funktioniert es nicht kannst Du immer noch das nächste probieren...
Gruß
slu
Das Server Reinheitsgebot:
Debian Bookworm, sonst nichts.
Stolzer Gewinner der Jessie Release Wette:
https://wiki.debianforum.de/Jessie_Release_Wette#SIEGER
slu
Das Server Reinheitsgebot:
Debian Bookworm, sonst nichts.
Stolzer Gewinner der Jessie Release Wette:
https://wiki.debianforum.de/Jessie_Release_Wette#SIEGER
Re: GAU: mit gparted die zu sichernde Platte „geleert“
Aber moeglichst auf einer *Kopie* des Images, weil sonst muesstest du es ja neu erstellen.
Use ed once in a while!
-
- Beiträge: 3721
- Registriert: 24.12.2019 12:25:08
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: z.Z. Palermo
Re: GAU: mit gparted die zu sichernde Platte „geleert“
Nun, das kann noch heiter werden:
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
Code: Alles auswählen
dd bs=1M if=/dev/sda of=/media/[Einhängepunkt]/buster.img
edit: code-tags ergänzt
Zuletzt geändert von fischig am 27.10.2021 18:50:38, insgesamt 1-mal geändert.
Re: GAU: mit gparted die zu sichernde Platte „geleert“
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.fischig hat geschrieben:27.10.2021 18:07:45Nun, 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?
Was die Partitionstabelle angeht:
Zeig mal die Ausgabe von:
Code: Alles auswählen
fdisk -l /dev/sda
-
- Beiträge: 3721
- Registriert: 24.12.2019 12:25:08
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: z.Z. Palermo
Re: GAU: mit gparted die zu sichernde Platte „geleert“
Keine Partitionstabelle mehr gefunden mit 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 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?
Code: Alles auswählen
fdisk -l /dev/sda
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
- Livingston
- Beiträge: 1557
- Registriert: 04.02.2007 22:52:25
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: 127.0.0.1
Re: GAU: mit gparted die zu sichernde Platte „geleert“
Du kannst das Image auch in eine virtuelle Maschine klemmen und dort stressfrei rumtüfteln.
Der Hauptunterschied zwischen etwas, was möglicherweise kaputtgehen könnte und etwas, was unmöglich kaputtgehen kann, besteht darin, dass sich bei allem, was unmöglich kaputtgehen kann, falls es doch kaputtgeht, normalerweise herausstellt, dass es unmöglich zerlegt oder repariert werden kann.
Douglas Adams
Douglas Adams
-
- Beiträge: 3721
- Registriert: 24.12.2019 12:25:08
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: z.Z. Palermo
Re: GAU: mit gparted die zu sichernde Platte „geleert“
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. Macht das Sinn beim Verfolgen meines Ziels: auf diese Weise die ursprünglichen Partitionen und Daten wiederherstellen zu können?
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]
- Livingston
- Beiträge: 1557
- Registriert: 04.02.2007 22:52:25
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: 127.0.0.1
Re: GAU: mit gparted die zu sichernde Platte „geleert“
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.
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.
Der Hauptunterschied zwischen etwas, was möglicherweise kaputtgehen könnte und etwas, was unmöglich kaputtgehen kann, besteht darin, dass sich bei allem, was unmöglich kaputtgehen kann, falls es doch kaputtgeht, normalerweise herausstellt, dass es unmöglich zerlegt oder repariert werden kann.
Douglas Adams
Douglas Adams
-
- Beiträge: 3721
- Registriert: 24.12.2019 12:25:08
- Lizenz eigener Beiträge: MIT Lizenz
- Wohnort: z.Z. Palermo
Re: GAU: mit gparted die zu sichernde Platte „geleert“
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.
Kann ich den Fehler ignorieren?
gpart auf /dev/sdb losgelassen bringt:
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.
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
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
...
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.
Re: GAU: mit gparted die zu sichernde Platte „geleert“
Dann war die Größe nicht identisch.fischig hat geschrieben:28.10.2021 08:59:39Obwohl 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
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.