[erledigt] Platte tauschen

[GregorS]

Hallo zusammen!

Eine Platte in meinem alten Rechner macht Ärger. Als er beim letzten Backup mit einer rsync-Fehlermeldung abbrach, habe ich mir die smart-Werte angeguckt und bin über einen „end-to-end Error“ gestolpert. Da das nach meinen Recherchen ein kritischer Fehler ist, möchte ich die betreffende Platte ersetzen, und zwar durch eine Platte desselben Typs, also voraussichtlich mit Byte-identischer Kapazität. Sobald ich die neue Platte habe, möchte ich so vorgehen:

1. Neue Platte da anhängen, wo jetzt die Systemplatte hängt (im Rechner gibt es keinen freien SATA-Anschluss).
2. GRML von USB-Stick booten.
3. Daten von der alten Platte auf die neue kopieren (mittels dd).
4. Alte Platte abklemmen, neue an diesen Anschluss hängen. Systemplatte wieder anschließen.

Beim Kopieren müssten Label/UUID doch „mit-umziehen“, sodass sonst keine weiteren Hampeleien nötig sind, oder nicht? D.h. das System sollte danach booten, ohne zu meckern - so, als wäre nichts gewesen.

Übersehe ich etwas?

TIA

Gregor

[debilian]

3. Daten von der alten Platte auf die neue kopieren (mittels dd).

warum nicht per rsync?

gruss

[Livingston]

Ja
Nein, Du übersiehst nichts.

[GregorS]

3. Daten von der alten Platte auf die neue kopieren (mittels dd).

warum nicht per rsync?

Weil ich die neue Platte dann erst vorbereiten müsste (Partitionieren, formatieren). Das spare ich mir mit dd.

Gruß

Gregor

[Livingston]

Von rsync würde ich sogar in diesem Fall abraten, falls Du alle UIDs beibehalten willst. Ansonsten bekämen nämlich Partitionstabelle, Partitionen und Dateisysteme bei Neueinrichtung neue UIDs ausgewürfelt; und genau das willst Du ja verhindern.

[hikaru]

Weil ich die neue Platte dann erst vorbereiten müsste (Partitionieren, formatieren). Das spare ich mir mit dd.

Partitionieren, Formatieren und den fstab-Eintrag ändern dauert geschätzt zwei Minuten. Und die neue Platte müsste dann nicht mal bytegenau gleich groß oder größer sein als die Alte.
Das Klonen der Platte mit dd dauert deutlich länger, es sei denn die ist rappelvoll.

Von rsync würde ich sogar in diesem Fall abraten, falls Du alle UIDs beibehalten willst. Ansonsten bekämen nämlich Partitionstabelle, Partitionen und Dateisysteme bei Neueinrichtung neue UIDs ausgewürfelt; und genau das willst Du ja verhindern.

Im einfachsten Fall ist das genau eine einzige UUID, die in der fstab geändert werden muss. Das halte ich für vertretbaren Aufwand.

[MSfree]

Übersehe ich etwas?

Ja, es gibt UEFI-Implemetationen, die sich daran stören, daß die kopierte Platte eine andere Seriennummer liefert als die Originalplatte.

[hikaru]

Ja, es gibt UEFI-Implemetationen, die sich daran stören, daß die kopierte Platte eine andere Seriennummer liefert als die Originalplatte.

Hier geht's doch um eine reine Datenplatte, wenn ich das richtig sehe, oder (Bootplatte soll temporär abgeklemmt werden)? Das sollte™ jedem UEFI egal sein, wenn die sich ändert.

[MSfree]

Das sollte™ jedem UEFI egal sein, wenn die sich ändert.

Den meisten UEFIs ist es auch egal. Es gibt halt ein paar besonders "sicherere" UEFIs, die einem das Leben schwre machen können.

[GregorS]

Weil ich die neue Platte dann erst vorbereiten müsste (Partitionieren, formatieren). Das spare ich mir mit dd.

Partitionieren, Formatieren und den fstab-Eintrag ändern dauert geschätzt zwei Minuten. Und die neue Platte müsste dann nicht mal bytegenau gleich groß oder größer sein als die Alte.
Das Klonen der Platte mit dd dauert deutlich länger, es sei denn die ist rappelvoll.

