staging.inyokaproject.org

Hallo,

ich habe unter Lubuntu die Partitionsgrössen meiner Festplatte mit dem grafischen Tool GParted geändert und komme nun nicht mehr an meine Daten. Die Platte (ssd) hängt mittels USB-Adapter an einem anderen Lubuntu PC.

• Sdb1 swap 11GB unverändert

• Sdb2 ext4 war ca. 28GB, jetzt 38GB hier ist Lubuntu installiert, diese Partition wurde nach „hinten“ vergrößert

• Sdb3 ext4 war ca. 193GB, jetzt 183GB, diese Partition wurde „vorne“ verkleinert“ hier sind die Daten drauf (ca. 100GB), wird jetzt nicht mehr erkannt bzw. „unbekannt“

(s. auch Screenshot GParted)

1. Problem 1: Mein Hauptproblem – ich komme nicht an die Daten. Was kann ich tun, um wieder an meine Daten auf Sdb3 zu kommen? Ein Versuch mit Gparted ein Dateisystem zu finden/reparieren ist nach 20h erfolglos geendet (s. Screenshot).

2. Problem 2: Das ist nachrangig, was kann ich tun, um das Lubuntu von Sdb2 wieder booten zu können?

Ja, ich ärgere mich auch riesig, vorher keine Datensicherung gemacht zu haben – mein Fehler!

Vielen Dank schon mal vorab.

Grüße Jan

Das ist oft schwer bis gar nicht möglich, da man gar nicht genau weiß, was gparted da anstellt.

Bei deinem beschriebenen Vorgang, muss das sdb3-Dateisystem zuerst verkleinert worden sein. Dann muss es vom Ende her nach hinten verschoben worden sein. Erst dann kann der Startsektor von sdb3 entsprechend auf den größeren Wert gesetzt werden. Und erst dann ist Platz frei um sdb2 zu vergrößern.

Da du ein größeres sdb2 siehst muss also der Vorgang rund um sdb3 eigentlich abgeschlossen gewesen sein. Daß es dann trotzdem kaputt ist, das ist schon kurios ☺ aber es kommt bei gparted leider sehr oft vor, es gibt viele Threads dazu.

Um da jetzt zu evaluieren ob sich noch irgendwas machen lässt, müsste man sich die Daten genauer anschauen das ist aus der Ferne übers Forum, kaum möglich.

Du kannst blind photorec darüber laufen lassen, ob es dir noch kleine unfragmentierte Dateien heraus fischen kann.

Partitionen lassen sich per testdisk suchen, aber gerade beim Verschieben ergibt das auch false matches da eben noch alte Header an den alten Offsets überlebt haben können. Und dann wird ggf. das neue Offset nicht gefunden. testdisk geht eben vom Standardfall der gelöschten Partitionstabelle aus. Falls du den Quick Search benutzt hast, der reicht da ggf. nicht.

Dann kommt dann noch das Problem dazu, es gibt fstrim, das wirft den gesamten freien Speicher eines Dateisystems weg, wenn du sdb2 gemountet hast dann ist alles wo das evtl. ins sdb3 reingeschrieben hat, dann erst recht weg. Das passiert auch bei Dateisystem-Images/Loop-Devices, nicht nur bei SSD.

Bei Datenrettung ist also immer 1) fstrim/discard abschalten, 2) komplettes Image ziehen, 3) erst auf einer weiteren Kopie davon experimentieren.

Am Ende sind die Erfolgschancen relativ gering. Ohne Backups kommt man da nicht weiter.

Hi frostschutz,

Das ist oft schwer bis gar nicht möglich, da man gar nicht genau weiß, was gparted da anstellt.

Könnte man denn hoffen, dass, was auch immer es da tut, auch umgekehrt wieder tut? Oder wäre die Hoffnung völlig vergebens? Also auch mit gparted (auf der Kopie!) alles so zurück verschieben wie es zuvor war? Oder verhaut es einem immer das Alignment irgendwo?

Mich irritieren allerdings die 138 MiB in der Mitte, warum sind sie da, woher kommen sie und wo waren sie vorher?

Viel Erfolg...

4JimBeam schrieb:

[…] Partitionsgrössen […] mit dem grafischen Tool GParted geändert […] ssd […]

Solche Verschiebungen sind äußerst gefährlich, wenn sich Ursprungs- und Zielbereich überlappen. Es geht entweder gut oder man erfährt einen Totalverlust.

• Sdb2 ext4 war ca. 28GB, jetzt 38GB hier ist Lubuntu installiert, diese Partition wurde nach „hinten“ vergrößert

Das ist ungefährlich, sofern der neue Bereich am Ende wirklich frei (im Sinne: darf überschrieben werden) ist.

• Sdb3 ext4 war ca. 193GB, jetzt 183GB, diese Partition wurde „vorne“ verkleinert“ hier sind die Daten drauf (ca. 100GB), wird jetzt nicht mehr erkannt bzw. „unbekannt“

Das ist gefährlich, weil jeder Block im Zielbereich überschrieben wird. Es ist besser, so etwas nicht zu machen, schon gar nicht bei SSD und auch nicht bei magnetischen Platten mit SMR-Aufzeichnung. Alternative: Kopieren A → B, dann B → A', wobei A und B sowie B und A' sich jeweils nicht überlappen.

[…] was kann ich tun, um das Lubuntu von Sdb2 wieder booten zu können?

Das sollte nach wie vor problemlos möglich sein, sofern die kaputte Partition sdb3 beim Hochlauf nicht eingebunden wird. Das erfordert u.U. eine Änderung der Datei /etc/fstab im Dateisystem in der Partition sdb2.

san04 schrieb:

Also auch mit gparted (auf der Kopie!) alles so zurück verschieben wie es zuvor war?

Nein, mit so Aktionen machst du es eher nur noch schlimmer. Das Verkleinern/Verschieben/Vergrößern ist auch kein Vorgang, der sich rückgängig machen lässt. Es wird ja auch sektorweise alles dabei überschrieben. Da gibt es kein Zurück bei dem dann alte Daten wieder zum Vorschein kommen... was weg ist das ist weg. Chancen hast du hier nur wenn es ein trivialer Fehler ist... oder du sehr gut verstehst wie gparted intern vorgeht und wie die Daten dementsprechend gelagert sein müssen oder was der Fehler sein kann.

Im einfachsten Fall ist nur das Partitionsoffset falsch, im schlechteren Fall wurde das Verschieben irgendwo unterbrochen und die Partition liegt nun in zwei Teilhälften oder sonst einem undefinierten Zustand vor, im schlimmsten Fall ist es halt komplett Banane.

Falsches Verschieben kann eben auch zu kompletter Datenkorruption führen.

Danke für den Hinweis 👍

Also funktioniert zurück verschieben nur, wenn der erste Kopiervorgang erfolgreich abgschlossen wurde... Aber dann hätte 4JimBeam ja auch gar kein Problem gehabt ☹

Hallo 4JimBeam,

willkommen hier im Forum! ☺

Wenn die Originalplatte wirklich noch eine mechanische Festplatte ist, hast Du ggf. noch eine Chance zur Rettung einiger Daten mit den Programmen testdisk/photorec.

Am besten von einem Live-System starten und vorher eine ausreichend große SSD für die Sicherung einhängen bei testdisk.

Grüße

schollsky