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.
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.
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!
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.
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.
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.
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.
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).
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:
(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.
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?
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.
> 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.
> 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
>> 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
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.
●DesIntegrator ●. schrieb:> wer dd empfiehlt, sollte dann auch angeben, wie man das verhindert.
Reicht es wenn man darauf hinweist das sämtliche relevanten Parameter
bequem nachlesbar sind, wenn man nur ein ›man ‹ davor schreibt?
Rolf M. schrieb:>> Wenn ›dd‹ eine bitgenaue Kopie einer kompletten Festplatte/SSD erstellt>> - und ›dd‹ macht genau DAS und zwar hervorragend um nicht zu sagen>> herausbaumelnd - wieso sollte dann bitte diese bitgenaue Kopie nicht>> funktionieren? Oder nicht booten?>> Gute Frage. Andere Festplattengröße? Andere Seriennummer? Andere> Sektorgröße (512 Bytes vs. 4k)?
Dann ist es ja kein echter Klone. Bitgenau ist bitgenau. Bei
unterschiedlicher Sektorgröße zum Beispiel sind natürlich auch
Sektornummern in den Partitionstabellen unterschiedlich.
>> Möglicherweise, weil MS die Lizenz z.T. an die Hardware gebunden hat,>> und ein Laufwerkswechsel da einige Punkte zugibt?> Das sollte allerdings meines Wissens eigentlich nicht das Booten> verhindern sondern höchstens dazu führen, dass die Aktivierung ungültig> wird und deshalb erneuert werden muss.
So ist es. Booten geht immer.
Windows-Lizenzen sind mit der Hardware verknüpft. Deshalb ist immer eine
erneute Aktivierung nötig.
https://support.microsoft.com/de-de/windows/windows-aktivieren-c39005d4-95ee-b91e-b399-2820fda32227
Notfalls muss man die Aktivierungs-Hotline von MS anrufen, z. B. wenn
man eine digitale Lizenz hatte und der Rechner defekt ist, sodass man an
die alte Lizenz nicht mehr rankommt.
Norbert schrieb:> ●DesIntegrator ●. schrieb:>> wer dd empfiehlt, sollte dann auch angeben, wie man das verhindert.>> Reicht es wenn man darauf hinweist das sämtliche relevanten Parameter> bequem nachlesbar sind, wenn man nur ein ›man ‹ davor schreibt?
wenns da drin steht?
●DesIntegrator ●. schrieb:> wenns da drin steht?
Bei mir steht's drin. Kann aber eine absolute Ausnahme sein, da ich ein
ansonsten völlig unbekanntes und fremdartig wirkendes – wie heißt's noch
– Debian nutze. (Das kennt kaum einer…) ;-)
Franc W. schrieb:> Dauert aber lange! Bin bei 30 GB erst, bei 11 MB/s, habe vorhin> angefangen.
Das hat nicht geklappt. Bei 51 GB hat es abgebrochen, warum auch immer.
Ich mach es jetzt mit Gparted, also alle Partitionen kopieren...
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:
Dergute W. schrieb:> Franc W. schrieb:>> Bei 51 GB hat es abgebrochen, warum auch immer.>> Weil du "gesagt" hast "es" soll das tun.
Denkst du ich bin versehentlich auf CTRL+C gekommen?
Franc W. schrieb:> Dergute W. schrieb:>> Franc W. schrieb:>>> Bei 51 GB hat es abgebrochen, warum auch immer.>>>> Weil du "gesagt" hast "es" soll das tun.>> Denkst du ich bin versehentlich auf CTRL+C gekommen?
Schnauf. Nein. Du hast count=100MB geschrieben, also 100MB*512=
51.2GByte.
Da steht doch:
Franc W. schrieb:> 100000000+0 Datensätze ein> 100000000+0 Datensätze aus
Das sind 100M. Genau wie du "wolltest"...
Gruss
WK
Dergute W. schrieb:> Franc W. schrieb:>> Dergute W. schrieb:>>> Franc W. schrieb:>>>> Bei 51 GB hat es abgebrochen, warum auch immer.>>>>>> Weil du "gesagt" hast "es" soll das tun.>>>> Denkst du ich bin versehentlich auf CTRL+C gekommen?>> Schnauf. Nein. Du hast count=100MB geschrieben, also 100MB*512=> 51.2GByte.> Da steht doch:>> Franc W. schrieb:>> 100000000+0 Datensätze ein>> 100000000+0 Datensätze aus>> Das sind 100M. Genau wie du "wolltest"...>> Gruss> WK
Schnauf!!! Manmanman! Das hab ich dämlich und blind wo abgeschrieben,
damit es einen Fortschrittsbericht gibt, ohne zu wissen was es wirklich
bedeutet :( :(
Ich dachte es mache in 100 MB Fortschritt, grrr.
Daher hatte es vorher, als ich noch 10MB geschrieben hatte, nur 5 GB
kopiert, jetzt klar.
Manmanman! Einfach nur mit status=progress wäre richtig gewesen.
Danke!
Bei Gparted bin ich jetzt bei knapp 72%
Franc W. schrieb:> Franc W. schrieb:>> Dauert aber lange! Bin bei 30 GB erst, bei 11 MB/s, habe vorhin>> angefangen.>> Das hat nicht geklappt. Bei 51 GB hat es abgebrochen, warum auch immer.
Nun verwende ich dd(1) seit vielen Jahren, und die einzige Situation, in
der ich jemals Abbrüche erlebt habe, waren Lese- oder Schreibfehler --
vielleicht ist das kein gutes Zeichen für Dein altes oder neues
Speichermedium. Mit der Option "conv=noerror" läßt sich dd(1) jedenfalls
anweisen, sich in derartigen Fällen nicht zu beenden. :-)
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...
Vanye R. schrieb:>> Man pages? Die muss man ja LESEN! Das ist sowas von 80er.>> Laber keinen scheiss. Die gibt es heute auch im Internet in HTML!>> Vanye
Und HTML-Seiten muss man nicht lesen? Da Frage ich mich, wer den
Sch.... labert.
Franc W. schrieb:> ... beim Booten kam dann ein blauer Screen mit:>> "Wiederherstellung> Der PC/das Gerät muss repariert werden.> Ein erforderliches Gerät ist nicht verbunden oder es kann nicht darauf> zugegriffen werden.> Fehlercode: 0x0000225> Sie müssen Wiederherstellungstools verwenden> ..."
Fällt mir ein, dass vermutlich einfach der SSD Treiber unterschiedlich
ist. Die 1 TB SSD ist zwar auch eine Samsung aber natürlich nicht
identisch. Die neue ist eine 870 EVO und einige Jahre neuer als die alte
500 GB Samsung 840 EVO.
Also völlig klar, dass es so nicht geht. Hätte ich "Windows reparieren"
müssen. Wäre ja zu einfach gewesen.
Linux klonen ging da einfacher.
Norbert schrieb:> ●DesIntegrator ●. schrieb:>> wenns da drin steht?>> Bei mir steht's drin. Kann aber eine absolute Ausnahme sein, da ich ein> ansonsten völlig unbekanntes und fremdartig wirkendes – wie heißt's noch> – Debian nutze. (Das kennt kaum einer…) ;-)
magst Du das hier mal angehängterweise posten?
> da war dann ein Hinweis im Windows Datenträgerverwaltung "Doppelte> Signatur" o.ä.), also anstatten der derzeitigen Windows SSD und beim
Was erwartest du wenn du 1:1 kopierst?
Vanye
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.
> 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.
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 ANGEZEIGTBELEGT 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. ;-)
Ein T. schrieb:> Was auch immer Du mir sagen möchtest... magst Du vielleicht kurz Deine> Gedanken ordnen und es dann noch einmal versuchen? Viel Glück! jkjm
Ja, so etwas nennt man schlecht erreichbar. Hat fast krankhafte Züge.
(ist übrigens immer dasselbe mit dir, "mein Haus, mein Auto, meine
tollen Freunde"...usw. wiederhole dich doch nicht dauernd.)
Ich würde hier auch Clonezilla einsetzen, ist halt Standard, und früher
auf dem Atari ST gab es auch genug Kopierprogramme, die eigentlich
selbsterklärend waren, und war auch kein Ding, die einzusetzen.
Außerdem benutze ich zum Partitionen einstellen auch lieber die
grafische Benutzeroberfläche von GParted. So etwas ähnliches gab es in
DOS früher auch schon.
Wo ich aber keinen Plan habe: wie jetzt mit Wine umziehen? Bräuchte ich
gar nicht, ich speichere in Windows auch nicht alles auf C: Hätte noch
eine riesengroße Festplatte, auf der würde ich gerne ein
speicherhungriges Spiel installieren. Ist aber auch keine SSD, weswegen
das ein wenig blöd ist. Die Dinge könnten ja einfacher sein, aber sie
sind wie sie sind.
So bin ich am überlegen, halt doch die Hardware upzudaten, und Windows
10/11 wollte ich wenigstens auch mal ausprobieren.
(https://store.steampowered.com/agecheck/app/1086940/)
Norbert schrieb:> BELEGT werden aber nur die 700MB auf der Platte.> $ cd tmp> $ truncate -s 100M IMAGEDATEI> $ ls -lh IMAGEDATEI> -rw-r--r-- 1 norbert norbert 100M 5. Jul 22:05 IMAGEDATEI> $ du -sh IMAGEDATEI> 0 IMAGEDATEI>> Dave würde sagen: A trap for the young players. ;-)
Mit dem sparse Flag werden Nullen übersprungen. Ich möchte gar nicht
wissen, was passiert wenn das Ausgabefile eine nackte Partition ist, und
Teile übersprungen werden. Je nach Treiber und SSD Hersteller kann
alles möglich sein. Eine SSD weiss ja ohne TRIM Befehl nicht, dass
Blöcke frei sind, und ohne expliziten Schreibevorgang haben die Blöcke
noch die Daten der alten Datei drinnen.
Udo K. schrieb:> Eine SSD weiss ja ohne TRIM Befehl nicht, dass Blöcke frei sind, und> ohne expliziten Schreibevorgang haben die Blöcke noch die Daten der> alten Datei drinnen.
Was ein FTL mit der SSD macht geht das Dateisystem aber gar nichts an.
Rbx schrieb:> Ein T. schrieb:>> Was auch immer Du mir sagen möchtest... magst Du vielleicht kurz Deine>> Gedanken ordnen und es dann noch einmal versuchen? Viel Glück! jkjm>> Ja, so etwas nennt man schlecht erreichbar. Hat fast krankhafte Züge.> (ist übrigens immer dasselbe mit dir, "mein Haus, mein Auto, meine> tollen Freunde"...usw. wiederhole dich doch nicht dauernd.)
Bitte entschuldige... ich weise auf einen der 90/10-Sprüche hin, die
unter Softwarefachleuten kursieren -- und dort zwar meist nicht ganz
ernst gemeint, aber dennoch so beliebt sind, daß sie es sogar zu eigenen
Wikipedia-Einträgen gebracht haben [1,2] -- und Du erzählst mir etwas
von "mein Haus, mein Auto, meine tollen Freunde"? Jetzt mache ich mir
Sorgen, ist alles in Ordnung bei Dir? Geht es Dir gut?
Nebenbei bemerkt kann ich es zwar nicht gänzlich ausschließen, glaube
aber tendenziell eher nicht, schlecht erreichbar oder krank zu sein.
Mein ganz persönlicher Eindruck ist vielmehr, daß Du häufig Dinge
schreibst, ohne daß ein Zusammenhang mit dem Thema des Threads oder
Aussagen Deiner Vorredner zu erkennen wäre. Zum Beispiel in diesem
Thread geht es um das Klonen von SSDs unter Linux, und Du schreibst
etwas von "mein Haus, mein Auto, meine tollen Freunde", danach über
Solaris, und dann über Software für DOS und den Atari ST. Was soll das?
Wer will das wissen? Was trägt es zum Thema bei?
Es tut mir leid, bitte entschuldige, aber ich verstehe leider immer noch
nicht, was Du mir sagen möchtest.
[1] https://de.wikipedia.org/wiki/90-90-Regel
[2] https://en.wikipedia.org/wiki/Ninety%E2%80%93ninety_rule> Ich würde hier auch Clonezilla einsetzen, ist halt Standard, und früher> auf dem Atari ST gab es auch genug Kopierprogramme, die eigentlich> selbsterklärend waren, und war auch kein Ding, die einzusetzen.
Das mag ja sein, aber der Atari ST ist heute noch toter als Solaris.
Insofern sind Deine Erinnerungen sicherlich schön, aber eben auch nicht
mehr als das: schöne Erinnerungen, und heute nicht mehr sonderlich
relevant. Was möchtest Du uns also damit sagen? Daß Du schon einen Atari
ST hattest? Daß Du Dich noch an Deine Zeit mit dem Atari ST erinnern
kannst?
> Außerdem benutze ich zum Partitionen einstellen auch lieber die> grafische Benutzeroberfläche von GParted. So etwas ähnliches gab es in> DOS früher auch schon.
Okay, Du hattest also auch mal ein DOS-System und kannst Dich daran
erinnern. Das ist schön und freut mich für Dich, aber: welchen Wert hat
die Aussage, daß es Klonwerkzeuge auch schon unter DOS gegeben hat, für
diese Diskussion? Oder, da Du das ja in einer Antwort auf meinen Beitrag
schreibst, für mich?
Nebenbei bemerkt, ist auch GParted anscheinend dazu fähig, Partitionen
(oder Dateisysteme...) zu kopieren. Ein weiteres Werkzeug wie Clonezilla
wäre dazu also gar nicht notwendig, wenn man schon GPartet hat.
Naja, wie dem auch sei: ich würde nicht Clonezilla benutzen, sondern
zuerst den freien Diskspace nullen und dann dd(1) mit
conv=noerror,sparse,fdatasync und bs=200M benutzen. Aber, wie oben
bereits angedeutet: ich fühle mich auf der Kommandozeile wohl und nach
meiner Erfahrung ist Kommandozeilensoftware meistens stabiler,
performanter und ressourcenschonender als GUI-Software. Aber das darf
natürlich jeder gerne anders sehen und machen.
> Wo ich aber keinen Plan habe: wie jetzt mit Wine umziehen?
Keine Ahnung. Als ich zum letzten Mal -- und das ist sehr lange her --
etwas mit Wine & Co zu tun hatte, hat es seine installierten
Windows-Programme im Verzeichnis ${HOME}/.wine und seine Settings unter
${HOME}/.winerc abgelegt, wenn ich mich richtig erinnere. Aus diesem
Grund würde ich vermuten, daß es ausreicht, diesen Ordner und die Datei
zu kopieren und die Datei .winerc dergestalt zu editeren, so daß deren
Pfade auf das neue Verzeichnis verweisen. Das würde ich zumindest einmal
versuchen, aber, wie gesagt: ich habe nicht wirklich eine Ahnung von
Wine, und kann daher nur vermuten. Viel Glück!
Rbx schrieb:> Hat fast krankhafte Züge.> (ist übrigens immer dasselbe mit dirEin T. schrieb:> Bitte entschuldige...
Könnt ihr bitte mit diesem Unsinn aufhören? Das macht diesen doch
interessanten Thread kaputt. Danke.
Ich habe zwar bisher keine Probleme gehabt, eine Festplatte zu klonen,
trotzdem lese ich gerne, was es so an Möglichkeiten mit ihren Vor- und
Nachteilen gibt.
Ich nutze in der Regel Clonezilla, ist für mich das kleinste "Übel" ;)
Intuitiv geht halt anders, aber es funktioniert sehr gut.
@Ein T.: und es ist sicher auch hilfreich, wenn du dich kürzer fassen
könntest und auf den Punkt kommen. Nochmal Danke.
Moin,
Ausser als erste Hilfe bei ueberraschenden Defekten (und dann ist wohl
eher ddrescue angesagt) seh' ich keinerlei Vorteile im klonen von
irgendwelchen Pladden - nochdazu wenn's von der Groesse nicht identisch
sein soll.
Dann erstelle ich mit neuesten Tools (hat ja einen Grund, warum z.b.
util-linux oder e2fsprogs permanent weiterentwickelt werden; wird bei
windows-geraffel nicht viel anders sein) neue Partitionstabellen und
Filesysteme meiner Wahl auf der neuen Pladde und kopiere mittels z.b. cp
-a den Schlonz dahin, wo ich ihn haben will.
Und wenns sein muss, halt noch den entsprechenden Bootloader (wird auch
nicht schaden, wenn der mal in einer neueren Version daherkommt) und
dessen config installieren und passend machen, fertsch.
Gruss
WK
Udo K. schrieb:> Ich möchte gar nicht> wissen, was passiert wenn das Ausgabefile eine nackte Partition ist
Direkt genutzt ist "dd" hoffentlich jedem als sehr nützliches aber
potentiell hochgefährliches Lowlevel-Tool bekannt, bei dem verstehen
sollte, was man tut. Andernfalls Finger weg.
900ss schrieb:> Könnt ihr bitte mit diesem Unsinn aufhören? Das macht diesen doch> interessanten Thread kaputt. Danke.
Tut mir leid. Ich wußte nicht, daß Dich jemand dazu zwingt, jeden
Beitrag vollständig zu lesen. :-)
Dergute W. schrieb:> Ausser als erste Hilfe bei ueberraschenden Defekten (und dann ist wohl> eher ddrescue angesagt) seh' ich keinerlei Vorteile im klonen von> irgendwelchen Pladden - nochdazu wenn's von der Groesse nicht identisch> sein soll.
Mir geistert dieser Gedanke schon seit Anfang dieses Threads im
Hinterkopf herum, Du bringst ihn endlich auf den Punkt. Ich frage mich,
was dieses Hin- und Herkopieren von Images eigentlich soll und was der
Vorteil gegenüber einer einfachen Kopie (cp(1)) oder einem anständigen
Backup sein sollte?!
Außer für forensische Anwendungsfälle sehe ich keinen einzigen
vernünftigen Grund dafür, ein Image eines Dateisystems anzufertigen.
Okay, da fällt mir gerade ein Anwendungsfall ein: für Benutzer
proprietärer Systeme, deren Daten und Konfigurationen in undokumentierte
BLOBs gesperrt worden sind. Aber sonst? Was ist der tiefere Sinn dieser
Tätigkeiten?
Ein T. schrieb:> Dergute W. schrieb:>> Ausser als erste Hilfe bei ueberraschenden Defekten (und dann ist wohl>> eher ddrescue angesagt) seh' ich keinerlei Vorteile im klonen von>> irgendwelchen Pladden - nochdazu wenn's von der Groesse nicht identisch>> sein soll.>> Mir geistert dieser Gedanke schon seit Anfang dieses Threads im> Hinterkopf herum, Du bringst ihn endlich auf den Punkt. Ich frage mich,> was dieses Hin- und Herkopieren von Images eigentlich soll und was der> Vorteil gegenüber einer einfachen Kopie (cp(1)) oder einem anständigen> Backup sein sollte?!>> Außer für forensische Anwendungsfälle sehe ich keinen einzigen> vernünftigen Grund dafür, ein Image eines Dateisystems anzufertigen.> Okay, da fällt mir gerade ein Anwendungsfall ein: für Benutzer> proprietärer Systeme, deren Daten und Konfigurationen in undokumentierte> BLOBs gesperrt worden sind. Aber sonst? Was ist der tiefere Sinn dieser> Tätigkeiten?
Lies mal den Beitrag des TE:
Beitrag "SSD mit Linux klonen"
Mir fiele noch ein Grund ein: Überführung in eine VM
Ein T. schrieb:> Ich frage mich,> was dieses Hin- und Herkopieren von Images eigentlich soll und was der> Vorteil gegenüber einer einfachen Kopie (cp(1)) oder einem anständigen> Backup sein sollte?!
Man kann sie leichter aufheben als eine Komplettkopie und man braucht
nicht für jedes Image ein komplettes Laufwerk.
Ein Image ist ein Komplettbackup.
Harald K. schrieb:> Man kann sie leichter aufheben als eine Komplettkopie und man braucht> nicht für jedes Image ein komplettes Laufwerk.>> Ein Image ist ein Komplettbackup.
Genau!
Zusätzlich:
Es ist ›sparse‹ also platzsparend.
Man kann es verdammt gut Schreibschützen.
Man kann es Blockweise mit Prüfsummen versehen.
Man kann zB. DPRAID Funktionalität hinzubringen und so bitrot
kompensieren.
(Hatte ich übrigens seit mehr als zwanzig Jahren nicht ein einziges Mal)
Man kann jederzeit problemlos auf einzelne oder auch alle Dateien
zugreifen. Und das praktisch ohne Geschwindigkeitsverlust.
…
Man kann natürlich auch alles anders machen. Oder noch einmal anders,
perfekt auf die eigenen Bedürfnisse zugeschnitten.
Die Freiheit, welche Unix/Linux Systeme freundlicherweise direkt mit
sich bringen.
Moin,
Norbert schrieb:> Man kann natürlich auch alles anders machen. Oder noch einmal anders,> perfekt auf die eigenen Bedürfnisse zugeschnitten.>> Die Freiheit, welche Unix/Linux Systeme freundlicherweise direkt mit> sich bringen.
squashfs :-)
Gruss
WK
Dergute W. schrieb:> squashfs :-)
Hat mit Klonen tendenziell nur sehr wenig bis gar nichts zu tun.
Dreht die Daten beim konvertieren mehrmals "durch die Mangel".
Funktioniert aber durchaus, wenn man den passenden Anwendungsfall hat.
Stephan S. schrieb:> Lies mal den Beitrag des TE:> Beitrag "SSD mit Linux klonen"
Den habe ich gelesen und trotzdem keinen zwingenden Grund dafür
gefunden, warum jemand Dat(ei)en kopieren sollte, die er problemlos von
seinem Installationsmedium bekommen kann. Wir reden hier -- laut des von
Dir verlinkten Beitrages -- ja immer noch über Linux, nicht wahr? Also
ist die Geschichte ziemlich simpel: neues System auf der neuen Disk
aufsetzen, die Liste der installierten Pakete vom alten System
einspielen, die Dateien von der alten auf die neue Disk kopieren,
rebooten, fertig. Ängstliche Menschen können die alte Disk vor der
Weiterverwendung vielleicht noch für ein halbes oder ein Jahr auf Halde
legen, für den unwahrscheinlichen Fall, daß man trotz aller Sorgfalt
etwas vergessen haben oder auf ihrem alten System Dinge getan haben, die
den Best Current Practices widersprochen haben.
Zu den IMHO in diesem Zusammenhang angenehmsten Eigenschaften von diesem
"Linux" gehört es, daß es seine Konfigurations- und Bewegungsdaten in
sehr spezifischen Orten speichert: /home natürlich, /var, /etc, /root,
/usr/local, /usr/src, /srv und /opt. Bei der Gelegenheit bietet es sich
an, rsnapshot oder borgbackup, sowie etckeeper einzurichten: zehn
Minuten Arbeit, ruhiger Schlaf über den Rest des Rechnerlebens hinaus.
:-)
> Mir fiele noch ein Grund ein: Überführung in eine VM
..."unter Linux". Selbe Vorgehensweise wie zuvor, nur mit einer VM als
Ziel. Das geht mit an Sicherheit grenzender Wahrscheinlichkeit
wesentlich schneller als das Gehampel mit riesigen Images.
Sorry, ich bleibe dabei: Images von Dateisystemen braucht es nur für
forensische Zwecke, alles andere geht problemlos auch ohne.
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:> 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.
Harald K. schrieb:> Ein T. schrieb:>> Trotzdem danke.>> Ja, Du bist echt ein Klasse-Typ, der wirklich jeden Knopf in der> Vorurteile-Maschine drückt. Mehrfach.
Du bist doch gleich großmäulig mit dem "Lebensinhalt" eingestiegen, nur
um jetzt Du wieder einmal den schlechten Verlierer zu geben. Für blöde
Vorurteile hast Du mich jedenfalls offensichtlich nicht nötig.
Ein T. schrieb:> Du bist doch gleich großmäulig mit dem "Lebensinhalt" eingestiegen,
Nein, großmäulig warst hier Du, der Du nur Deine persönliche
analretentive Vorgehens- und Arbeitsweise als die einzig überhaupt
sinnvolle und mögliche akzeptieren willst, und alles andere mit
arschiger Arroganz abkanzelst.
Thread beobachten
Seitenaufteilung abschalten