USB Stick Clonen

Beitrag #8082333 wurde von einem Moderator gelöscht.
Beitrag #8082348 wurde von einem Moderator gelöscht.
(Firma: 1984now) #8082357
Lesenswert?

Jack V. schrieb:

Für Windows gab’s sowas wie den Win32DiskImager – da weiß ich allerdings mangels Windows nicht, wie es sich verhält, wenn das Dateisystem nicht erkannt wird.

Das Problem mit dem Diskimager ist: er kann gar nicht clonen. Man muss den Umweg über eine (temporäre) Image-Datei auf einem Laufwerk gehen.

Dateisysteme sind ihm übrigens unbekannt. Maximal (beim Lesen) kennt er Partitionen und kann seine Lesetätigkeit darauf basierend beschränken. Also nur insofern, dass halt nach dem Ende der am weitesten "hinten" liegenden Partition nicht mehr weiter gelesen wird.

#8082360
Lesenswert?

Ob S. schrieb:

Das Problem mit dem Diskimager ist: er kann gar nicht clonen. Man muss den Umweg über eine (temporäre) Image-Datei auf einem Laufwerk gehen.

Und? Es ist an dieser Stelle völlig unerheblich, ob das Image direkt auf den Zieldatenträger geschrieben wird, oder ob es zwischengespeichert wird – das Ergebnis wird genau dieselben Eigenschaften aufweisen.

Harald A. schrieb:

WSL kann - nach kurzer Dressur - selbst ein Schimpanse bedienen aber hey, wenn es denn unbedingt sein soll: Als sehr gutes Datenträger-Kopierprogramm habe ich Acronis kennengelernt, legale Keys ab ca. 15€ zu kaufen.

Lässt sich denn von WSL aus direkt auf Blockdevices zugreifen? Ich hab das bezüglich Hardwarezugriff eher als eingeschränkt in Erinnerung. Und Acronis erstellt bei „normaler“ Anwendung keinen Clone, und benötigt auch bekannte Dateisysteme. Gibt’s da eine Option zur bitgenauen Kopie?

: Bearbeitet durch User
Gast #8082409
Lesenswert?

Jack V. schrieb:

Rufus ist eigentlich nicht für bitgenaue Kopien gedacht. Einer kurzen Recherche kann’s das auch nicht – gibt’s da andere Informationen?

Rufus macht eine Imagedatei aus dem USB Stick (Rechts neben dem USB Stick das File Symbol klicken) und speichert die in einem VHD Format ab. Die Datei kann dann auch in einer virtuellen Maschine geladen werden.
Mit der VHD Datei kann dann ein zweiter USB Stick beschrieben werden.

Gast #8082433
Lesenswert?

Jack V. schrieb:

… und an der Stelle ist’s keine bitgenaue Kopie mehr, wie es aber die Definition von „Clone“ ist, oder?

Für das Kopieren von USB-Sticks mit "unbekanntem" Dateiformat hat das in der Vergangenheit funktioniert. Ob da der Bootsektor auch drauf ist weiss ich nicht.

#8082440
Lesenswert?

Michael B. schrieb:

wie kann ich einen USB Stick mit unbekannten Dateiformat, 1:1 klonen. Danke

Von PassMark Software (bekannt durch MemTest86) gibt es die Freeware ImageUSB. Die kann bitgenaue Kopien von USB-Sticks erstellen. Nachteil: Wenn dein USB-Stick 128 GB hat, dann hat deine Kopie ebenfalls 128 GB. :-) Ich benutze ImageUSB und ich hatte noch nie Probleme damit.

#8082583
Lesenswert?

Symantec/Norton Ghost existiert auch in einer unter Windows ohne Installation ausführbaren Version (ghost32.exe bzw. ghost64.exe).

Das stellt dann die uralte und krude DOS-Graphikoberfläche dar, die das vor über 30 Jahren schon existierende und damals unter DOS zu nutzende Programm anbot.

Dort jedenfalls gibt es die Funktion "copy disk to disk". Stellt man /vorher/ unter den Einstellungen das "forensische Kopieren" ein, wird ohne Berücksichtigung von Dateisystemen jeder Sektor kopiert.

Andererseits:

Es gibt auch ein dd für Windows, das man ohne WSL-Krücke verwenden kann. Man muss nur in der Lage sein, in der Kommandozeile ("Eingabeaufforderung" oder hipstercool "Terminal" genannt) Programme aufzurufen.

http://www.chrysocome.net/dd

#8082628
Lesenswert?

Diverse Tools werden für Windows benannt, von keinen weiß man ob es für diesen Fall richtig funktioniert. Für Unix ein Tool was es schon seit Jahrzehnten gibt und wahrscheinlich noch in Jahrzehnten geben wird.

Falls sich jemand fragt warum Windows immer weniger wird, hier ist die Antwort.

: Bearbeitet durch User
Gast #8082651
Lesenswert?

