CentOS 6.7 RAID vollständig entfernen. Festplatten schließen und von /dev/sda booten

Question 1

Zunächst einmal muss klar sein, dass es hier nicht darum geht, eine ausgefallene Festplatte in einem RAID-1-Array auszutauschen, sondern darum, das RAID-Array vollständig zu entfernen, die Festplatte zu klonen, die kurz vor dem Ausfall steht, und dann das System von der funktionierenden Festplatte ohne RAID-Konfiguration zu booten. Der Grund für diesen Ansatz ist, dass die erste Festplatte (sda), die funktionierende Festplatte, völlig leer ist, keine Partitionen und Dateisysteme hat, und wenn ich sie zum Array hinzufüge, schlägt die Synchronisierung (Neuaufbau) fehl, wahrscheinlich weil es Lesefehler auf der zweiten Festplatte (sdb) gibt. Außerdem bootet das System von der zweiten Festplatte (der fehlerhaften). Die Schritte, die zum Abschließen dieser Aufgabe erforderlich sind, sind ziemlich einfach, wenn Sie Linux und seine Befehle kennen. Das Verfahren umfasst jedoch Partitionierungs-, Klon- und MBR-Installationsaufgaben, die Ihre Daten zerstören, wenn Sie nicht vorsichtig genug sind. Schließlich ist das folgende Verfahren spezifisch für die in der Frage beschriebene Festplattenkonfiguration, sollte aber auch in anderen Systemen funktionieren, wenn Sie die erforderlichen Geräte und Partitionsnamen sorgfältig ersetzen.

Hier ist die Vorgehensweise:

1. Booten Sie das System im Rettungsmodus.

Da wir Daten von der Startdiskette des Systems klonen, müssen wir uns keine Gedanken über gesperrte Dateien oder ähnliches machen. Am besten geht das, indem wir im Rettungsmodus booten. Glücklicherweise unterstützt mein Server-Hosting-Unternehmen das auf sehr einfache Weise. Bei einem Server, auf den Sie direkten Zugriff haben (kein Remote-Zugriff), wäre das etwa so, als würden Sie von einer Live-CD booten oder „Rettungsmodus“ aus Ihrem Startmenü auswählen.

2. Bereiten Sie die erste Festplatte (/dev/sda) zum Klonen der Daten vor.

Um sda vorzubereiten, müssen wir Partitionierungsinformationen von sdb abrufen. Eigentlich ist dieser Schritt nicht zwingend erforderlich, da unser Ziel darin besteht, das System ohne RAID-Konfiguration oder, wenn Sie dies bevorzugen, ohne jegliche Verbindung zu sdb zu booten. Wenn also das aktuelle Partitionsschema nicht unseren Wünschen entspricht, haben wir hier die Möglichkeit, es zu ändern. Das Einzige, was wir beachten müssen, ist, dass die neuen Partitionen genügend Speicherplatz haben müssen, um die Daten von sdb aufzunehmen. Die Partitionierung in Linux erfordert jedoch einiges an Wissen über Ausrichtung und dergleichen, und da sdb bereits richtig partitioniert ist, fand ich es einfacher, dasselbe in sda zu tun. Dazu müssen wir zuerst die Partitionen in sdb anzeigen, ich habe dafür parted verwendet.

Notiz:Die schwierigste Aufgabe bei der Recherche nach Linux-Befehlen ist herauszufinden, welcher (von den vielen) Befehlen am besten geeignet ist. Es gibt beispielsweise eine ganze Reihe von Partitionierungsbefehlen und -dienstprogrammen, und die Entscheidung, welchen man verwenden soll, erfordert viel Zeit beim Lesen und Vergleichen von Informationen. Ich habe mich hier für parted entschieden, weil es das Dateisystem zusammen mit den Partitionen anzeigt und weil es eine bessere Unterstützung für große Festplatten bietet? (Ich bin nicht sicher).

# parted /dev/sdb
(parted) unit s
(parted) print

Ausgabe:

Model: ATA ST3000DM001-1CH1 (scsi)
Disk /dev/sdb: 5860533168s
Sector size (logical/physical): 512B/4096B
Partition Table: msdos

