Protokoll eines Festplattenwechsels im MDM Raid
Es war mal wieder so weit. Eine Festplatte auf dem produktiven Webserver musste getauscht werden. So ein Festplattentausch in einem produktiven Web- und Mailserver ist für mich immer noch mit etwas leicht erhöhtem Blutdruck verbunden. Das letzte Mal hat es zwar ohne Probleme geklappt aber …..
Seit einiger Zeit waren recht niedrige “Gesundheitswerte” meiner ersten Festplatte gemeldet worden
smartd[626]: Device: /dev/sda [SAT], SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 63 to 64
So das ich für heute morgen ein Festplattentausch bei Hetzner beantragt habe. Sicherheitshalber habe ich auch gleich noch eine KVM Session beantragt um im Notfall direkt auf den “Bildschirm” schauen zu können. Bei der Vorgehensweise habe ich mit an diese Doku von Hetzner gehalten. Diese Dokument ist “nur” meine exakte Dokumentation für mich selber aber vielleicht hiflt was ja auch jemandem.
Der Status zu Beginn war dieser
cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md2 : active raid1 sdb3[1] sda3[2]
1073610560 blocks super 1.2 [2/2] [UU]
md3 : active raid1 sdb4[1] sda4[2]
1847478528 blocks super 1.2 [2/2] [UU]
md0 : active raid1 sdb1[1] sda1[2]
8384448 blocks super 1.2 [2/2] [UU]
md1 : active raid1 sdb2[1] sda2[2]
523968 blocks super 1.2 [2/2] [UU]
Zur Vorbereitung galt es zuerst die “altersmüde” Festplatte /dev/sda aus dem Raid zu nehmen
Schritt 1: markieren der Partitionen als “ausgefallen”
mdadm --manage /dev/md0 --fail /dev/sda1
mdadm: set /dev/sda1 faulty in /dev/md0
mdadm --manage /dev/md1 --fail /dev/sda2
mdadm: set /dev/sda2 faulty in /dev/md1
mdadm --manage /dev/md2 --fail /dev/sda3
mdadm: set /dev/sda3 faulty in /dev/md2
mdadm --manage /dev/md3 --fail /dev/sda4
mdadm: set /dev/sda4 faulty in /dev/md3
Schritt 2: Entfernen der Partitionen aus dem Raid
mdadm /dev/md0 -r /dev/sda1
mdadm: hot removed /dev/sda1 from /dev/md0
mdadm /dev/md1 -r /dev/sda2
mdadm: hot removed /dev/sda2 from /dev/md1
mdadm /dev/md2 -r /dev/sda3
mdadm: hot removed /dev/sda3 from /dev/md2
mdadm /dev/md3 -r /dev/sda4
mdadm: hot removed /dev/sda4 from /dev/md3
Wie schaut es jetzt aus?
more /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md2 : active raid1 sdb3[1]
1073610560 blocks super 1.2 [2/1] [_U]
md3 : active raid1 sdb4[1]
1847478528 blocks super 1.2 [2/1] [_U]
md0 : active raid1 sdb1[1]
8384448 blocks super 1.2 [2/1] [_U]
md1 : active raid1 sdb2[1]
523968 blocks super 1.2 [2/1] [_U]_
Pünktlich zu der vereinbarten Uhrzeit wurde mein Server gestoppt. 5 Minuten später war er wieder online.
Jetzt hat man eine leere Festplatte bei der die Partitionen von der “guten” auf die “neue” kopiert werden müssen und die Partitionen müssen dort dann neue “Nummern” bekommen
fdisk -l /dev/sda
Disk /dev/sda: 2,7 TiB, 3000592982016 bytes, 5860533168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Die Partitionen werden von der guten auf die neue Platte übertragen
sgdisk -R /dev/sda /dev/sdb
The operation has completed successfully.
(Hier war dann ein Fehler. Eigentlich hätte das auf sda gemacht werden sollen.)
sgdisk -G /dev/sdb
Warning: The kernel is still using the old partition table.
The new table will be used at the next reboot or after you
run partprobe(8) or kpartx(8)
The operation has completed successfully.
Wie schaut’s aus?
fdisk -l /dev/sda
Disk /dev/sda: 2,7 TiB, 3000592982016 bytes, 5860533168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: E6C5E876-F160-4D89-8FBF-D431C4AD1D63
Device Start End Sectors Size Type
/dev/sda1 4096 16781311 16777216 8G Linux RAID
/dev/sda2 16781312 17829887 1048576 512M Linux RAID
/dev/sda3 17829888 2165313535 2147483648 1T Linux RAID
/dev/sda4 2165313536 5860533134 3695219599 1,7T Linux RAID
/dev/sda5 2048 4095 2048 1M BIOS boot
Dann konnte ich die neuen leeren Partitionen in das Raid einfügen
mdadm --manage /dev/md0 --add /dev/sda1
mdadm: added /dev/sda1
mdadm --manage /dev/md1 --add /dev/sda2
mdadm: added /dev/sda2
mdadm --manage /dev/md2 --add /dev/sda3
mdadm: added /dev/sda3
mdadm --manage /dev/md3 --add /dev/sda4
mdadm: added /dev/sda4
Und die Synchronisation beginnt
more /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md1 : active raid1 sda2[2] sdb2[1]
523968 blocks super 1.2 [2/1] [_U]
resync=DELAYED
md3 : active raid1 sda4[2] sdb4[1]
1847478528 blocks super 1.2 [2/1] [_U]
resync=DELAYED
md2 : active raid1 sda3[2] sdb3[1]
1073610560 blocks super 1.2 [2/1] [_U]
[======>..............] recovery = 32.4% (348329536/1073610560) finish=74.7min speed=161716K/sec
md0 : active raid1 sda1[2] sdb1[1]
8384448 blocks super 1.2 [2/2] [UU]_
Irgendwann ist dann alles fertig. Bei 2,7TB hat das hier um die 8 Stunden gedauert.
Leider habe ich zwischendurch bemerkt das ich den Befehl zu Neugenerierung der Partitionsnummern vergessen habe und dann habe ich ihn auch noch auf der falschen (der gesunden) Platte ausgeführt. Da es aber um das generieren von eindeutigen IDs geht habe ich das gelassen da sich ja damit eigentlich die IDs der beiden Platten unterscheiden sollten.
Anpassungen für den Bootmanager
grub-mkdevicemap -n
grub-install /dev/sda
i386-pc wird für Ihre Plattform installiert.
installation beendet. Keine Fehler aufgetreten.
Wegen des angesprochenen Fehlers habe ich das auch noch mal für die alte Platte gemacht.
grub-install /dev/sdb
i386-pc wird für Ihre Plattform installiert.
installation beendet. Keine Fehler aufgetreten.
Da ich mir nicht sicher war ob die IDs in der Grub Konfiguration noch stimmen habe ich das auch noch mal upgedated
update-grub
GRUB-Konfigurationsdatei wird erstellt …
Linux-Abbild gefunden: /boot/vmlinuz-4.9.0-8-amd64
initrd-Abbild gefunden: /boot/initrd.img-4.9.0-8-amd64
Linux-Abbild gefunden: /boot/vmlinuz-4.9.0-7-amd64
initrd-Abbild gefunden: /boot/initrd.img-4.9.0-7-amd64
erledigt
Sicherheitshalber habe ich dann noch mal eine KVM beantragt und einen Neustart getestet (Man weiß ja nie) aber der Server hat schön neu gestartet.