Peter M. schrieb:

Wie kann man mit Rufus Images von Datenträgern erzeugen?!^

Auf den rot umrandeten Button drücken und einen Dateinamen für das Image File auswählen. Ein vhdx ist ein komprimiertes Image, ein vhd ist ein unkomprimiertes Image mit Zusatz Info. Unter Auswahl kannst du das Image File dann wieder auswählen und auf einen anderen USB-Stick schreiben.

Angehängte Dateien:
#8082796
Lesenswert?

Harald A. schrieb:

WSL kann - nach kurzer Dressur - selbst ein Schimpanse bedienen aber hey, wenn es denn unbedingt sein soll: Als sehr gutes Datenträger-Kopierprogramm habe ich Acronis kennengelernt, legale Keys ab ca. 15€ zu kaufen.

Wenn Mann sich nicht aum Affen machen lassen will, Macrium Reflect ab Version 8 kann sowohl bitgenaue Kopien, Images, etc. pp. auch von USB-Sticks anfertigen.

Die wichtigste Zutat bei einem (Unix®-)dd ist übrigens eine angemessen grosse bs (Blocksize) und nicht der Progess. Ein Bekannter kopierte mal (DDS-)Bänder zwischen zwei Streamern, ohne eine vernünftige Blocksize. Das dauerte dann Tage. ☺

#8082811
Lesenswert?

Cartman E. schrieb:

Die wichtigste Zutat bei einem (Unix®-)dd ist übrigens eine angemessen grosse bs (Blocksize) und nicht der Progess. Ein Bekannter kopierte mal (DDS-)Bänder zwischen zwei Streamern, ohne eine vernünftige Blocksize. Das dauerte dann Tage.

Ja klar, mechanischer Start-Stop Betrieb.
USB Sticks stoppen und starten tendenziell eher seltener und bewegen sich nur ungern selbst. Da geht's auch ohne bs=. Obschon ich aber auch gerne bs=1M mitgebe.

1
# dd if=/dev/sdf of=/dev/null status=progress
2
784450048 Bytes (784 MB, 748 MiB) kopiert, 13 s, 60,3 MB/s^C
3
1638881+0 Datensätze ein
4
1638880+0 Datensätze aus
5
839106560 Bytes (839 MB, 800 MiB) kopiert, 13,962 s, 60,1 MB/s
#8082826
Lesenswert?

Norbert schrieb:

Cartman E. schrieb:

Das Weglassen der Blocksize

…zeigt das Wissen, wann es notwendig ist und wann nicht.

Nur /Leerdenker/ ignorieren Fakten.

Und außerdem die geistige Flexibilität nicht ständig seinen eigenen Erfahrungsbereich auf die ganze Welt abbilden zu wollen. ;-)

Die gibt es überall auf dieser Welt, und vermutliach auch in anderen Universen.

#8082833
Lesenswert?

Norbert schrieb:

Cartman E. schrieb:

Nur /Leerdenker/ ignorieren Fakten.

Bis jetzt ging's ja gerade noch. Jetzt kommt wieder nur belangloses Gesülze von dir.

Darauf solltest du flexibler reagieren.

Es hat keinen Sinn zu diskutieren, wenn man Fakten in Abrede stellt.

Es ist kein Fall bekannt, dass ein dd mit seiner Standardblocksize von 512, bei allgemenem Gebrauch schneller wäre.

#8082835
Lesenswert?

… so richtig Unrecht hat der Cartman allerdings nicht: Auch bei USB-Sticks hab zumindest ich ’ne messbar langsamere Geschwindigkeit, wenn ich bs weglasse. Allerdings ist das für den Job eh nicht meine erste Wahl, da nehme ich mittlerweile pv her: Um die richtigen Parameter muss ich mir da keine Sorgen machen, und ich hab ’nen schönen Fortschrittsbalken (ja: schöner, als die Ausgabe von dd status=progress). Ansonsten kann man auch cp oder cat oder was auch immer nehmen – aber das nutzt dem TE vermutlich so gar nichts, weil die Dinge für sein System in der Form nicht zur Verfügung stehen.

: Bearbeitet durch User
#8082836
Lesenswert?

Einmal ohne bs= und einmal mit bs=1M

Dass die von dir präferierte Methode mit bs= sogar geringfügig langsamer ist, bewegt sich noch im Rahmen der Messungenauigkeiten.

Da hast du deine Fakten. Und zwar Richtige!

1
root@Entwicklung:/home/norbert# dd if=/dev/sdf of=/dev/null status=progress
2
11384540160 Bytes (11 GB, 11 GiB) kopiert, 170 s, 67,0 MB/s^C
3
22354592+0 Datensätze ein
4
22354592+0 Datensätze aus
5
11445551104 Bytes (11 GB, 11 GiB) kopiert, 171,55 s, 66,7 MB/s
6

