Neue System-Festplatte installieren

[wckl]

Hallo,
heute wollte mein Laptop nicht starten: eingeschaltet, die Festplatte startet nicht, erst nach einem leichten Stoß meldete sie sich wieder und das System startete.
Nun sichere ich mit rsync alle Nutzer-Daten auf zwei externe Festplatten.

Da ist wohl eine neue Festplatte angeraten.
Meine Frage:
Kann ich mit rsync die komplette Festplatte mit allen Sytem-Dateien kopieren? Entsprechend als su?
Bisher nutze ich rsync -av zur Datensicherung. Sind in diesem Fall andere Optionen erforderlich?

Vorher muss ich wohl die neue Festplatte wie die alte in Partitionen aufteilen?

Vielen Dank für Hinweise.
wckl

[king-crash]

Wenn die neue Festplatte gleich groß oder größer als die Alte ist würde ich "dd if=/dev/alteplatte of=/dev/neueplatte" empfehlen. Das erzeugt eine 1:1 Kopie der Platte.
Siehe auch dd.

[debilian]

clonezilla macht sowas auch zuverlässig...

[wckl]

Zu dd eine Verständnisfrage:

Die jetzige Festplatte hat 500 GB und hat mehrere Partitionen.
Wenn ich eine neue Platte mit 1 oder 2 TB einbaue, wie verteilt dd dann den Platz?

Muss ich nicht zuerst auf der neuen Platte Partitionen einteilen, die ggf. größer als die alten Partitionen sind?
Und muss ich dd dann jeweils getrennt auf die Partitionen anwenden?

[debilian]

man dd
dd macht eine 1 zu 1 Kopie inklusive Partitionen.
Dann wäre die neue Festplatte auch 5ooGB gross.....

gruss

[debilian]

Muss ich nicht zuerst auf der neuen Platte Partitionen einteilen, die ggf. größer als die alten Partitionen sind?
Und muss ich dd dann jeweils getrennt auf die Partitionen anwenden?

das machst du eher mit rsync, dann musst du vorher natürlich die Partitonen anlegen und danach mit rsync die Inhalte kopieren.
dann grub installieren bzw. updaten....

[king-crash]

dd sollte in jedem Fall wenn die Platte gut gefüllt ist die deutlich schnellere Alternative sein.
Hier ergeben sich zwei sinnvolle Möglichkeiten:

1. Die Partition, die vergrößert werden soll, befindet sich an letzter Stelle: Die gesamte Platte mit dd kopieren und danach die letzte Partition vergrößern. Das funktioniert mit weiter vorne liegenden Partitionen natürlich nicht so einfach.

2. Die gewünschten Partitionen auf der größeren Platte mit der gewünschten Größe neu anlegen und dann mit dd Partition für Partition kopieren. Als Abschluss bringt resize2fs das jeweilige Dateisystem auf Partitionsgröße (muss natürlich auch für jede Partition erfolgen) und mit "dpkg-reconfigure grub-pc" kommt noch der Bootloader auf die Platte.
Beispiel: sda=alte Platte sdb=neue Platte, 2 Partitionen

Code: Alles auswählen

[Partitionen auf sdb vorher anlegen]
dd if=/dev/sda1 of=/dev/sdb1
dd if=/dev/sda2 of=/dev/sdb2
fsck /dev/sdb1
resize2fs /dev/sdb1
fsck /dev/sdb2
resize2fs /dev/sdb2

Was hast du denn für verschiedene Partitionen?

Edit: bei wenig bis mittelmäßig gefüllter Platte wird rsync wahrscheinlich schneller sein.

[hikaru]

dd sollte in jedem Fall die deutlich schnellere Alternative sein.

Nein.
dd kopiert auf Blockebene jedes Byte auf der HDD (Partition, etc.), auch die Leeren. rsync hingegen kopiert auf Dateiebene nur die tatsächlich vorhandenen Daten. dd kann also bezogen auf I/O rein theoretisch nur dann höchstens genauso schnell sein wie rsync, wenn die HDD rappelvoll ist.

Code: Alles auswählen

dd if=/dev/sda1 of=/dev/sdb1

Angenommen man macht das tatsächlich so, dann sollte man dd auf jeden Fall noch eine sinnvolle Option für bs mitgeben.
Moderne HDDs haben Sektoren mit 4kB Größe. Ohne explizite Angabe nutzt dd standardmäßig eine Block Size von 512B. D.h., dd würde ohne explizite Angabe von bs jeden Sektor 8x lesen und schreiben. Wenn man Glück hat, erkennt das die HDD-Firmware und fasst das wieder zusammen zu 4kB-Blöcken, aber wenn man sicher gehen will sollte man mindesten bs=4K mitgeben. Bei SSDs kann die Clustergröße auch mal deutlich größer sein und zu große Angaben schaden hier für gewöhnlich nicht, so dass bs=1M allgemein eine sinnvolle und leicht zu merkende Option ist.

[king-crash]

Da hast du natürlich nicht unrecht, bei vielen kleinen Dateien ist rsync allerdings deutlich langsamer. Am Ende des Tages kommt es hier sicherlich wesentlich auf den Füllstand der Platte an, ich korrigiere das.
bs=1M ist prinzipiell auch richtig, allerdings fängt (ohne o/iflag=direct) der readahead Cache des Kernel die Leseaufforderungen auf, sodass hier die Platte nicht traktiert werden sollte. Allerdings hat natürlich die CPU mehr zu tun.
Wen es interessiert "blockdev --report" und dann die Spalte RA mit 512 multipliziert gibt den Readaheadwert in Bytes.

Edit:
Gerade nochmal überprüft mit SATA SSD.

Code: Alles auswählen

# sync; echo 3 > /proc/sys/vm/drop_caches
# dd if=/dev/sda of=/dev/null iflag=direct count=1M
1048576+0 Datensätze ein
1048576+0 Datensätze aus
536870912 Bytes (537 MB, 512 MiB) kopiert, 26,0223 s, 20,6 MB/s
# sync; echo 3 > /proc/sys/vm/drop_caches
# dd if=/dev/sda of=/dev/null count=1M
1048576+0 Datensätze ein
1048576+0 Datensätze aus
536870912 Bytes (537 MB, 512 MiB) kopiert, 1,91346 s, 281 MB/s

Es macht transfertechnisch nur mit "direct" einen Unterschied. Wie vermutet ist die CPU aber wesentlich beschäftigter im Vergleich zu bs=1M.

[fischig]

rsync wäre für mich beim Vorhaben des TE nach wie vor die bevorzugte Wahl; habe ich seit wheezy mehrfach durchexerziert. Aber ich habe bisher noch keine zeitgemäße Maschine benutzt (efi und/oder GPT). Insofern weiß ich nicht, ob meine „obsoleten“ Erfahrungen noch hilfreich sein könnten.