Number  Start        End          Size         Type      File system  Flags
 1      2048s        25167872s    25165825s    primary
 2      25169920s    26218496s    1048577s     primary   ext3         raid
 3      26220544s    2173704192s  2147483649s  primary   ext4         raid
 4      2173706240s  5860533167s  3686826928s  extended               lba
 5      2173708288s  5860533167s  3686824880s  logical   ext4         raid

(parted) quit

Wie wir hier sehen können, hat sdb eine Partitionstabelle vom Typ msdos, das heißt, wir können bis zu 4 primäre Partitionen auf der Festplatte erstellen. In diesem Fall hat es 3 primäre Partitionen (1,2,3) und eine erweiterte (4), die eine logische Partition (5) enthält.

Der nächste Schritt besteht darin, dieselben Partitionen auf sda zu erstellen:

# parted /dev/sda
(parted) unit s
(parted) mkpart primary 2048 25167872
(parted) mkpart primary 25169920 26218496
(parted) mkpart primary 26220544 2173704192
(parted) mkpart extended 2173706240 5860533167
(parted) mkpart logical 2173708288 5860533167
(parted) quit

Wie Sie sehen, habe ich dieselben Start- und Endsektoren von SDB verwendet. Natürlich sind die Datenträger dieselben, ansonsten müssen Sie die Sektoren entsprechend anordnen.

Nun müssen wir dem System die Partitionsänderungen in sda mitteilen:

# partprobe /dev/sda

Schließlich müssen wir die Dateisysteme auf sda erstellen. Wahrscheinlich ist dieser Schritt überhaupt nicht erforderlich, da wir die Partitionen von sdb klonen werden. Der Klonvorgang kopiert daher auch die Dateisysteminformationen. Es kann jedoch nicht schaden.

# mkfs -t ext3 /dev/sda2
# mkfs -t ext4 /dev/sda3
# mkfs -t ext4 /dev/sda5

Beachten Sie, dass wir in Partition 4 (sda4) kein Dateisystem erstellt haben. Dies liegt daran, dass es sich um eine erweiterte Partition handelt, die eine logische Partition (sda5) enthält. Wir müssen das Dateisystem nur auf der logischen Partition erstellen.

Jetzt haben wir sda partitioniert und sind bereit, unsere Daten zu speichern.

3. Kopieren der Daten aus SDB.

Dieser Schritt erforderte die meiste Recherche, vor allem, weil es viele Möglichkeiten gibt, Daten zu kopieren. Wahrscheinlich würde cp -a ausreichen, aber ich konnte keine verlässlichen Informationen darüber finden, wie man mit versteckten Dateien, Links usw. umgeht, um das System richtig zu booten. Also entschied ich mich für ein Dienstprogramm zum Byte-für-Byte-Kopieren (Klonen) anstelle eines Dateikopierbefehls. Das von mir verwendete Dienstprogramm war dd:

# dd if=/dev/md1 of=/dev/sda2 bs=512 conv=noerror,sync,notrunc
# dd if=/dev/md2 of=/dev/sda3 bs=512 conv=noerror,sync,notrunc
# dd if=/dev/md3 of=/dev/sda5 bs=512 conv=noerror,sync,notrunc

Hinweise: Beachten Sie zunächst, dass wir von /dev/md* und nicht von /dev/sdb* kopieren. Dies liegt daran, dass unsere SDB-Festplatte tatsächlich Teil eines RAID-1-Arrays ist. Dies war ein weiterer Teil, zu dem ich keine verlässlichen Informationen finden konnte. Beispielsweise „sieht“ das System /dev/sdb2, /dev/sdb3 und /dev/sdb5, die Partitionen, die unsere Daten enthalten, aber laut der Datei /etc/fstab mountet es /dev/md1, /dev/md2 und /dev/md3, also nahm ich an, dass es besser ist, von /dev/md* zu kopieren. Eine weitere Sache, die Sie beachten müssen, ist, wohin auf sda Sie die Daten kopieren werden. Mit anderen Worten, wohin auf sda /dev/md1,2,3 kopiert werden muss. Nun, in diesem Fall ist es einfach, das anhand der Partitionsgrößen und Dateisysteme herauszufinden, allerdings in einem anderen Systemdf -kkann dies anzeigen, aber nicht aus dem Rettungsmodus heraus; Sie müssen normal booten, damit dies funktioniert.