7
root@Entwicklung:/home/norbert# dd if=/dev/sdf of=/dev/null status=progress bs=1M
8
11400118272 Bytes (11 GB, 11 GiB) kopiert, 173 s, 65,9 MB/s^C
9
10924+0 Datensätze ein
10
10923+0 Datensätze aus
11
11453595648 Bytes (11 GB, 11 GiB) kopiert, 174,491 s, 65,6 MB/s
#8082840
Lesenswert?

Jack V. schrieb:

Auch bei USB-Sticks hab zumindest ich ’ne messbar langsamere Geschwindigkeit, wenn ich bs weglasse.

Ich benutze ja auch ständig bs=

Aber diese kategorische Aussage zur Geschwindigkeit ist einfach falsch. Es ist stark vom jeweiligen Device, der Pufferung und auch dem Anschluss abhängig. Wie man zweifelsfrei sehen kann.

Getestet mit sdf 28,6G Ultra_Fit an USB3 Anschluss.

: Bearbeitet durch User
#8082844
Lesenswert?

Norbert schrieb:

Wie man zweifelsfrei sehen kann.

Naja – mach’s mal andersrum. NAND-Flash ist seinerseits in Blöcke aufgeteilt, und wenn die Standard-Blocksize kleiner als die Größe der Blöcke des Sticks ist, dann gibt es deutlich geringere Geschwindigkeit, weil Blöcke mehrfach geschrieben werden.

Ich hab leider keinen freien USB-Stick zur Hand, um es nochmal zu testen – aber ich bin mir ziemlich sicher, dass es mich in einem solchen Szenario schon dazu gebracht hat, den Vorgang abzubrechen und mit größerer Blockgröße neu zu starten, weil’s so langsam ging.

: Bearbeitet durch User
#8082845
Lesenswert?

Norbert schrieb:

Einmal ohne bs= und einmal mit bs=1M

Dass die von dir präferierte Methode mit bs= sogar geringfügig langsamer ist, bewegt sich noch im Rahmen der Messungenauigkeiten.

Da hast du deine Fakten. Und zwar Richtige!

1
root@Entwicklung:/home/norbert# dd if=/dev/sdf of=/dev/null 
2
status=progress
3
11384540160 Bytes (11 GB, 11 GiB) kopiert, 170 s, 67,0 MB/s^C
4
22354592+0 Datensätze ein
5
22354592+0 Datensätze aus
6
11445551104 Bytes (11 GB, 11 GiB) kopiert, 171,55 s, 66,7 MB/s
7

8
root@Entwicklung:/home/norbert# dd if=/dev/sdf of=/dev/null 
9
status=progress bs=1M
10
11400118272 Bytes (11 GB, 11 GiB) kopiert, 173 s, 65,9 MB/s^C
11
10924+0 Datensätze ein
12
10923+0 Datensätze aus
13
11453595648 Bytes (11 GB, 11 GiB) kopiert, 174,491 s, 65,6 MB/s

(Hast du vorher auch artig den Cache invalidisiert?

Scheinbar ja.)

Meine flexible Antwort darauf, ist keine Antwort.

Ich bin auch ehrlich viel zu faul, überhaupt deine Messergebnisse angemessen zu würdigen. Ich werde selbst jetzt keine Laufzeitmessungen anstrengen. Die Urväter der C-Laufzeitbibliothek aber würden vermutlich auch schon rotieren.

Jeder darf sich so .... anstellen wie es ihm behagt.

Izmi Regal

#8082851
Lesenswert?

Cartman E. schrieb:

Das Weglassen der Blocksize, zeigt den gegenwärtigen geistigen Verfall an. ☺

Ein dd wird ohne angegebene,angemessen grosse, Blocksize immer langsamer sein, als mit. Dieser Fakt reicht mir schon.

Unter Linux gibt es keine raw-devices für Platten mehr:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=603e4922f1c81fc2ed3a87b4f91a8d3aafc7e093

Das geht alles über den Buffer-Cache, womit der Performance-Impact irgendwelcher Blocksizes marginal geworden ist.

#8082860
Lesenswert?

G. K. schrieb:

Cartman E. schrieb:

Das Weglassen der Blocksize, zeigt den gegenwärtigen geistigen Verfall an. ☺

Ein dd wird ohne angegebene,angemessen grosse, Blocksize immer langsamer sein, als mit. Dieser Fakt reicht mir schon.

Unter Linux gibt es keine raw-devices für Platten mehr:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=603e4922f1c81fc2ed3a87b4f91a8d3aafc7e093

Das geht alles über den Buffer-Cache, womit der Performance-Impact irgendwelcher Blocksizes marginal geworden ist.

Ob man das jetzt als "Errungenschaft" ansehen will, oder als Zeichen des um sich greifenden geistigen Verfalls?

Vermutlich ziehen die "Leerdenker" aus einem solchen Mechanismus den grössten Nutzen. Der Rest konnte das schon vorher, auch mit "Raw Devices".

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren