Hallo, an meinem Rechner hängt eine Sata SSD, die mittlerweile zu klein geworden ist. Was wäre der einfachste Weg, diese unter Linux auf eine neue (größere) Sata SSD zu 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.
:
Bearbeitet durch User
Ich würde mit DD klonen und dannach mit Gparted die Partitionsgrößen ändern Gruss Bernd
Vielleicht sollte ich noch erwähnen, dass auf der SSD Windows installiert ist. Das muss ich leider von Zeit zu Zeit booten, wenn ich mal Spezialsoftware benötige. Wäre natürlich schön, wenn nach dem Umzug/Klonen auch die neue SSD gleich bootfähig wäre... :-)
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.
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! Besser wäre Image sichern und dann später Partition vergrößern, wennn das so einfach von der Reihenfolge her wäre. Allerdings merkt Windows Veränderungen und fragt dann gelegentlich nach dem richtigen Lizenzschlüssel. Clonezilla ist auch ganz schön, wenn man es gelesen und verstanden hat. https://www.heise.de/download/product/clonezilla-49483
Bei manchen SSDs liefert der Hersteller auch ein Cloning Tool mit (oder man kann es sich bei auf der Herstellerseite kostenlos runterladen). Meine Empfehlung ist die Free Version von Macrium Reflect.
Nimm Clonezilla, von USB reingebootet. Entweder ein Image auf eine externe Platte ziehen und nach SSD-Umbau auf die neue zurückspielen, oder wenn beide SSDs gleichzeitig verbaut sein können, direkt clonen. Danach mit Gparted die Partitionsgröße anpassen, fertig. Habe ich schon mehrfach gemacht. Anders als DD kann Clonezilla bei bekannten Dateisystemen (ext, NTFS, FAT, ...) nur die tatsächlich benutzten Blöcke clonen, und Komporession gibt's bei Images auch noch. Geht schneller.
oszi40 schrieb: > Mit einfachen kopieren änderst Du alle möglichen Dateieigenschaften! Nicht, wenn man cp -a nutzt.
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.
:
Bearbeitet durch User
Ich habe das zwar noch nie versucht, sollte aber eigentlich gehen: Man kann mit sfdisk eine Partitionstabelle dumpen, als Textfile, und wieder einspielen. Dazwischen kann man auch die grössen anpassen (alle Werte sind optional, also offsets raus löschen). Mit dd kann man dann den Inhalt der Partitionen kopieren. Danach noch das resize zum vergrössern das fs machen und fertig. Für linux partitionen kann man auch das Dateisystem anlegen (bei mkfs.* kann man die fs uuid mitgeben, oder sonst halt die fstab anpassen), und nur die Dateien kopieren (cp -a oder rsync -a, eventuell noch eine Option dran hängen, die anzeigt, wie lange es geht). Da kann man auch das verwendete fs wechseln, wenn man will. Eventuell am Schluss noch ein fstrim auf alle Partitionen.
Ich schliesse mich der Meinung von NOP an. --> Clonezilla <-- kostet nichts und funktioniert gut
Jack V. schrieb: > 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. Mit Windows funktioniert das Klonen schon - habe ich selbst schon mehrfach gemacht. Wenn das nicht funktionieren würde könnte man ja die ganzen Imagetools in die Tonne kloppen. Wenn man erstmal die komplette Platte klont so wie sie ist sollte das kein Problem sein. Danach kann man mit den gängigen Partitionierungstools die Partitionen nach seinem Gusto anpassen. @TO Was spricht dagegen die neue Platte als zweite PLatte einzubauen und dann nur das Linuxgeraffel darauf zu kopieren, z.B. wie vorgeschlagen mit rsync. Sobald das läuft kann man Linux auf der ersten Platte löschen und den gewonnenen Platz Windows zuschlagen oder auch eine ordenlich große Datenpartition anlegen die beiden System zu Gute kommt.
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.
Moin, - clonezilla ist schon ein gutes Werkzeug. Vielleicht eine kleine Anleitung auf Deutsch wuerde helfen: https://www.thomas-krenn.com/de/wiki/Klonen_einer_Windows-Installation_mit_Clonezilla Die Anleitung funktioniert (wenn man die Phraseologie von Clonezilla akzeptiert) fuer Windows und Linux. Problem ist mehr Windows10 weil Win10 eine bestimmte Partition-Reihenfolge haben will. Gruesse Th.
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
Jack V. schrieb: > Wie auch immer – um ein bootbares Windows zu bekommen, wird das Klonen > der betreffenden Partition(en) nicht ausreichen. Warum nicht? An einem 2. PC oder mit live-USB- Stick: cp /dev/quellssd /dev/zielssd wobei Quelle/Ziel die gesamte SSD ist, als z.B. sda, sdb, sdc.. Dann mit gparted die gewünschten Partitionen vergrößern, fertig. Im jedem Fall Backup bereithalten, man hat schnell mal Quelle und Zeil verwechselt.
M.M.M schrieb: > Warum nicht? Weil Windows dann schlicht nicht sauber startet. Zumindest bei meinen Versuchen, siehe oben. YMMV
DER TO hat aber Windows + Linux, wenn ich richtig gelesen habe. Ob Dein Programm auch alle benötigten Linux-Filesysteme beherrscht???
So, alles erledigt. Der Tipp mit Clonezilla war goldrichtig. Anschließend habe ich noch mit dem Windows-Festplattendienstprogramm die Partition vergrößert. Hat prima funktioniert. Danke!
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.
:
Bearbeitet durch User
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: > via etwa ›dd‹ erstellen, und damit kopierte Windowssysteme in > verschiedenen Versionen kamen bei mir reproduzierbar nicht aus eigener > Kraft hoch. habe letztes jahr ein dualboot debian/win10 mit dd über einen usb/sata adapter einfach geklont und beide systeme haben im neuen rechner ohne probleme gestartet. abgesehen von ein paar treibern unter windows und verschobenen icons wegen neuem bildschirm, ...
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.
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.
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.
Jack V. schrieb: > Ich bin kein nativer Windowsuser … und kann diesbezüglich auch nur raten. Da geht's dir wie mir. Ich gehe da auch nur dran wenn Freunde mit ihrem Gerümpel auf eine größere Platte umziehen wollen. > Möglicherweise, weil MS die Lizenz z.T. an die Hardware gebunden hat, > und ein Laufwerkswechsel da einige Punkte zugibt? Gute Idee, aber ich meine gehört zu haben das es nur kritisch wird wenn mehrere Marker geändert werden. (NIC/HDD-ID/…) Werde mal bei Clonezilla nachsehen ob die etwas in der Richtung machen. Aber wenn's so einfach wäre, könnte MS sich den Krampf auch sparen. -)
Rolf M. schrieb: > 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. Habe gerade Kaffee getrunken. Du schuldest mir eine neue Tastatur! ;-)
Norbert schrieb: > Rolf M. schrieb: >> 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. > > Habe gerade Kaffee getrunken. Du schuldest mir eine neue Tastatur! ;-) Das ist das normale Verhalten bei Linux. Kann man umgehen, wenn man mit Hilfe eines Live-Linux die Partitionen mit Labels versieht und in /etc/fstab diese Labels statt der UUID angibt.
1 | # /etc/fstab: static file system information. |
2 | # |
3 | # Use 'blkid' to print the universally unique identifier for a |
4 | # device; this may be used with UUID= as a more robust way to name devices |
5 | # that works even if disks are added and removed. See fstab(5). |
6 | # |
7 | # <file system> <mount point> <type> <options> <dump> <pass> |
8 | |
9 | /swapfile none swap sw 0 0 |
10 | LABEL=sys0815 / ext4 errors=remount-ro,relatime 0 1 |
11 | LABEL=dat0815 /home ext4 defaults,relatime 0 2 |
usuru schrieb: > Das ist das normale Verhalten bei Linux. Noch nicht einmal ansatzweise. UUID= ist der Standardweg, LABEL= ist der alternative Weg, /dev/xxx geht aber immer noch genauso gut. 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. In der Tat ist es jedoch sinnvoll nach einem Klonvorgang neue UUIDs für das Drive und die Dateisysteme zu generieren. Nicht notwendig, aber besser, damit keine Verwirrung aufkommt wenn das alte Drive im System verbleibt.
… und bei tune2fs findet man zB. -U UUID (man darf sich selbst eine ausdenken) clear clear the filesystem UUID random generate a new randomly-generated UUID time generate a new time-based UUID … und bei mkswap das Gleiche. -U, --uuid UUID gibt die zu verwendende UUID an. Vorgabe ist die Erzeugung einer UUID.
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 |
:
Bearbeitet durch User
(prx) A. K. schrieb: > Norbert schrieb: >> /dev/xxx geht aber immer noch genauso gut. > 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. Das Phänomen ist mir durchaus bekannt. Aus dem gleichen Grund hat man ja auch angefangen zB. die Netzwerk-Schnittstellen umzubenennen. Ich präzisiere dann mal: /dev/xxx geht aber in den meisten Fällen immer noch genauso gut. Obschon nicht dazu geraten wird und Linux per default auch mit UUID arbeitet. Einzelne Konfigurationen mögen anders reagieren. Dem Anwender obliegt es das System daraufhin zu überprüfen. Der Ersteller dieser Zeilen kann eine Gewährleistung bezüglich bestimmter Verhaltensweisen nicht vollumfänglich garantieren.
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.
:
Bearbeitet durch User
Rolf M. schrieb: > Ja, die UUID ist eine Eigenschaft des Dateisystems, nicht der Festplatte > selbst, Und die PARTUUIDs sind Eigenschaften des Drives welche mit Partition-Nummern hochgezählt werden. Aber wir diskutieren hier sowieso schon über Details welche die meisten Linux-_Nutzer_ gar nicht kennen und auch nie zu Gesicht bekommen. Und wer sich darüber unterhält weiß im Allgemeinen recht genau worum es geht.
Es gibt einige Tools die beim installieren die Option haben auf einem USB Stick installiert zu werden. HDCLone (sehr langsam als Free Edition (30MB/s) begrenzt) Clonezilla PartitionMagic easeus Partition Master Viele mehr.. Ich benutze easeus Partition Master, vorher immer clonezilla (gewöhnungsbedürftig).. gabs irgendwann mal als Professional Version für 5€.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.