Schließlich weisen wir dd mit den obigen Befehlen an, jede Partition einzeln Byte für Byte zu klonen, ohne bei Lesefehlern anzuhalten (Parameter noerror). Dies kann natürlich zu einem nicht bootfähigen System führen, wenn es einen Lesedatenfehler auf sdb gibt (was in diesem Fall der Fall ist). Bevor ich jedoch dd verwendete, verwendete ich einige Techniken, um herauszufinden, welche Dateien betroffen waren und ob es sicher war, mit dem Klonen fortzufahren. Diese Aufgabe geht über den Rahmen dieser Antwort hinaus, aber ein guter Ausgangspunkt istHier.

Ein weiterer wichtiger Punkt ist der Blockgrößenparameter (bs). Laut dd-Dokumentation sollten Sie den bs-Wert auf 512 Bytes setzen, denn wenn ein Lesefehler auftritt (und das wird er), werden nur 512 Bytes auf der Zielfestplatte „zerstört“ und nicht ein größerer Bereich, der Vorgang wird jedoch langsamer sein. Auch hier konnte ich keine verlässlichen Informationen dazu finden und wahrscheinlich hätte eine Blockgröße von 4096 Bytes die gleichen Ergebnisse.

Schließlich erzeugt dd während seines Vorgangs keine Ausgabe und es wird aufgrund der Größe der Partitionen einige Zeit dauern, bis es fertig ist. Wenn Sie sehen möchten, wo es ist, sollten Sie eine neue Konsolensitzung öffnen (in meinem Fall eine neue SSH-Remotesitzung, da ich das remote mache) und den folgenden Befehl eingeben:

# kill -USR1 $(pidof dd)

Dadurch wird dd gezwungen, seinen aktuellen Fortschritt in der ersten Konsolensitzung auszudrucken.

4. Machen Sie sda bootfähig.

Dies ist ziemlich einfach durchzuführen. Zunächst müssen Sie die erforderlichen Einhängepunkte auf sda einhängen:

# mount -t ext4 /dev/sda3 /mnt
# mount -t proc proc /mnt/proc
# mount -t sysfs sys /mnt/sys
# mount -o bind /dev /mnt/dev
# mount -t ext3 /dev/sda2 /mnt/boot

Hinweis: Der letzte Befehl ist nicht erforderlich, wenn Sie in Ihrem System keine separate Partition für /boot haben.

Als Nächstes müssen Sie Root auf der Festplatte /dev/sda werden. Derzeit sind Sie Root im Rettungssystem.

# chroot /mnt /bin/bash

Als nächstes müssen wir unsere etc/mtab-Datei aktualisieren. Ich weiß nicht wirklich, warum wir das tun sollten, ich habe es in einem anderen Rettungs-Tutorial ohne Erklärung gefunden.

# grep -v rootfs /proc/mounts > /etc/mtab

Als nächstes müssen wir GRUB in sda installieren.

# grub-install --recheck /dev/sda

Ausgabe:

Probing devices to guess BIOS drives. This may take a long time.
Installation finished. No error reported.

Jetzt ist sda bereit zum Booten. Es sind jedoch noch ein paar Schritte erforderlich, um dem System mitzuteilen, wo die erforderliche Datei zu finden ist, nachdem es von sda gebootet hat.

Das erste ist zu bearbeiten/boot/grub/grub.confDatei, die GRUB liest, um herauszufinden, wie es weitergeht. In meinem Fall musste ich alle"Wurzel (hd0,0)"Instanz mit"Wurzel (hd0,1)"Und jeder„/dev/md2“Instanz mit"/dev/sda3".

