SSD mit Linux klonen

Muss es denn „klonen“ sein? Das wäre recht umständlich, weil man im 
Anschluss die Partition(en) und das/die Dateisystem(e) entsprechend 
vergrößern müsste, und sich auch um die UUIDs und Labels kümmern sollte, 
um da keine zweideutigen Zuordnungen zu haben.

Der „normale“ Weg wäre schlicht das Kopieren der Daten, damit würde man 
sich das ganze Gehampel ersparen.

"Klonen" ist hier der falsche Ansatz.
Daran versteht man landläufig das Anfertigen eines Images (z.B. mittels 
dd). Aber dann hast du Ärger mit der Partitionstabelle, du möchtest ja 
auf der neuen SSD eine größere Partition haben.

Ich würde die Daten einfach nur kopieren, rsync mit entsprechenden 
Optionen, als root ausgeführt, kopiert dir die Dateien 1:1 und unter 
Berücksichtigung von Links usw.

Wenn es sich um die Systempartition handelt: den Kopiervorgang am Besten 
von einem Live-Stick aus Starten.
Nicht vergessen die /etc/fstab anzupassen.

Bernd schrieb:
> Vielleicht sollte ich noch erwähnen […]

Vielleicht solltest du mal gleich allen Informationen auf den Tisch 
packen? Das Salamispiel ist nicht mehr so geschätzt, heutzutage.

Wie auch immer – um ein bootbares Windows zu bekommen, wird das Klonen 
der betreffenden Partition(en) nicht ausreichen.

Boote das Windows und starte dort das der neuen SSD 
beiliegende/herunterladbare Tool des Herstellers zum klonen.

oszi40 schrieb:
> Mit einfachen kopieren änderst Du alle möglichen Dateieigenschaften!

Wäre halt bei der Ausgangsfrage vollkommen irrelevant, zumal man die 
Attribute auch mitkopieren kann. Dass es um Windows geht, das dann im 
Anschluss bitte auch noch bootfähig sein soll – die Salamischeibe kam ja 
erst später. Da wird’s mit dem Kopieren halt nichts, mit dem reinen 
Klonen allerdings auch nicht.

Zeno schrieb:
> Mit Windows funktioniert das Klonen schon

Interessant. Bei mir nämlich nicht, jedenfalls nicht so, dass ein 
bootbares System rauskam – versucht hatte ich es mit XP, 7 und 10. Die 
Image-Tools, die du ansprichst, klonen hingegen nicht (nur), sondern 
machen noch weiteren Kram.

Wie auch immer – die Salamischeiben „welche Windowsversion“ und „BIOS 
oder UEFI-Firmware“ fehlen beispielsweise auch noch immer. Meinem 
Wunsch, die ganze Wurst serviert zu bekommen, wurde ja leider nicht 
entsprochen.

oszi40 schrieb:
> Jack V. schrieb:
>> Der „normale“ Weg wäre schlicht das Kopieren der Daten, damit würde man
>> sich das ganze Gehampel ersparen.
>
> Mit einfachen kopieren änderst Du alle möglichen Dateieigenschaften!

...die in 99,999% der Fälle ohnehin irrelevant sind. Aber wenn es Dir 
gar so wichtig ist: man 1 cp/--preserve

M.M.M schrieb:
> Warum nicht?

Weil Windows dann schlicht nicht sauber startet. Zumindest bei meinen 
Versuchen, siehe oben. YMMV

Jack V. schrieb:
> Wie auch immer – um ein bootbares Windows zu bekommen, wird das Klonen
> der betreffenden Partition(en) nicht ausreichen.

Beim Umstieg von einer 500er-SSD auf eine 1000er-SSD hab ich genau das 
(Klonen via Clonezilla) gemacht und sowohl Linux als auch das Win7 waren 
danach bootbar. Als Backup mach ich das ganze auch regelmäßig auf HDD, 
funktioniert auch.

Das Vergrößern der Linux-Partition ging dann aus dem laufenden Linux 
heraus via gparted, aber hier hatte ich auch Glück, das die 
Linux-Partition am "Ende" der alten SSD lag.

Reinhard S. schrieb:
> Beim Umstieg von einer 500er-SSD auf eine 1000er-SSD hab ich genau das
> (Klonen via Clonezilla) gemacht

Hast du eben nicht, weil Clonezilla entgegen seines Namens nicht 
zwangsweise (nur) klont ;)

Eine „echte“ bitgenaue Kopie ließe sich via etwa ›dd‹ erstellen, und 
damit kopierte Windowssysteme in verschiedenen Versionen kamen bei mir 
reproduzierbar nicht aus eigener Kraft hoch. Zumindest bei Win7 hat’s 
aber gereicht, den Installationsdatenträger zu booten, auf „Reparieren 
einer vorhandenen Installation“ (o.Ä.) zu klicken und etwa eine halbe 
Stunde zu rätseln, was es da wohl gerade macht, und ob es überhaupt noch 
was macht.

Jack V. schrieb:
> Reinhard S. schrieb:
>> Beim Umstieg von einer 500er-SSD auf eine 1000er-SSD hab ich genau das
>> (Klonen via Clonezilla) gemacht
>
> Hast du eben nicht, weil Clonezilla entgegen seines Namens nicht
> zwangsweise (nur) klont ;)

Es klont das Dateisystem. Dazu müssen Sektoren, die vom Dateisystem 
gerade nicht genutzt werden, auch nicht mit kopiert werden.

> Eine „echte“ bitgenaue Kopie ließe sich via etwa ›dd‹ erstellen, und
> damit kopierte Windowssysteme in verschiedenen Versionen kamen bei mir
> reproduzierbar nicht aus eigener Kraft hoch.

Ich hab da schon unterschiedliches erlebt, aber meistens ging es. 
Allerdings ist es schon eine Weile her, dass ich das das letzte mal 
gemacht habe.

Norbert schrieb:
> wieso sollte dann bitte diese bitgenaue Kopie nicht
> funktionieren? Oder nicht booten?

Möglicherweise, weil MS die Lizenz z.T. an die Hardware gebunden hat, 
und ein Laufwerkswechsel da einige Punkte zugibt? Oder weil deren 
Bootloader hardwarespezifische Kennungen vom Laufwerk nimmt, und ihm die 
neuen mitgeteilt werden müssten? Ich bin kein nativer Windowsuser, bei 
mir ist das nur zum Starten von Spielen da → ich hab da keine Ahnung 
von, und kann diesbezüglich auch nur raten.

Ich weiß nur, dass meine Versuche nicht auf Anhieb gebootet hatten. Bei 
Win7 hat’s, wie geschrieben, das „vorhandene Installation reparieren“ 
(o.Ä.) behoben, bei Win10 hab ich mich nicht weiter drum gekümmert und 
das Ding schlicht neu installiert, nachdem es nicht direkt starten 
wollte.

Norbert schrieb:
> Wenn ›dd‹ eine bitgenaue Kopie einer kompletten Festplatte/SSD erstellt
> - und ›dd‹ macht genau DAS und zwar hervorragend um nicht zu sagen
> herausbaumelnd - wieso sollte dann bitte diese bitgenaue Kopie nicht
> funktionieren? Oder nicht booten?

Gute Frage. Andere Festplattengröße? Andere Seriennummer? Andere 
Sektorgröße (512 Bytes vs. 4k)?

Jack V. schrieb:
> Möglicherweise, weil MS die Lizenz z.T. an die Hardware gebunden hat,
> und ein Laufwerkswechsel da einige Punkte zugibt?

Das sollte allerdings meines Wissens eigentlich nicht das Booten 
verhindern sondern höchstens dazu führen, dass die Aktivierung ungültig 
wird und deshalb erneuert werden muss.

> Oder weil deren Bootloader hardwarespezifische Kennungen vom Laufwerk
> nimmt, und ihm die neuen mitgeteilt werden müssten?

Sowas ist mir mal bei einem Suse Linux über den Weg gelaufen. Da waren 
in der fstab die Filesysteme über die Seriennummer der Festplatte 
referenziert.

Norbert schrieb:
> /dev/xxx geht aber immer noch genauso gut.

Systemabhängig. Bei nur einer Disk ist die Nummerierung sehr 
zuverlässig. Darüber... ;-)

Bei meinem Serverlein hängt die Bootdisk an einem anderen SATA 
Controller als die 4 Datendisks. Der Diskscan dieser Controller erfolgt 
offenbar parallel und das Ergebnis hängt vom Hashwert der Uhrzeit oder 
der Entfernung von Artemis oder was auch immer ab. Zwei 
aufeinanderfolgende Systemstarts:

1

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT

2

sda      8:0    0   3,6T  0 disk 

3

sdb      8:16   0   3,6T  0 disk 

4

sdc      8:32   0   3,6T  0 disk /work

5

sdd      8:48   0   1,4T  0 disk 

6

└─sdd1   8:49   0   1,4T  0 part /archiv

7

sde      8:64   0 238,5G  0 disk 

8

├─sde1   8:65   0 235,5G  0 part /

9

├─sde2   8:66   0     1K  0 part 

10

└─sde5   8:69   0     3G  0 part [SWAP]

11

sdf      8:80   0   7,3T  0 disk 

12

└─sdf1   8:81   0   7,3T  0 part

1

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT

2

sda      8:0    0 238.5G  0 disk 

3

├─sda1   8:1    0 235.5G  0 part /

4

├─sda2   8:2    0     1K  0 part 

5

└─sda5   8:5    0     3G  0 part [SWAP]

6

sdb      8:16   0   3.6T  0 disk 

7

sdc      8:32   0   3.6T  0 disk 

8

sdd      8:48   0   3.6T  0 disk /work

9

sde      8:64   0   1.4T  0 disk 

10

└─sde1   8:65   0   1.4T  0 part /archiv

11

sdf      8:80   0   7.3T  0 disk 

12

└─sdf1   8:81   0   7.3T  0 part

Norbert schrieb:
> Und die UUID wird aus Zeit,Zufall,… gebildet. Nicht aus der Drive-ID.
> Und selbst wenn, dann würde die UUID mit kopiert werden und einen
> Bootvorgang nicht verhindern.

Ja, die UUID ist eine Eigenschaft des Dateisystems, nicht der Festplatte 
selbst, daher wird sie einfach mit kopiert. Man kann aber auch die 
Seriennummer der Festplatte nutzen, die dann natürlich nicht mit kopiert 
wird. Die entsprechenden Links findet man z.B. unter /dev/disk/by-id, im 
Gegensatz zu /dev/disk/by-uuid.

Norbert schrieb:
> Das Phänomen ist mir durchaus bekannt. Aus dem gleichen Grund hat man ja
> auch angefangen zB. die Netzwerk-Schnittstellen umzubenennen.

Bei denen gibt's dafür aber eigentlich schon die persistent-net-rules, 
die dafür sorgen, dass ein einmal gefundenes Netzwerkgerät immer den 
selben Namen trägt (gekoppelt über dessen MAC-Adresse). Warum die Namen 
jetzt so kryptisch sein müssen statt einfach sowas wie eth0, hab ich 
noch nicht verstanden.

Norbert schrieb:

Da hätte ich doch gerne mal eine Frage.

Wenn ›dd‹ eine bitgenaue Kopie einer kompletten Festplatte/SSD erstellt

• und ›dd‹ macht genau DAS und zwar hervorragend um nicht zu sagen herausbaumelnd - wieso sollte dann bitte diese bitgenaue Kopie nicht funktionieren? Oder nicht booten?

Ich frage nur weil ich schon seit Jahrzehnten ausschließlich mit ›dd‹ arbeite und dieses Verhalten niemals feststellen können.

Hallo Norbert, ich grabe diesen Thread mal aus, weil ich gerade dabei bin, mit dd eine Windows SSD auf eine andere zu klonen, also ungefähr wie der TE. Ich habe das schon mal mit dd gemacht und es ging auch, m.E. einfacher als mit CloneZilla (weil man nebenher auch was machen kann). Wichtig ist in erster Linie, dass das Ziellaufwerk nicht kleiner ist als das Quelllaufwerk! Außerdem dürfen die beiden Laufwerke beim Booten nicht gleichzeitig angeschlossen sein, wg. der UUID, s.o.

Im habe einen Rechner, auf dem ist Windows auf einer 500 GB SSD (sda) und auf einer 2 TB SSD ist auf einer 1 TB Partition Ubuntu 22.04 (sdd), wo ich gerade bin. Ich habe über einen Adapter eine 1 TB SSD angeschlossen, das ist Laufwerk sde:

1

$ lsblk | grep sd

2

sda      8:0    0 465,8G  0 disk 

3

├─sda1   8:1    0   350M  0 part 

4

├─sda2   8:2    0 464,8G  0 part 

5

├─sda3   8:3    0   100M  0 part 

6

└─sda4   8:4    0   549M  0 part 

7

sdb      8:16   0   1,8T  0 disk 

8

└─sdb1   8:17   0   1,8T  0 part 

9

sdc      8:32   0 372,6G  0 disk 

10

└─sdc1   8:33   0 372,6G  0 part 

11

sdd      8:48   0   1,8T  0 disk 

12

├─sdd1   8:49   0     1G  0 part /boot/efi

13

├─sdd2   8:50   0 953,3G  0 part /

14

└─sdd3   8:51   0 908,6G  0 part 

15

sde      8:64   0 931,5G  0 disk

Jetzt habe ich eingegeben:

1

$ sudo dd if=/dev/sda of=/dev/sde

Wenn fertig geklont ist, dann hol ich die alte Windows 500 GB SSD (sda) raus und stecke anstatten ihr die neue 1 TB SSD rein. Dann wird Windows vermutlich meckern wg. Aktivierung, aber dann muss ich halt noch mal aktivieren. Die leeren 500 GB muss ich dann in die geklonte 500 GB Partition übernehmen, also in Windows im Festplattendienstprogramm einfach die Partition vergrößern.

Franc W. schrieb:

$ sudo dd if=/dev/sda of=/dev/sde

Besser aber:

1

$ sudo dd if=/dev/sda of=/dev/sde count=10MB status=progress

Dann sieht man wie es voran geht :)

Leider gibt es scheinbar bis heute, keine vernünftige Image/Backup Lösung für Linux, nur Spielkram und Fehleranfällige Lösung, wäre mir zu heiß

Das liegt daran das man so einen Quatsch nicht braucht. Ich hab mein System auch erst vor drei Wochen von einer 500MB M2 und 1TB-SSD auf eine neue 4TB M2 NVMe umgezogen und dabei gleich mal etwas umstrukturiert.

Einfach neue Platte rein, Partitionen nach Wunsch anlegen/formatieren. Alle Daten mit cp -a kopieren. Fuer sonderfaelle wie dev, usr, home, run, proc die Mountpoints anlegen. Im kopierten fstab die blkids an die neuen Partitionen anpassen. Das neues System einmal mit der Commandozeile im alten grub booten, im laufenden neuen System den grub im mbr oder efi installieren.

Und wenn man schonmal dabei ist gleich einen neuen Kernel von https://cdn.kernel.org/pub/linux/kernel/ runterladen und compilieren. (optional)

Alles keine grosse Sache. Wer das nicht kann sollte besser bei Spielzeugsoft aus Redmond bleiben. :-p

Lohnt sich uebrigens. System ist jetzt von schnell auf rattenschnell gestiegen. Selbst so Sachen wie Qt oder Virtualbox starten nun fast instantan.

Vanye

Monk schrieb:

Mit der Beschreibung schreckst du die meisten User ab. Viel zu viele Schritte. Mehr als ein Kommando nach Anleitung einzutippen nach ihnen Angst.

Wer selbst einer kurzen Liste mit einfach abzutippenden Kommandos nicht folgen kann, sollte solche Arbeiten besser der Fachfrau seines geringsten Misstrauens überlassen.

Bernd schrieb:

Spezialsoftware

= Daddelspiele

Mit der Beschreibung schreckst du die meisten User ab.

Das ist dann aber auch besser so!

Genau deswegen gibt für solche Pillepalle nur wenig GUI Programme.

Die helfen einem nicht. Denn es gibt immer mal irgendein kleines unvorsehbares Problem das man dann schnell von der Kommandozeile aus beheben kann. Wenn es aber alles versteckt in KlickiBunti laeuft dann sieht man nicht die Ursache und kann schon gar nix beheben. Dann steht man letztlich wie doof da und kann mit seiner Unterlippe "bl-bl-bl" machen und dann ist man wieder Windowsuser. Das will man ja gerade nicht!

Beispiel?!

Bei mir lief die neue 4TB 990PRO nicht im zweiten M2 Sockel auf dem Board. Grund dafuer ist angeblich das bei meinem Asrock Taichi X470 irgendeine Leitung am zweiten M2 Sockel vergessen wurde und deshalb dort die neue Nvme nicht laeuft. (aeltere Nvme gehen aber!) Deshalb musste ich meine alte NVMe da reinbauen und die neue in den ersten M2 Platz wo sie auch geht! Dadurch werden die Boot und Kopieraktionen natuerlich etwas anders. Aber wenn man versteht was man da macht auch kein grosses Problem.

Und ja, ich musste auch erstmal die Hilfe von grub lesen weil ich sowas natuerlich auch nur alle 10Jahre mal mache. Aber es gibt ja auch eine Anleitung! BTW: Bemerkenswert was grub alles fuer Kommandos kennt!

Was glaubt ihr eigentlich welche Freude das war als die Partitionen noch mit sdaX, sdbX, sdcX angesprochen wurden und sich die Reihenfolge je nach Bios im MB, je nach Hostadapter oder ob noch ein Brenner an hda war geaendert hat. Dazu ist das heute gerade zu ein Kinderspiel. .-)

Vanye

Franc W. schrieb:

1

> $ sudo dd if=/dev/sda of=/dev/sde count=10MB status=progress

2

>

Dann sieht man wie es voran geht :)

Dauert aber lange! Bin bei 30 GB erst, bei 11 MB/s, habe vorhin angefangen. Ich hatte es schon heute morgen gestartet und bin weg, aber nach 2 h ist der Rechner in den Energiesparenmodus gegangen und dabei ist es wohl abgebrochen, jedenfalls hat alles gefehlt. Dann hab ich die sde noch mal mit Gparted komplett gelöscht (alle schon angelegten Partitionen) und noch mal neu angefangen.

Ich glaub, das nächste Mal nehm ich wirklich Clonezilla, das gibt ja auch als Skript in Ubuntu (apt install clonezilla). Beide Platten sind ja nicht in Verwendung, daher ginge das ja problemlos. Ich hätte es auch in Windows machen können, fallt mir jetzt ein, mit snapshot.exe, das kann das auch, hab ich auch schon mal gemacht.

Paule M. schrieb:

Verwende einfach bekannte Windows Tools wie die von Macrium Reflect. Ich meine mit der kostenlosen Testversion geht das git aber noch eine Menge andere Tools.

Hast Du diesen unvollständigen Satz aus einem Backup Deines Wunderwerkzeugs wiederhergestellt? Dann wirkt auf mich nicht sehr vertrauenerweckend. :-)

Nebenbei erwähnt der Eintrag Deines Wunderwerkzeugs in der englischsprachigen Wikipedia, daß die freie Version des Wunderwerkzeugs eingestellt worden sei, und seit Januar 2024 keine Updates mehr erhält.

Die werden dann vom USB Stick gestartet oder CD und ganz easy geklont. Leider gibt es scheinbar bis heute, keine vernünftige Image/Backup Lösung für Linux, nur Spielkram und Fehleranfällige Lösung, wäre mir zu heiß

Klar gibt es die, auch für die armen Menschen, die mit einer Kommandozeile überfordert sind. Warum allerdings ausgerechnet die ein Linux nutzen wollen würden, erschließt sich mir ohnehin nicht. Gerade die Kommandozeile ist aus meiner Perspektive doch eine der größten Stärken von Linux und ein Grund für viele jener Eigenschaften, die Linux-Anwender an ihrem System lieben.

Nebenbei bemerkt kenne ich aus der professionellen Softwareentwicklung die Faustregel, daß bei GUI-Werkzeugen 90% des Code, 90% der Fehler und 90% der Laufzeit in der GUI liegen. Das halte ich zwar für ein bisschen übertrieben, aber nichtsdestotrotz liegt darin IMHO doch ein Fünkchen Wahrheit. Dazu sind GUI-Werkzeuge mitunter sehr viel schwieriger automatisierbar als CLI-Tools, und... wie sage ich das... also gerade Backups möchte ich gern genau einmal einrichten und dann gerne vergessen, bis ich es brauche.

Moin,

Franc W. schrieb:

Franc W. schrieb:

$ sudo dd if=/dev/sda of=/dev/sde count=10MB status=progress

Dann sieht man wie es voran geht :)

Dauert aber lange! Bin bei 30 GB erst, bei 11 MB/s, habe vorhin angefangen.

Wozu denn count=10MB und warum wird die Blocksize nicht hochgesetzt - koennt' es evtl. sein, dass das copy-und-convertieren schneller geht, wenn man's nicht in 512byte Haeppchen macht? Fragen ueber Fragen...

Gruss WK

Franc W. schrieb:

1

> $ sudo dd if=/dev/sda of=/dev/sde count=10MB status=progress

2

>

/hüstel/ bs=10MB :-)

Monk schrieb:

Mit der Beschreibung schreckst du die meisten User ab. Viel zu viele Schritte. Mehr als ein Kommando nach Anleitung einzutippen nach ihnen Angst.

Norbert schrieb:

Wer selbst einer kurzen Liste mit einfach abzutippenden Kommandos nicht folgen kann, sollte solche Arbeiten besser der Fachfrau seines geringsten Misstrauens überlassen.

Seid mir nicht böse, aber solche Aussagen finde ich ein wenig bedenklich. Kommandos "nach Anleitung" abzutippen ist dasselbe wie Quellcode aus obskuren Quellen zusammen zu kopieren und dann zu behaupten, man habe "programmiert".

Auch wenn Kommandozeilenbefehle ein wunderbares Medium sind, um miteinander zu kommunizieren (jedenfalls besser als "Start -> Einstellungen -> Steuerung -> Gerätemanager -> Rübennase -> Tab 'Einstellungen' und dann dort..."), aber niemand -- und ich meine: wirklich niemand! -- sollte unverstandene Befehle auf seinem Computer eingeben und ausführen. Neben den allfälligen Hinweisen darauf, daß das mitunter gefährlich werden kann, widerspricht es aus meiner persönlichen Sicht auch der Idee vom mündigen Benutzer, der seine Software versteht und beherrscht.

nur dass das blanke "dd" auch leere Bereiche einer Festplatte mit kopiert...

wer dd empfiehlt, sollte dann auch angeben, wie man das verhindert.

●DesIntegrator ●. schrieb:

wer dd empfiehlt, sollte dann auch angeben, wie man das verhindert.

Reicht es wenn man darauf hinweist das sämtliche relevanten Parameter bequem nachlesbar sind, wenn man nur ein ›man ‹ davor schreibt?

Rolf M. schrieb:

Wenn ›dd‹ eine bitgenaue Kopie einer kompletten Festplatte/SSD erstellt

• und ›dd‹ macht genau DAS und zwar hervorragend um nicht zu sagen herausbaumelnd - wieso sollte dann bitte diese bitgenaue Kopie nicht funktionieren? Oder nicht booten?

Gute Frage. Andere Festplattengröße? Andere Seriennummer? Andere Sektorgröße (512 Bytes vs. 4k)?

Dann ist es ja kein echter Klone. Bitgenau ist bitgenau. Bei unterschiedlicher Sektorgröße zum Beispiel sind natürlich auch Sektornummern in den Partitionstabellen unterschiedlich.

Möglicherweise, weil MS die Lizenz z.T. an die Hardware gebunden hat, und ein Laufwerkswechsel da einige Punkte zugibt?

Das sollte allerdings meines Wissens eigentlich nicht das Booten verhindern sondern höchstens dazu führen, dass die Aktivierung ungültig wird und deshalb erneuert werden muss.

So ist es. Booten geht immer.

Windows-Lizenzen sind mit der Hardware verknüpft. Deshalb ist immer eine erneute Aktivierung nötig. https://support.microsoft.com/de-de/windows/windows-aktivieren-c39005d4-95ee-b91e-b399-2820fda32227 Notfalls muss man die Aktivierungs-Hotline von MS anrufen, z. B. wenn man eine digitale Lizenz hatte und der Rechner defekt ist, sodass man an die alte Lizenz nicht mehr rankommt.

Norbert schrieb:

●DesIntegrator ●. schrieb:

wer dd empfiehlt, sollte dann auch angeben, wie man das verhindert.

Reicht es wenn man darauf hinweist das sämtliche relevanten Parameter bequem nachlesbar sind, wenn man nur ein ›man ‹ davor schreibt?

wenns da drin steht?

●DesIntegrator ●. schrieb:

wenns da drin steht?

Bei mir steht's drin. Kann aber eine absolute Ausnahme sein, da ich ein ansonsten völlig unbekanntes und fremdartig wirkendes – wie heißt's noch – Debian nutze. (Das kennt kaum einer…) ;-)

Franc W. schrieb:

Dauert aber lange! Bin bei 30 GB erst, bei 11 MB/s, habe vorhin angefangen.

Das hat nicht geklappt. Bei 51 GB hat es abgebrochen, warum auch immer. Ich mach es jetzt mit Gparted, also alle Partitionen kopieren...

Man pages? Die muss man ja LESEN! Das ist sowas von 80er.

Laber keinen scheiss. Die gibt es heute auch im Internet in HTML!

Vanye

Franc W. schrieb:

Ich mach es jetzt mit Gparted, also alle Partitionen kopieren...

Gparted ???

Franc W. schrieb:

Das hat nicht geklappt. Bei 51 GB hat es abgebrochen, warum auch immer. Ich mach es jetzt mit Gparted, also alle Partitionen kopieren...

Gab es keine Fehlermeldung? Lesefehler, Schreibfehler, eine der Platten nicht mehr verbunden, kein Platz mehr?

Ich nehme eigentlich immer ddrescue, falls die zu lesende Platte fehlerhaft ist.
Falls die zu schreibende Platte fehlerhaft ist, nimm eine andere Platte.
Falls die Platte verschwindet, nimm ein anderes Kabel und/oder Netzteil. Falls die Platte zu klein ist, nimm eine grössere, oder verkleinere die Partitionen auf der alten.

Stephan S. schrieb:

Franc W. schrieb:

Ich mach es jetzt mit Gparted, also alle Partitionen kopieren...

Gparted ???

Ja, der Reihe nach alle Partitionen von der sda kopieren und in die sde einfügen, dann laufen lassen. Ist jetzt bei 39% (Cloning NTFS, die größste Partition mit 470163 MB Space in use).

Daniel A. schrieb:

Gab es keine Fehlermeldung? Lesefehler, Schreibfehler, eine der Platten nicht mehr verbunden, kein Platz mehr?

Da stand nur im Terminal:

1

#dd if=/dev/sda of=/dev/sde count=100MB status=progress

2

51199103488 Bytes (51 GB, 48 GiB) kopiert, 4546 s, 11,3 MB/s

3

100000000+0 Datensätze ein

4

100000000+0 Datensätze aus

5

51200000000 Bytes (51 GB, 48 GiB) kopiert, 4555,4 s, 11,2 MB/s

6

Sie haben neue Post in /var/mail/root.

7

#

Die Post in /var/mail/root war aber was anderes.

Franc W. schrieb:

Ist jetzt bei 39%

Ist jetzt bei 50% Damit wäre es in ca. anderthalb Stund fertig, rechnerisch.

Franc W. schrieb:

Bei 51 GB hat es abgebrochen, warum auch immer.

Weil du "gesagt" hast "es" soll das tun.

Gruss WK

Dergute W. schrieb:

Franc W. schrieb:

Bei 51 GB hat es abgebrochen, warum auch immer.

Weil du "gesagt" hast "es" soll das tun.

Denkst du ich bin versehentlich auf CTRL+C gekommen?

Franc W. schrieb:

Dergute W. schrieb:

Franc W. schrieb:

Bei 51 GB hat es abgebrochen, warum auch immer.

Weil du "gesagt" hast "es" soll das tun.

Denkst du ich bin versehentlich auf CTRL+C gekommen?

Schnauf. Nein. Du hast count=100MB geschrieben, also 100MB*512= 51.2GByte. Da steht doch:

Franc W. schrieb:

100000000+0 Datensätze ein 100000000+0 Datensätze aus

Das sind 100M. Genau wie du "wolltest"...

Gruss WK

Dergute W. schrieb:

Franc W. schrieb:

Dergute W. schrieb:

Franc W. schrieb:

Bei 51 GB hat es abgebrochen, warum auch immer.

Weil du "gesagt" hast "es" soll das tun.

Denkst du ich bin versehentlich auf CTRL+C gekommen?

Schnauf. Nein. Du hast count=100MB geschrieben, also 100MB*512= 51.2GByte. Da steht doch:

Franc W. schrieb:

100000000+0 Datensätze ein 100000000+0 Datensätze aus

Das sind 100M. Genau wie du "wolltest"...

Gruss WK

Schnauf!!! Manmanman! Das hab ich dämlich und blind wo abgeschrieben, damit es einen Fortschrittsbericht gibt, ohne zu wissen was es wirklich bedeutet :( :( Ich dachte es mache in 100 MB Fortschritt, grrr. Daher hatte es vorher, als ich noch 10MB geschrieben hatte, nur 5 GB kopiert, jetzt klar. Manmanman! Einfach nur mit status=progress wäre richtig gewesen. Danke!

Bei Gparted bin ich jetzt bei knapp 72%

Franc W. schrieb:

Franc W. schrieb:

Dauert aber lange! Bin bei 30 GB erst, bei 11 MB/s, habe vorhin angefangen.

Das hat nicht geklappt. Bei 51 GB hat es abgebrochen, warum auch immer.

Nun verwende ich dd(1) seit vielen Jahren, und die einzige Situation, in der ich jemals Abbrüche erlebt habe, waren Lese- oder Schreibfehler -- vielleicht ist das kein gutes Zeichen für Dein altes oder neues Speichermedium. Mit der Option "conv=noerror" läßt sich dd(1) jedenfalls anweisen, sich in derartigen Fällen nicht zu beenden. :-)

Franc W. schrieb:

1

> #dd if=/dev/sda of=/dev/sde count=100MB status=progress

2

> 51199103488 Bytes (51 GB, 48 GiB) kopiert, 4546 s, 11,3 MB/s

3

> 100000000+0 Datensätze ein

4

> 100000000+0 Datensätze aus

5

> 51200000000 Bytes (51 GB, 48 GiB) kopiert, 4555,4 s, 11,2 MB/s

6

> Sie haben neue Post in /var/mail/root.

7

> #

8

>

Offensichtlich hat dd(1) genau das getan, was ihm mit dem flashcen Parameter "count=10MB" gesagt worden ist: 100000000 Datenblöcke zu jeweils 512 Bytes kopiert und sich dann beendet. Wie hier (nicht nur von mir) schon mehrmals gesagt wurde, nicht der "count", sondern die Blocksize "bs" auf "10MB" zu setzen, also "bs=10MB" statt "count=10MB".

Bitte versteh' meinen Hinweis als freundliche Anregung für die Zukunft: bitte keine unverstandenen Befehle aus dem Internet ausführen. In diesem Fall ist zum Glück nichts passiert, aber das kann auch ganz anders ausgehen. Natürlich spricht nichts dagegen, Kommandozeilen aus dem Internet als kreative Anregung zu benutzen, aber bitte tu' Dir selbst den Gefallen und lies vor dem Eingeben von Befehlen aus dem Netz wenigstens deren Manpages und Optionen nach. Hier in diesem Fall wärst Du dann sehr schnell selbst darauf gekommen, daß es nicht "count=10MB", sondern "bs=10MB" heißen muß. Viel Erfolg! :-)

Franc W. schrieb:

Daher hatte es vorher, als ich noch 10MB geschrieben hatte, nur 5 GB kopiert, jetzt klar. Manmanman! Einfach nur mit status=progress wäre richtig gewesen.

Jaein. Durch Weglassen von "count=100MB" hätte dd(1) sich zwar nicht beendet, aber das hätte auch dafür gesorgt, daß in Blöcken von 512 Byte kopiert wird, und das ist ziemlich langsam. Bei einem kurzen Test mit einer 3,1 GB großen Datei auf einer Samsung 970 EVO Plus kopiert das dann nur mit 187 MB/s, so daß das Kopieren der Datei geschlagene 16,8 Sekunden dauert. Mit "bs=10MB" kopiert DD dagegen Blöcke von je 10 MB, und damit ist dasselbe Video mit 1,2 GB/s in lediglich 2,7 Sekunden kopiert.

Moin,

Franc W. schrieb:

Daher hatte es vorher, als ich noch 10MB geschrieben hatte, nur 5 GB kopiert, jetzt klar.

shit happens. Wenigsten keine schwindelige Pladde, Kabel oder Controller.

Nicht zur Strafe, nur zur Uebung: Wie sieht ein dd Kommando aus, was "einfach" ab den 51.2GByte "weitermacht"? ;-)

Gruss WK

Dergute W. schrieb:

Nicht zur Strafe, nur zur Uebung: Wie sieht ein dd Kommando aus, was "einfach" ab den 51.2GByte "weitermacht"? ;-)

Mist, bin schon wieder auf Windows, das muss ich später lösen ;)

Aber meine Rechnung ist jedenfalls nicht aufgegangen: ich hab die so geklonte SSD in den Rechner gesteckt (erst auch noch verwechselt, aber da war dann ein Hinweis im Windows Datenträgerverwaltung "Doppelte Signatur" o.ä.), also anstatten der derzeitigen Windows SSD und beim Booten kam dann ein blauer Screen mit:

"Wiederherstellung Der PC/das Gerät muss repariert werden. Ein erforderliches Gerät ist nicht verbunden oder es kann nicht darauf zugegriffen werden. Fehlercode: 0x0000225 Sie müssen Wiederherstellungstools verwenden ..."

Hat also nicht geklappt...

Ein T. schrieb:

/hüstel/ bs=10MB :-)

das B hinter 10M sollte eigentlich einen Fehler produzieren, dumm wenn das ignoriert wird

Vanye R. schrieb:

Man pages? Die muss man ja LESEN! Das ist sowas von 80er.

Laber keinen scheiss. Die gibt es heute auch im Internet in HTML!

Vanye

Und HTML-Seiten muss man nicht lesen? Da Frage ich mich, wer den Sch.... labert.

Franc W. schrieb:

... beim Booten kam dann ein blauer Screen mit:

"Wiederherstellung Der PC/das Gerät muss repariert werden. Ein erforderliches Gerät ist nicht verbunden oder es kann nicht darauf zugegriffen werden. Fehlercode: 0x0000225 Sie müssen Wiederherstellungstools verwenden ..."

Fällt mir ein, dass vermutlich einfach der SSD Treiber unterschiedlich ist. Die 1 TB SSD ist zwar auch eine Samsung aber natürlich nicht identisch. Die neue ist eine 870 EVO und einige Jahre neuer als die alte 500 GB Samsung 840 EVO. Also völlig klar, dass es so nicht geht. Hätte ich "Windows reparieren" müssen. Wäre ja zu einfach gewesen. Linux klonen ging da einfacher.

Norbert schrieb:

●DesIntegrator ●. schrieb:

wenns da drin steht?

Bei mir steht's drin. Kann aber eine absolute Ausnahme sein, da ich ein ansonsten völlig unbekanntes und fremdartig wirkendes – wie heißt's noch – Debian nutze. (Das kennt kaum einer…) ;-)

magst Du das hier mal angehängterweise posten?

da war dann ein Hinweis im Windows Datenträgerverwaltung "Doppelte Signatur" o.ä.), also anstatten der derzeitigen Windows SSD und beim

Was erwartest du wenn du 1:1 kopierst?

Vanye

●DesIntegrator ●. schrieb:

magst Du das hier mal angehängterweise posten?

1

       sparse Probieren  zu  suchen,  statt  alle  Nullbyte-Ausgabeblöcke   zu

2

              schreiben

3

oder auch:

4

      sparse try to seek rather than write all-NUL output blocks

Ich hoffe ja inständig das die Bitte nur aus Spaß war...

Übersetzt: Kalle, kumma hiä. Kannse sparse angeben, dann ignorierta de Nullen. Sach dat bloß nich die Baerbock, sonst isse plötzlich wech.

Vanye R. schrieb:

da war dann ein Hinweis im Windows Datenträgerverwaltung "Doppelte Signatur" o.ä.), also anstatten der derzeitigen Windows SSD und beim

Was erwartest du wenn du 1:1 kopierst?

Das mit der Signatur war mir klar, sollte ja auch so sein, ich hätte ja nur die neue SSD drin gehabt dann, hab ja einfach umgesteckt. Nur dass natürlich der Treiber für die alte SSD in Windows hinterlegt ist, obwohl dann die neue lauft, hab ich nicht bedacht. Da scheint Linux flexibler zu sein, weil da ging das.

Norbert schrieb:

●DesIntegrator ●. schrieb:

magst Du das hier mal angehängterweise posten?

1

>        sparse Probieren  zu  suchen,  statt  alle 

2

> Nullbyte-Ausgabeblöcke   zu

3

>               schreiben

4

> oder auch:

5

>       sparse try to seek rather than write all-NUL output blocks

6

>

Ich hoffe ja inständig das die Bitte nur aus Spaß war...

Übersetzt: Kalle, kumma hiä. Kannse sparse angeben, dann ignorierta de Nullen. Sach dat bloß nich die Baerbock, sonst isse plötzlich wech.

Aber es /liesst/ das immer noch alles durch. Dauert immer noch Stunden, wenn z.B. auf ner 1TB Platte nur 50GB belegt sind.

richtige Image/Clon-Programme sind da nach Minuten fertig.

Ein T. schrieb:

Nebenbei bemerkt kenne ich aus der professionellen Softwareentwicklung die Faustregel, daß bei GUI-Werkzeugen 90% des Code, 90% der Fehler und 90% der Laufzeit in der GUI liegen.

Sinnloser Quark mit der "Genauigkeit" von Fließkommazahlen (Fließkommazahlen sind ja gerade nicht genau) als "Faustregel" professionell angepinselt??

Die GUI in Solaris ist eigentlich Top, und so viele Updates wie in Linux gibt es da auch nicht. Könnte es nicht auch sein, dass die GUI-Szenarien in Linux zu 90% unprofessionell sind und deswegen auch sehr uneinheitlich?

Früher in DOS gab es nicht so ein Durcheinander und auffälligen Hahnenkammvergleich, da gab es reichlich Papierkram zum Orientieren und einen professionellen Service.

Monk schrieb:

●DesIntegrator ●. schrieb:

Dauert immer noch Stunden

Irgendwas stimmt da nicht.

Könnte es sein, dass für das System der Bereich zwar leer war, also als "überschreibbar markiert", aber von vormals gelöschten Daten der Bereich nicht "auf Null gesetzt" war?

Weshalb ja "Entlöschungsprogramme" das wiederholen können...

●DesIntegrator ●. schrieb:

Aber es liesst das immer noch alles durch. Dauert immer noch Stunden, wenn z.B. auf ner 1TB Platte nur 50GB belegt sind.

Bei SATA III ca. 550MB/s, also grob 30GB pro Minute. Für ›Stunden‹ brauchts's da schon ein Riesen-Riesen-Drive. Bei moderneren Interfaces liest's dementsprechend nochmals schneller.

Im Übrigen ist sparse noch cleverer, das erkennt auch Null-Lücken inmitten von Dateien und handhabt diese natürlich auch korrekt.

Ein Image-Clone Programm ist darauf angewiesen das es das zu lesende Dateisystem genauestens kennt (lesend und schreibend).

Dem gegenüber "macht" ›dd‹ einfach, das muss nichts kennen und kommt mit allem klar.

es gibt auch andere Systeme als SATA III

habs grad wieder mit einem 8GB-Stick (sdb) probiert.

700MB sind drauf, Rest leer. Mit dd landen 8GB im Image:

dd if=/dev/sdb of=stick.img conv=sparse

Rbx schrieb:

Ein T. schrieb:

Nebenbei bemerkt kenne ich aus der professionellen Softwareentwicklung die Faustregel, daß bei GUI-Werkzeugen 90% des Code, 90% der Fehler und 90% der Laufzeit in der GUI liegen.

Sinnloser Quark mit der "Genauigkeit" von Fließkommazahlen (Fließkommazahlen sind ja gerade nicht genau) als "Faustregel" professionell angepinselt??

Was auch immer Du mir sagen möchtest... magst Du vielleicht kurz Deine Gedanken ordnen und es dann noch einmal versuchen? Viel Glück! jkjm

Die GUI in Solaris ist eigentlich Top,

"Die GUI" in Solaris? Offiziell hatten wir CDE, aber es gab noch eine ganze Reihe von Alternativen.

und so viele Updates wie in Linux gibt es da auch nicht.

Solaris ist ja auch schon lange tot.

Könnte es nicht auch sein, dass die GUI-Szenarien in Linux zu 90% unprofessionell sind und deswegen auch sehr uneinheitlich?

Keine Ahnung, was Du da faselst, aber wenn ich KDE und CDE vergleiche... also meine Wahl fällt dann auf den KDE, und das war auch schon so, als ich noch bei Sun gearbeitet und natürlich Solaris benutzt habe.

Früher in DOS gab es nicht so ein Durcheinander und auffälligen Hahnenkammvergleich,

Damit kenne ich mich nicht aus, und muß mich daher auf Deine Expertise verlassen.

●DesIntegrator ●. schrieb:

es gibt auch andere Systeme als SATA III

habs grad wieder mit einem 8GB-Stick (sdb) probiert.

700MB sind drauf, Rest leer. Mit dd landen 8GB im Image:

dd if=/dev/sdb of=stick.img conv=sparse

Ja selbstverständlich wird es als 8GB Datei ANGEZEIGT

BELEGT werden aber nur die 700MB auf der Platte.

1

$ cd tmp

2

$ truncate -s 100M IMAGEDATEI

3

$ ls -lh IMAGEDATEI 

4

-rw-r--r-- 1 norbert norbert 100M  5. Jul 22:05 IMAGEDATEI

5

$ du -sh IMAGEDATEI 

6

0  IMAGEDATEI

Dave würde sagen: A trap for the young players. ;-)

Zum Klonen von ext2/3/4-Partitionen bietet sich "e2image -ra" an. Und im Anschluss ein resize2fs, wenn die Zielpartition größer ist.

Ein T. schrieb:

Was auch immer Du mir sagen möchtest... magst Du vielleicht kurz Deine Gedanken ordnen und es dann noch einmal versuchen? Viel Glück! jkjm

Ja, so etwas nennt man schlecht erreichbar. Hat fast krankhafte Züge. (ist übrigens immer dasselbe mit dir, "mein Haus, mein Auto, meine tollen Freunde"...usw. wiederhole dich doch nicht dauernd.)

Ich würde hier auch Clonezilla einsetzen, ist halt Standard, und früher auf dem Atari ST gab es auch genug Kopierprogramme, die eigentlich selbsterklärend waren, und war auch kein Ding, die einzusetzen. Außerdem benutze ich zum Partitionen einstellen auch lieber die grafische Benutzeroberfläche von GParted. So etwas ähnliches gab es in DOS früher auch schon.

Wo ich aber keinen Plan habe: wie jetzt mit Wine umziehen? Bräuchte ich gar nicht, ich speichere in Windows auch nicht alles auf C: Hätte noch eine riesengroße Festplatte, auf der würde ich gerne ein speicherhungriges Spiel installieren. Ist aber auch keine SSD, weswegen das ein wenig blöd ist. Die Dinge könnten ja einfacher sein, aber sie sind wie sie sind. So bin ich am überlegen, halt doch die Hardware upzudaten, und Windows 10/11 wollte ich wenigstens auch mal ausprobieren. (https://store.steampowered.com/agecheck/app/1086940/)

Norbert schrieb:

BELEGT werden aber nur die 700MB auf der Platte. $ cd tmp $ truncate -s 100M IMAGEDATEI $ ls -lh IMAGEDATEI -rw-r--r-- 1 norbert norbert 100M 5. Jul 22:05 IMAGEDATEI $ du -sh IMAGEDATEI 0 IMAGEDATEI

Dave würde sagen: A trap for the young players. ;-)

Mit dem sparse Flag werden Nullen übersprungen. Ich möchte gar nicht wissen, was passiert wenn das Ausgabefile eine nackte Partition ist, und Teile übersprungen werden. Je nach Treiber und SSD Hersteller kann alles möglich sein. Eine SSD weiss ja ohne TRIM Befehl nicht, dass Blöcke frei sind, und ohne expliziten Schreibevorgang haben die Blöcke noch die Daten der alten Datei drinnen.

Udo K. schrieb:

Eine SSD weiss ja ohne TRIM Befehl nicht, dass Blöcke frei sind, und ohne expliziten Schreibevorgang haben die Blöcke noch die Daten der alten Datei drinnen.

Was ein FTL mit der SSD macht geht das Dateisystem aber gar nichts an.

Rbx schrieb:

Ein T. schrieb:

Was auch immer Du mir sagen möchtest... magst Du vielleicht kurz Deine Gedanken ordnen und es dann noch einmal versuchen? Viel Glück! jkjm

Ja, so etwas nennt man schlecht erreichbar. Hat fast krankhafte Züge. (ist übrigens immer dasselbe mit dir, "mein Haus, mein Auto, meine tollen Freunde"...usw. wiederhole dich doch nicht dauernd.)

Bitte entschuldige... ich weise auf einen der 90/10-Sprüche hin, die unter Softwarefachleuten kursieren -- und dort zwar meist nicht ganz ernst gemeint, aber dennoch so beliebt sind, daß sie es sogar zu eigenen Wikipedia-Einträgen gebracht haben [1,2] -- und Du erzählst mir etwas von "mein Haus, mein Auto, meine tollen Freunde"? Jetzt mache ich mir Sorgen, ist alles in Ordnung bei Dir? Geht es Dir gut?

Nebenbei bemerkt kann ich es zwar nicht gänzlich ausschließen, glaube aber tendenziell eher nicht, schlecht erreichbar oder krank zu sein. Mein ganz persönlicher Eindruck ist vielmehr, daß Du häufig Dinge schreibst, ohne daß ein Zusammenhang mit dem Thema des Threads oder Aussagen Deiner Vorredner zu erkennen wäre. Zum Beispiel in diesem Thread geht es um das Klonen von SSDs unter Linux, und Du schreibst etwas von "mein Haus, mein Auto, meine tollen Freunde", danach über Solaris, und dann über Software für DOS und den Atari ST. Was soll das? Wer will das wissen? Was trägt es zum Thema bei?

Es tut mir leid, bitte entschuldige, aber ich verstehe leider immer noch nicht, was Du mir sagen möchtest.

[1] https://de.wikipedia.org/wiki/90-90-Regel [2] https://en.wikipedia.org/wiki/Ninety%E2%80%93ninety_rule

Ich würde hier auch Clonezilla einsetzen, ist halt Standard, und früher auf dem Atari ST gab es auch genug Kopierprogramme, die eigentlich selbsterklärend waren, und war auch kein Ding, die einzusetzen.

Das mag ja sein, aber der Atari ST ist heute noch toter als Solaris. Insofern sind Deine Erinnerungen sicherlich schön, aber eben auch nicht mehr als das: schöne Erinnerungen, und heute nicht mehr sonderlich relevant. Was möchtest Du uns also damit sagen? Daß Du schon einen Atari ST hattest? Daß Du Dich noch an Deine Zeit mit dem Atari ST erinnern kannst?

Außerdem benutze ich zum Partitionen einstellen auch lieber die grafische Benutzeroberfläche von GParted. So etwas ähnliches gab es in DOS früher auch schon.

Okay, Du hattest also auch mal ein DOS-System und kannst Dich daran erinnern. Das ist schön und freut mich für Dich, aber: welchen Wert hat die Aussage, daß es Klonwerkzeuge auch schon unter DOS gegeben hat, für diese Diskussion? Oder, da Du das ja in einer Antwort auf meinen Beitrag schreibst, für mich?

Nebenbei bemerkt, ist auch GParted anscheinend dazu fähig, Partitionen (oder Dateisysteme...) zu kopieren. Ein weiteres Werkzeug wie Clonezilla wäre dazu also gar nicht notwendig, wenn man schon GPartet hat.

Naja, wie dem auch sei: ich würde nicht Clonezilla benutzen, sondern zuerst den freien Diskspace nullen und dann dd(1) mit conv=noerror,sparse,fdatasync und bs=200M benutzen. Aber, wie oben bereits angedeutet: ich fühle mich auf der Kommandozeile wohl und nach meiner Erfahrung ist Kommandozeilensoftware meistens stabiler, performanter und ressourcenschonender als GUI-Software. Aber das darf natürlich jeder gerne anders sehen und machen.

Wo ich aber keinen Plan habe: wie jetzt mit Wine umziehen?

Keine Ahnung. Als ich zum letzten Mal -- und das ist sehr lange her -- etwas mit Wine & Co zu tun hatte, hat es seine installierten Windows-Programme im Verzeichnis ${HOME}/.wine und seine Settings unter ${HOME}/.winerc abgelegt, wenn ich mich richtig erinnere. Aus diesem Grund würde ich vermuten, daß es ausreicht, diesen Ordner und die Datei zu kopieren und die Datei .winerc dergestalt zu editeren, so daß deren Pfade auf das neue Verzeichnis verweisen. Das würde ich zumindest einmal versuchen, aber, wie gesagt: ich habe nicht wirklich eine Ahnung von Wine, und kann daher nur vermuten. Viel Glück!

Rbx schrieb:

Hat fast krankhafte Züge. (ist übrigens immer dasselbe mit dir

Ein T. schrieb:

Bitte entschuldige...

Könnt ihr bitte mit diesem Unsinn aufhören? Das macht diesen doch interessanten Thread kaputt. Danke.

Ich habe zwar bisher keine Probleme gehabt, eine Festplatte zu klonen, trotzdem lese ich gerne, was es so an Möglichkeiten mit ihren Vor- und Nachteilen gibt. Ich nutze in der Regel Clonezilla, ist für mich das kleinste "Übel" ;) Intuitiv geht halt anders, aber es funktioniert sehr gut.

@Ein T.: und es ist sicher auch hilfreich, wenn du dich kürzer fassen könntest und auf den Punkt kommen. Nochmal Danke.

Moin,

Ausser als erste Hilfe bei ueberraschenden Defekten (und dann ist wohl eher ddrescue angesagt) seh' ich keinerlei Vorteile im klonen von irgendwelchen Pladden - nochdazu wenn's von der Groesse nicht identisch sein soll. Dann erstelle ich mit neuesten Tools (hat ja einen Grund, warum z.b. util-linux oder e2fsprogs permanent weiterentwickelt werden; wird bei windows-geraffel nicht viel anders sein) neue Partitionstabellen und Filesysteme meiner Wahl auf der neuen Pladde und kopiere mittels z.b. cp -a den Schlonz dahin, wo ich ihn haben will. Und wenns sein muss, halt noch den entsprechenden Bootloader (wird auch nicht schaden, wenn der mal in einer neueren Version daherkommt) und dessen config installieren und passend machen, fertsch.

Gruss WK

Udo K. schrieb:

Ich möchte gar nicht wissen, was passiert wenn das Ausgabefile eine nackte Partition ist

Direkt genutzt ist "dd" hoffentlich jedem als sehr nützliches aber potentiell hochgefährliches Lowlevel-Tool bekannt, bei dem verstehen sollte, was man tut. Andernfalls Finger weg.

mindestens genauso lowlevel und "hochgefährlich" wie 'rm'

900ss schrieb:

Könnt ihr bitte mit diesem Unsinn aufhören? Das macht diesen doch interessanten Thread kaputt. Danke.

Tut mir leid. Ich wußte nicht, daß Dich jemand dazu zwingt, jeden Beitrag vollständig zu lesen. :-)

Dergute W. schrieb:

Ausser als erste Hilfe bei ueberraschenden Defekten (und dann ist wohl eher ddrescue angesagt) seh' ich keinerlei Vorteile im klonen von irgendwelchen Pladden - nochdazu wenn's von der Groesse nicht identisch sein soll.

Mir geistert dieser Gedanke schon seit Anfang dieses Threads im Hinterkopf herum, Du bringst ihn endlich auf den Punkt. Ich frage mich, was dieses Hin- und Herkopieren von Images eigentlich soll und was der Vorteil gegenüber einer einfachen Kopie (cp(1)) oder einem anständigen Backup sein sollte?!

Außer für forensische Anwendungsfälle sehe ich keinen einzigen vernünftigen Grund dafür, ein Image eines Dateisystems anzufertigen. Okay, da fällt mir gerade ein Anwendungsfall ein: für Benutzer proprietärer Systeme, deren Daten und Konfigurationen in undokumentierte BLOBs gesperrt worden sind. Aber sonst? Was ist der tiefere Sinn dieser Tätigkeiten?

Ein T. schrieb:

Dergute W. schrieb:

Ausser als erste Hilfe bei ueberraschenden Defekten (und dann ist wohl eher ddrescue angesagt) seh' ich keinerlei Vorteile im klonen von irgendwelchen Pladden - nochdazu wenn's von der Groesse nicht identisch sein soll.

Mir geistert dieser Gedanke schon seit Anfang dieses Threads im Hinterkopf herum, Du bringst ihn endlich auf den Punkt. Ich frage mich, was dieses Hin- und Herkopieren von Images eigentlich soll und was der Vorteil gegenüber einer einfachen Kopie (cp(1)) oder einem anständigen Backup sein sollte?!

Außer für forensische Anwendungsfälle sehe ich keinen einzigen vernünftigen Grund dafür, ein Image eines Dateisystems anzufertigen. Okay, da fällt mir gerade ein Anwendungsfall ein: für Benutzer proprietärer Systeme, deren Daten und Konfigurationen in undokumentierte BLOBs gesperrt worden sind. Aber sonst? Was ist der tiefere Sinn dieser Tätigkeiten?

Lies mal den Beitrag des TE: Beitrag "SSD mit Linux klonen"

Mir fiele noch ein Grund ein: Überführung in eine VM

Ein T. schrieb:

Ich frage mich, was dieses Hin- und Herkopieren von Images eigentlich soll und was der Vorteil gegenüber einer einfachen Kopie (cp(1)) oder einem anständigen Backup sein sollte?!

Man kann sie leichter aufheben als eine Komplettkopie und man braucht nicht für jedes Image ein komplettes Laufwerk.

Ein Image ist ein Komplettbackup.

Harald K. schrieb:

Man kann sie leichter aufheben als eine Komplettkopie und man braucht nicht für jedes Image ein komplettes Laufwerk.

Ein Image ist ein Komplettbackup.

Genau!

Zusätzlich: Es ist ›sparse‹ also platzsparend. Man kann es verdammt gut Schreibschützen. Man kann es Blockweise mit Prüfsummen versehen. Man kann zB. DPRAID Funktionalität hinzubringen und so bitrot kompensieren. (Hatte ich übrigens seit mehr als zwanzig Jahren nicht ein einziges Mal) Man kann jederzeit problemlos auf einzelne oder auch alle Dateien zugreifen. Und das praktisch ohne Geschwindigkeitsverlust.

…

Man kann natürlich auch alles anders machen. Oder noch einmal anders, perfekt auf die eigenen Bedürfnisse zugeschnitten.

Die Freiheit, welche Unix/Linux Systeme freundlicherweise direkt mit sich bringen.

Moin,

Norbert schrieb:

Man kann natürlich auch alles anders machen. Oder noch einmal anders, perfekt auf die eigenen Bedürfnisse zugeschnitten.

Die Freiheit, welche Unix/Linux Systeme freundlicherweise direkt mit sich bringen.

squashfs :-)

Gruss WK

Dergute W. schrieb:

squashfs :-)

Hat mit Klonen tendenziell nur sehr wenig bis gar nichts zu tun.

Dreht die Daten beim konvertieren mehrmals "durch die Mangel".

Funktioniert aber durchaus, wenn man den passenden Anwendungsfall hat.

Stephan S. schrieb:

Lies mal den Beitrag des TE: Beitrag "SSD mit Linux klonen"

Den habe ich gelesen und trotzdem keinen zwingenden Grund dafür gefunden, warum jemand Dat(ei)en kopieren sollte, die er problemlos von seinem Installationsmedium bekommen kann. Wir reden hier -- laut des von Dir verlinkten Beitrages -- ja immer noch über Linux, nicht wahr? Also ist die Geschichte ziemlich simpel: neues System auf der neuen Disk aufsetzen, die Liste der installierten Pakete vom alten System einspielen, die Dateien von der alten auf die neue Disk kopieren, rebooten, fertig. Ängstliche Menschen können die alte Disk vor der Weiterverwendung vielleicht noch für ein halbes oder ein Jahr auf Halde legen, für den unwahrscheinlichen Fall, daß man trotz aller Sorgfalt etwas vergessen haben oder auf ihrem alten System Dinge getan haben, die den Best Current Practices widersprochen haben.

Zu den IMHO in diesem Zusammenhang angenehmsten Eigenschaften von diesem "Linux" gehört es, daß es seine Konfigurations- und Bewegungsdaten in sehr spezifischen Orten speichert: /home natürlich, /var, /etc, /root, /usr/local, /usr/src, /srv und /opt. Bei der Gelegenheit bietet es sich an, rsnapshot oder borgbackup, sowie etckeeper einzurichten: zehn Minuten Arbeit, ruhiger Schlaf über den Rest des Rechnerlebens hinaus. :-)

Mir fiele noch ein Grund ein: Überführung in eine VM

..."unter Linux". Selbe Vorgehensweise wie zuvor, nur mit einer VM als Ziel. Das geht mit an Sicherheit grenzender Wahrscheinlichkeit wesentlich schneller als das Gehampel mit riesigen Images.

Sorry, ich bleibe dabei: Images von Dateisystemen braucht es nur für forensische Zwecke, alles andere geht problemlos auch ohne.

Ich habe mehrere Linuxdistributionen installiert und diese nur als Image eingebunden. Die Dateien liegen auf einer Windows Partition.

Harald K. schrieb:

Ein Image ist ein Komplettbackup.

True. Aber es enthält eben auch sehr viele unnötige Daten, und die machen es groß, unhandlich, und nicht besonders wirtschaftlich.

Ein T. schrieb:

Also ist die Geschichte ziemlich simpel: neues System auf der neuen Disk aufsetzen, die Liste der installierten Pakete vom alten System einspielen, die Dateien von der alten auf die neue Disk kopieren, rebooten, fertig.

Wenn eine die eigene Lebenszeit nichts wert ist, kann man das natürlich so handhaben.

Dein Verfahren setzt natürlich auch voraus, daß man "die Liste der installierten Pakete" penibel und säuberlich pflegt, und "die Dateien" (die i.d.R. eine ganze Latte von quer über das System verstreuter Konfigurationsdateien enthalten) ebenso penibel gesichert hat.

Wessen Lebensinhalt das Hegen und Pflegen eines Computers ist, der kann sich das leisten. Andere müssen mit ihren Computern arbeiten, d.h. andere Dinge tun als dafür zu sorgen, daß die Kiste penibel und akkurat dokumentiert wird.

Ein Image ist da eine sehr praktische Angelegenheit, das ist schnell erzeugt und vor allem auch schnell wieder eingespielt.

Ein T. schrieb:

True. Aber es enthält eben auch sehr viele unnötige Daten, und die machen es groß, unhandlich, und nicht besonders wirtschaftlich.

Nur um der Diskussion willen, wie kommst du darauf? Und was sind ›sehr viele unnötige Daten‹?

Da ich seit Ewigkeiten sehr erfolgreich und platzsparend mit Images arbeite, wäre ich da sehr interessiert.

Harald K. schrieb:

Ein T. schrieb:

Also ist die Geschichte ziemlich simpel: neues System auf der neuen Disk aufsetzen, die Liste der installierten Pakete vom alten System einspielen, die Dateien von der alten auf die neue Disk kopieren, rebooten, fertig.

Wenn eine die eigene Lebenszeit nichts wert ist, kann man das natürlich so handhaben.

Verglichen mit dem Speicherplatz und den Zeiten, die es braucht, um Images mit nutzlosen Daten zu speichern und zu kopieren, bin ich mit meinen Setups unter Garantie sowohl schneller, als auch preiswerter unterwegs.

Aber gut, jemand, der eine Linux-Installation und drei einfache Shellbefehle als wertlos verschwendete Lebenszeit ansieht, und stattdessen lieber riesige Mengen völlig nutz- und wertloser Daten hin und her kopiert, für den ist und bleibt das wahrscheinlich für immer unverständlich.

Dein Verfahren setzt natürlich auch voraus, daß man "die Liste der installierten Pakete" penibel und säuberlich pflegt, und "die Dateien" (die i.d.R. eine ganze Latte von quer über das System verstreuter Konfigurationsdateien enthalten) ebenso penibel gesichert hat.

Das machen meine Systeme automagisch über Dpkg::Post-Invoke und meine Backups -- je nachdem rsnapshot oder Borg -- auch noch einmal vor jedem Backup. Wobei bei mir ohnehin nicht so oft installiert wird, für meine Arbeit habe ich eine erprobte Werkzeugkiste und viele andere Sachen mach ich eh in Containern. Das hilft sehr dabei, meine Systeme sauber, klein und fein zu halten.

Dazu gibt es übrigens noch einen ganz anderen Aspekt bei meinen Setups: meine Backups mit rsnapshot oder BorgBackup laufen ohnehin stündlich und werden auf mountbare Medien geschrieben. Zwei Fliegen, eine Klappe: einerseits habe ich Backups, und wenn ich ein neues System aufsetze, kann ich die Dat(ei)en aus meinen Backups jederzeit komfortabel mounten, scp(1)en oder rsync(1)en.

Wessen Lebensinhalt das Hegen und Pflegen eines Computers ist, der kann sich das leisten. Andere müssen mit ihren Computern arbeiten, d.h. andere Dinge tun als dafür zu sorgen, daß die Kiste penibel und akkurat dokumentiert wird.

Images zu benutzen, um sich die Kosten für ein sauberes Setup zu sparen, ist möglich und spart dem Einsteiger vielleicht einen halben Tag Arbeit, kostet aber langfristig viel mehr Zeit und Diskspace für das Kopieren und Speichern von letztlich vollkommen nutzlosen Informationen. Insofern ist das aus meiner Sicht nicht einmal etwas für Faulpelze -- beim fortgeschrittenen Faulpelztum geht es ja vor allem um Effizienz.

Haargenau deswegen gibt es für das Setup meiner Systeme eine (ausgesprochen einfache) Ansible-Rolle. Die macht die ganze Angelegenheit sehr einfach und komfortabel, und hat gleichzeitig den eleganten Vorteil, daß sie das Ganze hübsch dokumentiert und loggt. Einmal gelaufen, ist alles installiert und konfiguriert, das ich haben möchte. Das verbindet das Notwendige -- nämlich saubere Backups -- mit maximaler Effizienz und enormem Komfort. Yay!

Aber okay, einer meiner Lebensinhalte -- und nebenbei der, mit dem ich meine Brötchen verdiene -- ist halt, stell' das Dir vor, die Arbeit mit Computern. Deswegen nehme ich mir die Zeit, wiederkehrende, zeitraubende, langweilige, und fehleranfällige Dinge soweit irgend möglich zu automatisieren und sie so einfach und komfortabel wie möglich umzusetzen.

