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€.
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.
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. 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ß Bernd schrieb: > 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?
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 :)
M.M.M schrieb: > Warum nicht? > An einem 2. PC oder mit live-USB- Stick: > cp /dev/quellssd /dev/zielssd > Dann mit gparted die gewünschten Partitionen vergrößern, fertig. So kenne ich das auch. Auf diese Weise habe ich vor wenigen Wochen die SSD meines Dienstlaptops aufgerüstet. Früher wurde für so etwas immer dd empfohlen, keine Ahnung warum. Ich bin ziemlich sicher, dass das auch mit Windows mindestens bis Version Vista klappt.
:
Bearbeitet durch User
Beitrag #7695679 wurde vom Autor gelöscht.
> 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
Vanye R. schrieb: > Einfach neue Platte rein, ... Mit der Beschreibung schreckst du die meisten User ab. Viel zu viele Schritte. Mehr als ein Kommando nach Anleitung einzutippen nach ihnen Angst. Der Zielgruppe von Linux macht das allerdings nichts aus. Genau deswegen gibt für solche Pillepalle nur wenig GUI Programme. Und wenn doch, unterscheiden diese nicht zwischen Anfänger und Experten Modi.
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.
Sorry , wer hier so einen Unsinn schreibt hat keine Ahnung. Eine Backup/Image Software hat einfach zu sein, sonst ist sie zu Fehleranfällig. Und gerade im Heimbereich muss sowas mit einem Klick zu erledigen sein. Wenn man erst merkt, das das Backup gar nicht funktioniert hat, wenn man es benötigt, sit es zu spät. Wer mal mit Tools wie Macrium gearbeitet hat, weiß was gemeint ist Und Tante Helga und Vater Fred, haben sicher kein Bock auf fehleranfällige Kommandozeilen
Von Backup war in meinem Fall nicht die Rede. Backups sollten weitgehend automatisch erstellt werden. Manuell will uch nur das Medium anschließen und den Start-knopf drücken müssen. Backup Programme hat Linux auch in allen Varianten dabei. Daran wird es nicht scheitern.
:
Bearbeitet durch User
> 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 :-)
Und was hat das damit zu tun? Du kannst es ja dennoch bentutzen, Aber Helden wie du müssen ja erstmal auf die Nase fallen bevor sie begreifen:-) Ein T. schrieb: > 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.
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?
:
Bearbeitet durch User
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?
Beitrag #7695925 wurde vom Autor gelöscht.
●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: > 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.
:
Bearbeitet durch User
Franc W. schrieb: > Ist jetzt bei 39% Ist jetzt bei 50% Damit wäre es in ca. anderthalb Stund fertig, rechnerisch.
:
Bearbeitet durch User
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%
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
●DesIntegrator ●. schrieb: > Dauert immer noch Stunden Irgendwas stimmt da nicht. Ich habe vor ein paar Wochen eine interne 256er SSD auf eine externe SSD via USB 3 mit dem cp Befehl geklont. Das dauerte nur 20 Minuten. Dabei sind weder die SSD noch der Laptop besonders schnell. Alles >5 Jahre alter Standard.
:
Bearbeitet durch User
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: > 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? Ich denke nicht, denn in meinem schnellen 20 Minuten Fall war die Ziel SSD eine gebrauchte.
●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/)
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
mindestens genauso lowlevel und "hochgefährlich" wie 'rm'
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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.
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.
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?
Harald K. schrieb: > Du weißt, wofür es "volume shadow copies" gibt? Den Begriff kenne ich. Wir diskutieren hier aber die ganze Zeit über ein Kopieren mittels dd oder cp oder ähnlich wirkenden Programmen.
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.
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
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.