grub.confkann sehr verwirrend sein, insbesondere für jemanden, der es noch nie verwendet hat. Am verwirrendsten sind die Root-Parameter. In Grub hat das Wort „root“ zwei verschiedene Bedeutungen. Wenn es als „root (hd0,1)“ angezeigt wird, teilt es Grub mit, wo sich sein Root-Verzeichnis befindet, um die erforderlichen Linux-Kernel und Anweisungen zum Booten zu finden. Viele Leute verwechseln es mit dem Root-Verzeichnis „/“ auf dem System, wenn es vollständig gebootet ist, aber was Grub hier benötigt, ist, wo sich das /boot-Verzeichnis befindet. In diesem Fall habe ich eine separate Partition (/dev/sda2), die das /boot-Verzeichnis enthält, und da /dev/sda2 die zweite Partition der ersten Festplatte ist, muss ich Grub genau das mitteilen, aber beginnend mit Null (die erste Partition ist 0, die zweite ist 1 und so weiter), also teilt der Befehl „root (hd0,1)“ Grub mit, dass es die benötigten Dateien auf der zweiten Partition der ersten Festplatte finden wird.

Wenn root als "/dev/" angezeigt wird, teilt es dem Kernel mit, wo sich das Stammverzeichnis des Dateisystems befindet, nämlich das "/", wenn das System vollständig gebootet ist. In diesem Fall geben wir also den Partitionsnamen (wie Linux ihn sieht) dort ein, wo das "/" ist, in meinem Fall /dev/sda3.

Zum Schluss müssen wir noch bearbeiten/etc/fstabum dem System beim Start mitzuteilen, was und wo gemountet werden soll.

In meinem Fall musste ich alle "/dev/md*"-Einträge durch die entsprechenden "/dev/sda*"-Partitionen ersetzen, die waren:

/dev/md1 --> /dev/sda2 /dev/md2 --> /dev/sda3 /dev/md3 --> /dev/sda5

5. Überprüfen und deaktivieren Sie den Bootvorgang von SDB.

Wenn Sie zwanghaft sind wie ich, dann möchten Sie vielleicht laufen

# file -s /dev/sda

um zu sehen, ob Grub auf SDA installiert ist. Wenn Sie eine Ausgabe wie diese erhalten:

/dev/sda: sticky x86 boot sector; GRand Unified Bootloader, stage1 version 0x3, stage2 address 0x2000, stage2 segment 0x200, GRUB version 0.94;

dann wird grub (GRand Unified Bootloader) auf sda installiert.

Obwohl es nicht notwendig ist, möchten Sie vielleicht Grub von der SDD entfernen. Ich habe das getan, weil das System von der SDB bootet, wenn etwas mit der obigen Konfiguration nicht stimmt, und das kann verwirrend sein. Um Grub von der SDB zu löschen, habe ich DD verwendet:

# dd if=/dev/zero of=/dev/sdb bs=446 count=1

Dadurch werden Nullen in die ersten 446 Bytes der Festplatte geschrieben. Auf Festplatten mit MSDOS-Partitionstabellen befindet sich dort Grub.

$ file -s /dev/sdb

Dadurch wird überprüft, ob Grub entfernt wurde.

6. Beenden Sie Chroot und hängen Sie alles aus.

# exit
# umount /mnt/boot
# umount /mnt/dev
# umount /mnt/sys
# umount /mnt/proc
# umount /mnt

Wenn während der Ausführung der obigen Befehle ein Fehler auftritt, bedeutet dies, dass etwas nicht abgeschlossen ist oder bei unserer Chroot-Sitzung ein Fehler aufgetreten ist und wir wahrscheinlich von vorne beginnen müssen.

7. Neustart.

Jetzt Daumen drücken und neu starten

# reboot

Wenn Sie sich mit Ihren ursprünglichen Root-Anmeldeinformationen beim Server anmelden können und alles ordnungsgemäß zu funktionieren scheint (Datenbanken, Websites usw.), haben Sie erfolgreich von sda gebootet.

8. Bereiten Sie SDB für den Austausch vor.

In meinem Fall wollte ich alle Daten von der SDB löschen, bevor ich den Support bat, sie zu ersetzen. Außerdem musste ich die RAID-Konfiguration vollständig aus dem System entfernen, um eine von Grund auf neue zu erstellen, wenn die neue Festplatte installiert ist. Ich begann damit, parted auszuführen, um die Partitionen zu löschen:

# parted /dev/sdb
# (parted) rm 5
# (parted) rm 4
# (parted) rm 2
# (parted) rm 2
# (parted) rm 1
# (parted) quit

Dann bemerkte ich, dass auch jede RAID-Konfiguration entfernt wurde, also nahm ich an, dass die RAID-Definition innerhalb der Partitionen war, also führte ich diesbezüglich keine weiteren Aktionen aus. Dann sicherte ich die gelöschte SDB. Es gibt mehrere Möglichkeiten, dies zu tun. Ich wählte die/Entwickler/urandomMethode vonHier

Answer

Zunächst einmal muss klar sein, dass es hier nicht darum geht, eine ausgefallene Festplatte in einem RAID-1-Array auszutauschen, sondern darum, das RAID-Array vollständig zu entfernen, die Festplatte zu klonen, die kurz vor dem Ausfall steht, und dann das System von der funktionierenden Festplatte ohne RAID-Konfiguration zu booten. Der Grund für diesen Ansatz ist, dass die erste Festplatte (sda), die funktionierende Festplatte, völlig leer ist, keine Partitionen und Dateisysteme hat, und wenn ich sie zum Array hinzufüge, schlägt die Synchronisierung (Neuaufbau) fehl, wahrscheinlich weil es Lesefehler auf der zweiten Festplatte (sdb) gibt. Außerdem bootet das System von der zweiten Festplatte (der fehlerhaften). Die Schritte, die zum Abschließen dieser Aufgabe erforderlich sind, sind ziemlich einfach, wenn Sie Linux und seine Befehle kennen. Das Verfahren umfasst jedoch Partitionierungs-, Klon- und MBR-Installationsaufgaben, die Ihre Daten zerstören, wenn Sie nicht vorsichtig genug sind. Schließlich ist das folgende Verfahren spezifisch für die in der Frage beschriebene Festplattenkonfiguration, sollte aber auch in anderen Systemen funktionieren, wenn Sie die erforderlichen Geräte und Partitionsnamen sorgfältig ersetzen.

Hier ist die Vorgehensweise:

1. Booten Sie das System im Rettungsmodus.

Da wir Daten von der Startdiskette des Systems klonen, müssen wir uns keine Gedanken über gesperrte Dateien oder ähnliches machen. Am besten geht das, indem wir im Rettungsmodus booten. Glücklicherweise unterstützt mein Server-Hosting-Unternehmen das auf sehr einfache Weise. Bei einem Server, auf den Sie direkten Zugriff haben (kein Remote-Zugriff), wäre das etwa so, als würden Sie von einer Live-CD booten oder „Rettungsmodus“ aus Ihrem Startmenü auswählen.

2. Bereiten Sie die erste Festplatte (/dev/sda) zum Klonen der Daten vor.

Um sda vorzubereiten, müssen wir Partitionierungsinformationen von sdb abrufen. Eigentlich ist dieser Schritt nicht zwingend erforderlich, da unser Ziel darin besteht, das System ohne RAID-Konfiguration oder, wenn Sie dies bevorzugen, ohne jegliche Verbindung zu sdb zu booten. Wenn also das aktuelle Partitionsschema nicht unseren Wünschen entspricht, haben wir hier die Möglichkeit, es zu ändern. Das Einzige, was wir beachten müssen, ist, dass die neuen Partitionen genügend Speicherplatz haben müssen, um die Daten von sdb aufzunehmen. Die Partitionierung in Linux erfordert jedoch einiges an Wissen über Ausrichtung und dergleichen, und da sdb bereits richtig partitioniert ist, fand ich es einfacher, dasselbe in sda zu tun. Dazu müssen wir zuerst die Partitionen in sdb anzeigen, ich habe dafür parted verwendet.

