ubuntuusers.de

tigram schrieb:

/dev/sda = LIVE-USB, ich denke für das Klonen ist es sicherer diesen zu verwenden; /dev/sdb = der 256GB Quellstick, der geklont werden soll; /dev/sdc = 2 TB externe SSD als Ziel.

1. Muss für das Klonen des gesamten USB-Sticks nur der Quellstick /dev/sdb ausgehängt werden (das steht gleich im roten Kasten bei der Einleitung) oder muss auch die Ziel-SSD /dev/sdc ausgehängt werden?

Beide ausgehängt, ist zu empfehlen.

lsblk

ob nichts bei sdb und sdc bei MOUNTPOINTS steht, sonst wie du geschrieben hast.

sudo umount /dev/sdb
sudo umount /dev/sdc

Stelle sicher, dass du wirklich im Live- System bist.

sudo dd if=/dev/sdX of=/dev/sdY bs=4M status=progress conv=fdatasync 

steht hier: dd (Abschnitt „Optionen“)

Im Wiki (https://wiki.ubuntuusers.de/dd/#Festplatte-klonen) steht: Standardmäßig wird mit 512 Bytes gelesen, bei defekten Blöcken wäre ein "bs=4K" zu empfehlen.

Richtig.

...(Das steht im Abschnitt https://wiki.ubuntuusers.de/dd/#Live-USB-Stick-erstellen nicht...

Warum auch, denn dieser Abschnitt hat nichts mit deiner Sache zu tun, denn hier wird eine ISO-Datei auf einen USB-Stick kopiert.

sudo dd if=NAME_ISO-ABBBILD of=/dev/sdX bs=4M status=progress conv=fdatasync 

Aber da du ja deine Quellplatte schon "bearbeitet" hast, ist zu bezeifeln, ob die Zielplatte überhaupt die gewünschten Aufgabe erledigen kann. Aber das wurde dir ja schon mehrmals geschrieben.

Aber da du ja deine Quellplatte schon "bearbeitet" hast, ist zu bezeifeln, ob die Zielplatte überhaupt die gewünschten Aufgabe erledigen kann. Aber das wurde dir ja schon mehrmals geschrieben.

Ich denke, das ist in der Situation, in der ich nun mal bin, noch immer das Beste. Das Backup der Partitionstabelle hat die Ausgangslage immerhin verbessert, der 256GB Stick wird jetzt im Explorer erkannt und angezeigt.

Danke für die genaue Anleitung. Das Klonen hat wie vorhergesagt ca. 15 Minuten gedauert.

lubuntu@lubuntu:~$ sudo dd if=/dev/sdb of=/dev/sdc bs=4M status=progress conv=fdatasync
255852544000 bytes (256 GB, 238 GiB) copied, 657.085 s, 389 MB/s
61056+0 records in
61056+0 records out
256087425024 bytes (256 GB, 239 GiB) copied, 659.053 s, 389 MB/s
lubuntu@lubuntu:~$ 

Ich denke es ist das Beste, wenn ich jetzt mit dem 2TB Klon weiterarbeite, dann kann ich wenn nötig den 256GB-Stick nochmal klonen, oder ?

Wenn ich nun mit dem Klon die Partitionen abfrage, bekomme ich folgende Warnung:

sudo parted -l
[sudo: authenticate] Passwort:       
Modell: SanDisk Extreme Pro (scsi)
Festplatte  /dev/sda:  128GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: gpt
Disk-Flags: 

Nummer  Anfang  Ende   Größe  Dateisystem  Name          Flags
 1      2097kB  317MB  315MB  fat32                      boot, esp
 2      317MB   128GB  128GB  ext4         lubuntu_2604


Warnung: Nicht der gesamte verfügbare Platz von /dev/sdb scheint belegt zu sein.
Sie können die GPT reparieren, damit der gesamte Platz verwendet wird
(zusätzlich 3406792865 Blöcke) oder Sie können mit den aktuellen Einstellungen
fortfahren. 
Reparieren/Fix/Ignorieren/Ignore? i                                       
parted: Unbekanntes Zeichen: i
Reparieren/Fix/Ignorieren/Ignore? I                                       
parted: Unbekanntes Zeichen: I
Reparieren/Fix/Ignorieren/Ignore? ^C                                      
Modell: SanDisk Extreme 55AE (scsi)
Festplatte  /dev/sdb:  2000GB
Sektorgröße (logisch/physisch): 512B/512B
Partitionstabelle: gpt
Disk-Flags: 

Nummer  Anfang  Ende    Größe   Dateisystem  Name               Flags
 1      2097kB  317MB   315MB                ef00               boot, esp
 2      317MB   31,8GB  31,5GB  ext4         Root-SD_Pro_256GB

...

Warum konnte ich diese Warnung weder mit i (klein geschrieben) noch mit I (groß geschrieben) ignorieren? Macht es Sinn, sie zu fixieren? Und wie gebe ich Antwort auf diese Frage?

Aber zuvor, vor dem einhängen des Dateisystems, die Fehler mit fsck beheben lasen.

Ist das dann so richtig?

sudo umount /dev/sdb
sudo fsck -y /dev/sdb1

Bereinigen...kann freilich auch heißen, es reißt alles den Orkus 'runter. Bleibt Dir was anderes als der Versuch? ... Laß den Reparaturversuch alles schrotten!

Was kann im schlimmsten Fall passieren, wenn der Reperaturversuch mit fsck schief geht? Ich nehme an, dass die Daten dann nicht mehr gerettet werden können. Aber kann auch der ganze Klon, die 2TB SSD ganz zerstört und unbrauchbar werden, sodass sie nicht mehr formatiert und für andere Zwecke verwendet werden kann?

Oder ist zunächst sinnvoll:

sudo umount /dev/sdb
sudo fsck -N /dev/sdb1

oder ... ?

Kann das Programm dmde für meine Datenrettung auch hilfreich sein?

ALso: Deine Ausgangssituation besteht in einem Datenträger A mit defekter GPT-Partitionstabelle, genauer: Der primäre Teil am Anfang des Datenträger ist defekt. Das könnte mit dem Programm gdisk repariert werden, indem aus dem am Ende des Datenträgers stehenden Backup-Teil die Daten kopiert würden.

Du willst vorher den Datenträger A auf K klonen. Dabei ist zu beachten:

• #A > #K: Geht gar nicht.

• #A = #K: Das wäre die optimale Situation.

• #A < #K: Das ist Deine Situation und erzeugt einen Klon mit doppelt defekter Partitionstabelle:

  • Der Teil am Anfang war ursprünglich bereits defekt und wurde genau so kopiert.

  • Der Teil am Ende von A steht auf K nicht am Ende. Aus das könnte mit gdisk repariert werden, indem die Daten aus dem primären Teil in einen neuen Backup-Teil am Ende von K kopiert würden, was wiederum bei Dir nicht sinnvoll ist, weil diese Daten ja korrumpiert sind.

Ich fürchte, dieser Klon ist für gar nichts gut.

A > K: Geht gar nicht.

Darauf bin auch ich beim Erstellen einer Kopie mit dd der sd Karte eines Raspi gestoßen.

Heißt das, auch dass man sich das Klonen eines Datenträgers in diesem Fall sparen kann?

kB schrieb:

• #A < #K: Das ist Deine Situation und erzeugt einen Klon mit doppelt defekter Partitionstabelle:

  • Der Teil am Anfang war ursprünglich bereits defekt und wurde genau so kopiert.

  • Der Teil am Ende von A steht auf K nicht am Ende. Aus das könnte mit gdisk repariert werden, indem die Daten aus dem primären Teil in einen neuen Backup-Teil am Ende von K kopiert würden, was wiederum bei Dir nicht sinnvoll ist, weil diese Daten ja korrumpiert sind.

Ich fürchte, dieser Klon ist für gar nichts gut.

Ich habe mal anhand des Befehls "lsblk -bl" , der hier in der Diskussion genannt wurde, bei meinen Datenträgern nachgeschaut:

sda         8:0    0  500107862016  0 disk  
sdc         8:32   0  500107861504  0 disk 

Ich bitte um Verständnis wenn ich hier nicht von prompt zu prompt zeige, aber ich weiß inzwischen, wie wichtig das ist.

2 gleich große Datenträger zu finden, scheint schwierig zu sein.

Deswegen klont man auch Datenträger in eine Imagedatei.

weholei schrieb:

A > K: Geht gar nicht.

Darauf bin auch ich beim Erstellen einer Kopie mit dd der sd Karte eines Raspi gestoßen.

Es ergibt sich bereits aus den Begriffen „größer“ und „kleiner“ im Endlichen.

Heißt das, auch dass man sich das Klonen eines Datenträgers in diesem Fall sparen kann?

Nein, es bedeutet, dass ein Klonen unmöglich ist, weil die Voraussetzungen dafür nicht erfüllt sind: Das Größere passt im Endlichen nicht in das Kleinere. (Im Unendlichen ist das anders, aber unendliche Datenträger spielen in der real existierenden EDV keine Rolle.)

Dieser Umstand gehört üblicherweise in den Bereich des gesunden Menschenverstandes, und wer darüber verfügt, kann sich in dieser Situation auch jeden Versuch eines Klonens sparen.

Deswegen klont man auch Datenträger in eine Imagedatei.

Danke, das wollte ich wissen.

Offenbar war es den TE auch nicht klar.

A = K: Das wäre die optimale Situation.

A < K: Das ist Deine Situation und erzeugt einen Klon mit doppelt defekter Partitionstabelle:

Ich dachte bisher, es ist nur wichtig, dass der Klon Datenträger zumindest gleichgroß ist. Dass der Klon natürlich auch die Fehler wie das Original hat ist mir klar, aber dass es Schwierigkeiten gibt weil der Klon größer ist, hat mich überrascht, ich hatte es aus den Beiträgen nicht herausgelesen.

Deswegen klont man auch Datenträger in eine Imagedatei.

Kann das Klonen in eine Imagedatei für meine Situation hilfreich sein?

... oder bleibt nur der Reperaturversuch mit allen Risiken direkt am 256GB USB-Stick?

Es wurde dir nun schon mehrfach gesagt.

Du hast schon dran rumgefummelt. Jetzt noch zu klonen ist absolut sinnlos.

Normal geht man so vor:

• als allererstes klonen bevor man irgendetwas dran macht

• NUR am Klon wird rumgefummelt

>> Datenrettung <<

Normal geht man so vor:

• als allererstes klonen bevor man irgendetwas dran macht

• NUR am Klon wird rumgefummelt

Danke, das merke ich mir für die Zukunft.

Die IST-Situation:

Du hast schon dran rumgefummelt. Jetzt noch zu klonen ist absolut sinnlos.

Dann will ich die Reperatur mit fsck am 257GB-USB Stick /dev/sdb versuchen: Ist es sinnvoll, mit dem ausgehängen Stick zuerste einen Probelauf zu machen?

sudo fsck -N /dev/sdb2

Wie viel Zeit muss ich für den Probelauf bzw. die automatische Reperatur mit fsck einplanen?

Oder gibt es noch einen anderen Vorschlag?

tigram schrieb:

... mit dem ausgehängen Stick zuerste einen Probelauf zu machen?

Bitte schreibe mal jeden deiner geplanten Schritte der Reihe nach auf, denn es überhaupt nicht klar, was du überhaupt machen willst.

ich würde mich auch freuen, wenn du weiterhin über Deine Schritte berichtest.

Ich kann daraus einiges lernen, z.B, ein Rettungs Backup nur als Image zu erstellen.

Dass bei mir das direkte Klonen einer 500 GB SSD geklappt hat, war ev. nur Zufall