Zeit ist in meinem Fall kein Problem - wenn's drei Tage dauert, dauert's eben so lange. Demnächst ist WE

Von rsync würde ich sogar in diesem Fall abraten, falls Du alle UIDs beibehalten willst. Ansonsten bekämen nämlich Partitionstabelle, Partitionen und Dateisysteme bei Neueinrichtung neue UIDs ausgewürfelt; und genau das willst Du ja verhindern.

Im einfachsten Fall ist das genau eine einzige UUID, die in der fstab geändert werden muss. Das halte ich für vertretbaren Aufwand.

Es wäre mehr als eine einzige UUID. Auf der Platte befinden sich mehrere Partitionen.

Gruß

Gregor

[rjh]

Habe bislang alle derartigen Aktionen per dd vorgenommen und bisher hat es dabei nie Probleme gegeben.

[schwedenmann]

Hallo

Es wäre mehr als eine einzige UUID. Auf der Platte befinden sich mehrere Partitionen.

macht doch nichts, die UUID kannnst du doch beim Formatieren bzw anlegen des FS mitgeben.

Danach dann per rsync,cp odermc die daten einfcah rüberkopieren ferig.

mfg
schwedenmann

[michaa7]

Also wenn du deine neue Platte ein erstmal *zusätzlich* zur alten Festplatte montierst und anschließt, dann gparted öffnest und über den Punkt "partition kopieren" einen Klonauftrag nach dem anderen eingibst bis du eben im Aufgabenbereich die Liste der als Auftrag angelegten Partitionskopien siehst kannste erstmal kurz innehalten und in Ruhe anschauen:
"Stimmt alles? .................... Ok.
---> Aufträge ausführen".

Je nach Menge und Größe der Partitionen dauert das eben Stunden. Aber auch nicht signifikant länger als mit anderen Möglichkeiten dies zu erledigen, wenn überhaupt..
Einzige Einschränkung: wenn du boot- oder UEFI Partitionen so klonen willst muss man sich schon vorab Gedanken machen ob und wo GRUB nach Abklemmen der alten Platte noch da ist und etwas findet (bei booten per UUID= könnte es einen vllt egal sein, aber ab es Grub egal ist zweimal die gleiche UUID zu sehen?). Zudem können wie oben beschrieben Stolpersteine entstehen. Aber davon war ja bisher nicht die Rede.

[Livingston]

Gregor brachte mich auf dei Idee, es einfach mal selbst zu machen. Ich habe mein altes Datengrab 1:1 mit Hilfe von dd auf eine doppelt so große Platte rübergebracht (anschließend noch Partition und dann fs mit resize2fs vergrößert). Fertig, nix zu beanstanden. Wenn man nicht unter Zeitdruck steht, ist das der einfachste Weg, keine zusätzliche Hirnleistung nötig.
Einzige Nebenbedingung: Ich machte es mit grml auf einem Stick, um hier angesprochenen potenziellen Problemen aus dem Weg zu gehen.

[GregorS]

Es wäre mehr als eine einzige UUID. Auf der Platte befinden sich mehrere Partitionen.

macht doch nichts, die UUID kannnst du doch beim Formatieren bzw anlegen des FS mitgeben.

Doch, das macht was. Livingston hat den Kern erkannt: (Warte-)Zeit ist kein Problem. Ich will mein Hirn für Besseres nutzen, als UUIDs zu notieren und wieder Einzugeben.

Mein Hirn soll abgesehen vom Basteln und dd-Eingeben zu genau 0,0 % damit beschäftigt sein.

Gruß

Gregor

[hikaru]

Ich habe mein altes Datengrab 1:1 mit Hilfe von dd auf eine doppelt so große Platte rübergebracht (anschließend noch Partition und dann fs mit resize2fs vergrößert). Fertig, nix zu beanstanden.

Einen Stolperstein gibt es dabei:
Wenn deine (ur)alte Quellplatte noch 512B-Sektoren hat und auch so partitioniert wurde, und du spiegelst dieses Layout auf deine neue HDD mit 4kB-Sektoren, dann kostet das hinterher Performance.