Notiz:Die schwierigste Aufgabe bei der Recherche nach Linux-Befehlen ist herauszufinden, welcher (von den vielen) Befehlen am besten geeignet ist. Es gibt beispielsweise eine ganze Reihe von Partitionierungsbefehlen und -dienstprogrammen, und die Entscheidung, welchen man verwenden soll, erfordert viel Zeit beim Lesen und Vergleichen von Informationen. Ich habe mich hier für parted entschieden, weil es das Dateisystem zusammen mit den Partitionen anzeigt und weil es eine bessere Unterstützung für große Festplatten bietet? (Ich bin nicht sicher).

# parted /dev/sdb
(parted) unit s
(parted) print

Ausgabe:

Model: ATA ST3000DM001-1CH1 (scsi)
Disk /dev/sdb: 5860533168s
Sector size (logical/physical): 512B/4096B
Partition Table: msdos

Number  Start        End          Size         Type      File system  Flags
 1      2048s        25167872s    25165825s    primary
 2      25169920s    26218496s    1048577s     primary   ext3         raid
 3      26220544s    2173704192s  2147483649s  primary   ext4         raid
 4      2173706240s  5860533167s  3686826928s  extended               lba
 5      2173708288s  5860533167s  3686824880s  logical   ext4         raid

(parted) quit

Wie wir hier sehen können, hat sdb eine Partitionstabelle vom Typ msdos, das heißt, wir können bis zu 4 primäre Partitionen auf der Festplatte erstellen. In diesem Fall hat es 3 primäre Partitionen (1,2,3) und eine erweiterte (4), die eine logische Partition (5) enthält.

Der nächste Schritt besteht darin, dieselben Partitionen auf sda zu erstellen:

# parted /dev/sda
(parted) unit s
(parted) mkpart primary 2048 25167872
(parted) mkpart primary 25169920 26218496
(parted) mkpart primary 26220544 2173704192
(parted) mkpart extended 2173706240 5860533167
(parted) mkpart logical 2173708288 5860533167
(parted) quit

Wie Sie sehen, habe ich dieselben Start- und Endsektoren von SDB verwendet. Natürlich sind die Datenträger dieselben, ansonsten müssen Sie die Sektoren entsprechend anordnen.

Nun müssen wir dem System die Partitionsänderungen in sda mitteilen:

# partprobe /dev/sda

Schließlich müssen wir die Dateisysteme auf sda erstellen. Wahrscheinlich ist dieser Schritt überhaupt nicht erforderlich, da wir die Partitionen von sdb klonen werden. Der Klonvorgang kopiert daher auch die Dateisysteminformationen. Es kann jedoch nicht schaden.

# mkfs -t ext3 /dev/sda2
# mkfs -t ext4 /dev/sda3
# mkfs -t ext4 /dev/sda5

Beachten Sie, dass wir in Partition 4 (sda4) kein Dateisystem erstellt haben. Dies liegt daran, dass es sich um eine erweiterte Partition handelt, die eine logische Partition (sda5) enthält. Wir müssen das Dateisystem nur auf der logischen Partition erstellen.

Jetzt haben wir sda partitioniert und sind bereit, unsere Daten zu speichern.

3. Kopieren der Daten aus SDB.

Dieser Schritt erforderte die meiste Recherche, vor allem, weil es viele Möglichkeiten gibt, Daten zu kopieren. Wahrscheinlich würde cp -a ausreichen, aber ich konnte keine verlässlichen Informationen darüber finden, wie man mit versteckten Dateien, Links usw. umgeht, um das System richtig zu booten. Also entschied ich mich für ein Dienstprogramm zum Byte-für-Byte-Kopieren (Klonen) anstelle eines Dateikopierbefehls. Das von mir verwendete Dienstprogramm war dd:

# dd if=/dev/md1 of=/dev/sda2 bs=512 conv=noerror,sync,notrunc
# dd if=/dev/md2 of=/dev/sda3 bs=512 conv=noerror,sync,notrunc
# dd if=/dev/md3 of=/dev/sda5 bs=512 conv=noerror,sync,notrunc