Wenn Dein Lebensinhalt hingegen das Anfertigen, Verwalten, und das Hin- und Herkopieren von nutzlosen Daten ist und Dir das Freude bereitet, dann mach' das doch. Ich stehe Dir dabei nicht im Wege, sondern freue mich im Gegenteil, daß Dir dann weniger Zeit bleibt, Quatsch in dieses Forum zu schreiben. Aber versuch nicht, mich zu missionieren: meine Lebenszeit ist mir zu kostbar für nutzlosen Unfug, und daran wirst Du ganz sicher nichts ändern.

Ein Image ist da eine sehr praktische Angelegenheit, das ist schnell erzeugt und vor allem auch schnell wieder eingespielt.

Naja, "schnell"... das darfst Du Dir natürlich jederzeit gerne einbilden, wenn es Dir dabei wohler ist. :-)

Norbert schrieb:

Nur um der Diskussion willen, wie kommst du darauf? Und was sind ›sehr viele unnötige Daten‹?

Wozu brauchst Du Dateien, die Du jederzeit vom Installationsimage kopieren kannst und die Du auch im Backup hast, wenn Du sie behalten möchtest? Welchen Wert haben die Dateisystem-Metadaten wie Inodes für Dich?

Da ich seit Ewigkeiten sehr erfolgreich und platzsparend mit Images arbeite, wäre ich da sehr interessiert.

Das heißt, Du fährst jedes Mal Dein System herunter, fertigst ein Image des Dateisystems (und komprimierst es zu diesem oder einem späteren Zeitpunkt), und bootest dann wieder? Bei Dir nehme ich an, daß Du sinnvolle Gründe dafür hast, und die würden wiederum mich sehr interessieren.

Ein T. schrieb:

Images zu benutzen, um sich die Kosten für ein sauberes Setup zu sparen, ist möglich und spart dem Einsteiger vielleicht einen halben Tag Arbeit, kostet aber langfristig viel mehr Zeit und Diskspace für das Kopieren und Speichern von letztlich vollkommen nutzlosen Informationen..

Also ich bin kein Einsteiger, ich habe schon vor mehr als 50 Jahren programmiert und später meine ersten Rechner selber gebaut.

Ich fertige Images an. Die kosten zwar Zeit, aber nicht meine: Während der Rechner stundenlang vom PC aufs NAS kopiert, tue ich andere Dinge: Ich schlafe, sitze im Caféhaus oder sehe einen Film. Oder ich sitze im Garten und benutze mein Notebook. Oder ich poste hier. Oder ...

Und ja, es kostet zwar Diskspace, aber ich kann mir das NAS leisten. Auf seine Lebensdauer gerechnet, sind das doch Peanuts.

Und was stört an der Existenz "nutzloser Information", wenn man sie einfach ignorieren kann? Eine plakative, aber leere Worthülse.

An der "nutzlosen" Stadtbibliothek gehe ich 99 mal einfach vorbei – aber wenn ich sie beim 100st Mal doch mal brauche, ist sie da.

Rolf schrieb:

Ich fertige Images an. Die kosten zwar Zeit, aber nicht meine: Während der Rechner stundenlang vom PC aufs NAS kopiert, tue ich andere Dinge: Ich schlafe, sitze im Caféhaus oder sehe einen Film. Oder ich sitze im Garten und benutze mein Notebook. Oder ich poste hier. Oder ...

Und ja, es kostet zwar Diskspace, aber ich kann mir das NAS leisten. Auf seine Lebensdauer gerechnet, sind das doch Peanuts.

Also sind Deine wesentlichen Argumente "ich hab's ja" und "ich kann's mir leisten", also: Diskspace und Zeit. Insbesondere diese Sache mit der Zeit ist allerdings so eine Sache, einerseits beim Sichern -- währenddessen man seinen Rechner meistens nicht benutzen kann -- und dann andererseits vor allem bei der Wiederherstellung, was insbesondere in einem Schadensfall ausgesprochen unangenehm sein kann.

Ich stelle auch nicht die Frage, ob man Images anlegen und sich die Aufwände leisten kann -- und ja, das könnten hier wohl die meisten --, sondern ob es abseits von forensischen Anwendungsfällen etwas gibt, das derartige Aufwände notwendig macht, sinnvoll erscheinen läßt oder anderweitig rechtfertigt.

Insofern freut es mich natürlich für Dich, daß Du Dir das leisten kannst, aber in der Sache überzeugen mich diese Argumente leider nicht. Das müssen sie aber auch nicht, ich bin ja nicht missionarisch unterwegs und Du kannst das gern so handhaben, wie Du es für richtig hälst. Das mache ich ja auch -- zumindest so lange, bis mich gute Argumente von etwas Besserem überzeugen. Wie gesagt, "ich kann's mir leisten" überzeugt mich leider nicht.

Und was stört an der Existenz "nutzloser Information", wenn man sie einfach ignorieren kann? Eine plakative, aber leere Worthülse.

Natürlich kannst Du sie ignorieren, aber sie verursachen trotzdem Kosten für das Kopieren übers Netzwerk, besonders wenn wir über 1GbE reden, das liefert ja höchstens 125 MB pro Sekunde. Ein 500GB-Image darüber zu kopieren dauert also schon theoretisch (also ohne Protokolloverhead) länger als eine Stunde, während der das Netzwerk dann vollständig saturiert ist.

Jetzt kann man natürlich sagen "okay, dann gehe ich eben spazieren", aber in heutigen Zeiten mit Festplatten von über 20 Terabyte braucht man dann recht schnell neue Schuhe, fürchte ich. Immerhin soll die Bewegung an der frischen Luft gut für die Gesundheit sein. ;-)

Nebenbei bemerkt, sichere ich nicht nur lokal, sondern besonders wichtige Daten auch verschlüsselt ins Internet -- und dabei wird die Sache mit der Bandbreite und der Zeit dann nochmal eine ganz andere Nummer.

Ein T. schrieb:

sondern ob es abseits von forensischen Anwendungsfällen etwas gibt,

ich habe doch ein Beispiel genannt

Ein T. schrieb:

Das heißt, Du fährst jedes Mal Dein System herunter, fertigst ein Image des Dateisystems (und komprimierst es zu diesem oder einem späteren Zeitpunkt), und bootest dann wieder?

Wieso sollte man das tun? Man kann Images zur Laufzeit erstellen. Sogar von Windows-Systemen.

Meiner Erinnerung nach funktioniert dd gar nicht mit gemounteten Partitionen. Auf jeden Fall macht es keinen Sinn das zu probieren, da ein statisches Image erstellt werden muss.

Alexander schrieb:

Meiner Erinnerung nach funktioniert dd gar nicht mit gemounteten Partitionen.

Mit der Erinnerung ist das so eine Sache... :-)

›dd‹ ist es wirklich völlig egal ob ›mounted‹ oder nicht.

Monk schrieb:

Weil man so ein inkonsistentes Dateisystem erhält, wo das Inhaltsverzeichnis einen älteren oder neueren Stand hat, als die Daten.

Du weißt, wofür es "volume shadow copies" gibt?

Monk schrieb:

Harald K. schrieb:

Wieso sollte man das tun? Man kann Images zur Laufzeit erstellen.

Weil man so ein inkonsistentes Dateisystem erhält, wo das Inhaltsverzeichnis einen älteren oder neueren Stand hat, als die Daten.

Es gibt Programme die machen auch bei eingehängten Partitionen ein konsistentes Image, drivesnapshot z.B. http://www.drivesnapshot.de/de/ dort ist auch erklärt wie das geht.

Monk schrieb:

Wir diskutieren hier aber die ganze Zeit über ein Kopieren mittels dd oder cp oder ähnlich wirkenden Programmen.

Wir diskutieren hier aber auch über das Erzeugen von Images, falls das an Dir vorbeigegangen sein sollte.

Harald K. schrieb:

Ein T. schrieb:

Das heißt, Du fährst jedes Mal Dein System herunter, fertigst ein Image des Dateisystems (und komprimierst es zu diesem oder einem späteren Zeitpunkt), und bootest dann wieder?

Wieso sollte man das tun? Man kann Images zur Laufzeit erstellen. Sogar von Windows-Systemen.

Das "Hegen und Pflegen eines Computers" ist nicht Dein Lebensinhalt, das hatte ich schon verstanden. Trotzdem danke.

Ein T. schrieb:

Trotzdem danke.

Ja, Du bist echt ein Klasse-Typ, der wirklich jeden Knopf in der Vorurteile-Maschine drückt. Mehrfach.

Harald K. schrieb:

Ein T. schrieb:

Trotzdem danke.

Ja, Du bist echt ein Klasse-Typ, der wirklich jeden Knopf in der Vorurteile-Maschine drückt. Mehrfach.

Du bist doch gleich großmäulig mit dem "Lebensinhalt" eingestiegen, nur um jetzt Du wieder einmal den schlechten Verlierer zu geben. Für blöde Vorurteile hast Du mich jedenfalls offensichtlich nicht nötig.

Ein T. schrieb:

Du bist doch gleich großmäulig mit dem "Lebensinhalt" eingestiegen,

Nein, großmäulig warst hier Du, der Du nur Deine persönliche analretentive Vorgehens- und Arbeitsweise als die /einzig/ überhaupt sinnvolle und mögliche akzeptieren willst, und alles andere mit arschiger Arroganz abkanzelst.

Harald K. schrieb:

Nein, großmäulig warst hier Du, der Du nur Deine persönliche analretentive

Lern lesen, Junge.