Wenn man nicht unter Zeitdruck steht, ist das der einfachste Weg, keine zusätzliche Hirnleistung nötig.

Mein Mathelehrer pflegte mit Verweis auf die Anzahl der Felder eines Schachbretts zu sagen: "Mathematik ist die Kunst der Faulen."

[MSfree]

Wenn deine (ur)alte Quellplatte noch 512B-Sektoren hat und auch so partitioniert wurde, und du spiegelst dieses Layout auf deine neue HDD mit 4kB-Sektoren, dann kostet das hinterher Performance.

Jein.

Linuxdateisysteme verwenden schon seit Urzeiten Blockgrößen von mindestens 4kByte bzw.. ein Vielfaches davon. Bei einer Platte mit 512 Byte Blöcken werden halt 8 Festplattensektoren gelsen, um an einen 4 kByte großen Dateisystemblock zu kommen. Bei einer Platte mit 4096 Byte Blöcken wird halt nur ein Festplattensektor gelesen, um an denselben Dateisystemblock zu kommen. Beim Schreiben sieht es ähnlich aus.

Der Haken, der dabei auftreten kann, ist, daß die Grenzen 4 kByte Dateisystemblöcke nach der Kopie nicht mit den 4 kByte Festplattensektoren übereinstimmen. Allerdings wurden meines Wissen auch schon zu Zeiten von 512 Byte Festplattensektoren die Grenzen der 4 kByte Dateisystemblöcke auf ein ganzzahliges Vielfaches von 4096 Bytes auf die Platte geschrieben. Es gab ja auch schon zu früheren Zeiten Speichergeräte mti 4 kByte Blöcken, z.B. 3.5" optical Disks, wo man das berücksichtigen mußte.

Wenn man ganz sicher gehen will, Partitioniert man die Platte vorher und copiert mit dd von der Quellpartition auf die Zielpartition statt von rohen Quell-Device auf das rohe Zieldevice.

[hikaru]

Der Haken, der dabei auftreten kann, ist, daß die Grenzen 4 kByte Dateisystemblöcke nach der Kopie nicht mit den 4 kByte Festplattensektoren übereinstimmen.

Eben.

Allerdings wurden meines Wissen auch schon zu Zeiten von 512 Byte Festplattensektoren die Grenzen der 4 kByte Dateisystemblöcke auf ein ganzzahliges Vielfaches von 4096 Bytes auf die Platte geschrieben.

Das ist eine relativ "neue" Entwicklung. Ich weiß nicht mehr wann genau es war (ich meine vor 10-15 Jahren), aber es ging relativ groß durch die Medien, dass z.B. Gparted in Anbetracht moderner Festplattengeometrien nun automatisch an 4kB-Blöcken ausrichtet.

Wenn man ganz sicher gehen will, Partitioniert man die Platte vorher und copiert mit dd von der Quellpartition auf die Zielpartition statt von rohen Quell-Device auf das rohe Zieldevice.

Dann muss man ja doch wieder nachdenken. Und dann kann man auch rsync nehmen und Zeit sparen.

[MSfree]

Dann muss man ja doch wieder nachdenken.

Sollte man das nicht sowieso bei jeder Aktion, die potenziell datenvernichtend sein kann?

Schnell sind bei dd Quelle und Ziel verwechselt, die Buchstaben i und o (für if= und of=) liegen nebeneinander auf üblichen PC-Tastaturen! Fehlerquellen schleichen sich schneller ein, als einem lieb ist.

Man kann aber immer ein kleineres Quelldateisystem auf eine größere Zielpartition schreiben und es hinterher mit resize2fs (bzw. bei anderen Dateisystemen halt das dazu passende Tool) an die größere Partition anpassen.

[cosinus]

Das ist eine relativ "neue" Entwicklung. Ich weiß nicht mehr wann genau es war (ich meine vor 10-15 Jahren), aber es ging relativ groß durch die Medien, dass z.B. Gparted in Anbetracht moderner Festplattengeometrien nun automatisch an 4kB-Blöcken ausrichtet.