Hinweise: Beachten Sie zunächst, dass wir von /dev/md* und nicht von /dev/sdb* kopieren. Dies liegt daran, dass unsere SDB-Festplatte tatsächlich Teil eines RAID-1-Arrays ist. Dies war ein weiterer Teil, zu dem ich keine verlässlichen Informationen finden konnte. Beispielsweise „sieht“ das System /dev/sdb2, /dev/sdb3 und /dev/sdb5, die Partitionen, die unsere Daten enthalten, aber laut der Datei /etc/fstab mountet es /dev/md1, /dev/md2 und /dev/md3, also nahm ich an, dass es besser ist, von /dev/md* zu kopieren. Eine weitere Sache, die Sie beachten müssen, ist, wohin auf sda Sie die Daten kopieren werden. Mit anderen Worten, wohin auf sda /dev/md1,2,3 kopiert werden muss. Nun, in diesem Fall ist es einfach, das anhand der Partitionsgrößen und Dateisysteme herauszufinden, allerdings in einem anderen Systemdf -kkann dies anzeigen, aber nicht aus dem Rettungsmodus heraus; Sie müssen normal booten, damit dies funktioniert.

Schließlich weisen wir dd mit den obigen Befehlen an, jede Partition einzeln Byte für Byte zu klonen, ohne bei Lesefehlern anzuhalten (Parameter noerror). Dies kann natürlich zu einem nicht bootfähigen System führen, wenn es einen Lesedatenfehler auf sdb gibt (was in diesem Fall der Fall ist). Bevor ich jedoch dd verwendete, verwendete ich einige Techniken, um herauszufinden, welche Dateien betroffen waren und ob es sicher war, mit dem Klonen fortzufahren. Diese Aufgabe geht über den Rahmen dieser Antwort hinaus, aber ein guter Ausgangspunkt istHier.

Ein weiterer wichtiger Punkt ist der Blockgrößenparameter (bs). Laut dd-Dokumentation sollten Sie den bs-Wert auf 512 Bytes setzen, denn wenn ein Lesefehler auftritt (und das wird er), werden nur 512 Bytes auf der Zielfestplatte „zerstört“ und nicht ein größerer Bereich, der Vorgang wird jedoch langsamer sein. Auch hier konnte ich keine verlässlichen Informationen dazu finden und wahrscheinlich hätte eine Blockgröße von 4096 Bytes die gleichen Ergebnisse.

Schließlich erzeugt dd während seines Vorgangs keine Ausgabe und es wird aufgrund der Größe der Partitionen einige Zeit dauern, bis es fertig ist. Wenn Sie sehen möchten, wo es ist, sollten Sie eine neue Konsolensitzung öffnen (in meinem Fall eine neue SSH-Remotesitzung, da ich das remote mache) und den folgenden Befehl eingeben:

# kill -USR1 $(pidof dd)

Dadurch wird dd gezwungen, seinen aktuellen Fortschritt in der ersten Konsolensitzung auszudrucken.

4. Machen Sie sda bootfähig.

Dies ist ziemlich einfach durchzuführen. Zunächst müssen Sie die erforderlichen Einhängepunkte auf sda einhängen:

# mount -t ext4 /dev/sda3 /mnt
# mount -t proc proc /mnt/proc
# mount -t sysfs sys /mnt/sys
# mount -o bind /dev /mnt/dev
# mount -t ext3 /dev/sda2 /mnt/boot

Hinweis: Der letzte Befehl ist nicht erforderlich, wenn Sie in Ihrem System keine separate Partition für /boot haben.

Als Nächstes müssen Sie Root auf der Festplatte /dev/sda werden. Derzeit sind Sie Root im Rettungssystem.

# chroot /mnt /bin/bash

Als nächstes müssen wir unsere etc/mtab-Datei aktualisieren. Ich weiß nicht wirklich, warum wir das tun sollten, ich habe es in einem anderen Rettungs-Tutorial ohne Erklärung gefunden.

# grep -v rootfs /proc/mounts > /etc/mtab

Als nächstes müssen wir GRUB in sda installieren.

# grub-install --recheck /dev/sda

Ausgabe:

Probing devices to guess BIOS drives. This may take a long time.
Installation finished. No error reported.