Waren die Blöcke nicht schon immer 4 kiB groß, also die Standardgröße?
Das viel größere Problem war doch, dass ältere Betriebssysteme wie zB Windows XP (was ja 2010 noch stark verbreitet war), "falsch" partitioniert hat. Falsch weil das Alignment nicht beachtet wurde: die erste Partition landete auf Sektor 63 - und das ist ja sehr suboptimal bei Platten mit 4K-Sektoren.
Ältere Versionen von fdisk unter Linux machten das auch, dann wurde das gefixt --> Startsektor der ersten Partition 2048 und nicht mehr 63.

[MSfree]

Waren die Blöcke nicht schon immer 4 kiB groß, also die Standardgröße?

Festplattensektoren waren früher 512 Byte groß. Erst seit Festplatten mehr als 1TB Kapazität haben, wurde auch die Sektorgröße auf 4 KB angehoben.

Bitte nicht mit der Blockgröße von Dateisystemen verwechseln. FAT und NTFS überterstützen bis heute Blockgrößen von 512 Byte. Unix- und Linuxdateisysteme hatten praktisch schon immer 4 kB Blockgröße (möglich, daß Minix sogar 512 Byte konnte).

Ältere Versionen von fdisk unter Linux machten das auch, dann wurde das gefixt --> Startsektor der ersten Partition 2048 und nicht mehr 63.

Die Verschiebung des Startsektors der ersten Partition auf 2048 ist GPT geschuldet. Mit MBR hat der Bootsektor inklusive Partitionstabelle in 512 Byte passen müssen (was auch die Anzahl der primären Partitionen auf 4 einschränkt). GPT möchte gerne 1 MByte, um genug Partitionen mitsamt der GUID speichern zu können.

[cosinus]

Festplattensektoren waren früher 512 Byte groß. Erst seit Festplatten mehr als 1TB Kapazität haben, wurde auch die Sektorgröße auf 4 KB angehoben.

Ich meinte ja auch die Dateisystemblöcke. Advanced-Format-HDD haben intern 4K-Sektoren, melden aber 512-Byte-Sektoren.

Bitte nicht mit der Blockgröße von Dateisystemen verwechseln.

Tue ich doch garnicht

[cosinus]

Die Verschiebung des Startsektors der ersten Partition auf 2048 ist GPT geschuldet. Mit MBR hat der Bootsektor inklusive Partitionstabelle in 512 Byte passen müssen (was auch die Anzahl der primären Partitionen auf 4 einschränkt). GPT möchte gerne 1 MByte, um genug Partitionen mitsamt der GUID speichern zu können.

Soviel Platz benötigt GPT aber auch nicht. Nachdem was ich hörte hatte man sich einfach auf MiB-Grenzen geeinigt für das Alignment. Schau dir mal dieses Wikipedia-Bild an; GPT braucht "nur" Platz bis Sektor 34, d.h. die Sektoren 34 bis 2047 sind leer. Partition 1 beginnt standardmäßig ab dem ersten MiB also Sektor 2048. gdisk meldet: first usable sector 34. (siehe Beispiel unten von meiner SSD)

Code: Alles auswählen

Disk /dev/sda: 234441648 sectors, 111.8 GiB
Model: Samsung SSD 850 
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): D950F871-9A7B-4EA8-A71B-5E7EF4084A75
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 234441614
Partitions will be aligned on 2048-sector boundaries
Total free space is 24521581 sectors (11.7 GiB)

[hikaru]

Als HDDs mit 4kB-Blöcken aufkamen, wurden auch SSDs gerade salonfähig. Die haben teils noch größere Flash-Zellgrößen. Und meist weiß man nicht so wirklich genau, wie groß die Zellen tatsächlich sind.
Auch auf SSDs will man ein ordentliches Alignment haben, und da wird man sich wohl gesagt haben: "Sch... auf das eine MB!" (2048*512B)

[cosinus]

Als HDDs mit 4kB-Blöcken aufkamen, wurden auch SSDs gerade salonfähig. Die haben teils noch größere Flash-Zellgrößen. Und meist weiß man nicht so wirklich genau, wie groß die Zellen tatsächlich sind.

Wie groß die tatsächlich sind weiß ich auch nicht, aber gdisk meldet bei mir 512 Byte Sektoren für meine SSD.