Beiträge zu “Raid”

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.

20.9.18
Weitere Beiträge zu: Hetzner   Raid   Debian  

Ein neues Raid zu einem vorhandenen hinzufügen

Hier ist eigentlich nichts neues zu sehen sondern nur eine kurze Dokumentation wie ich in ein bestehendes Raidsystem zwei neue Festplatten komplett als neues Raid hinzugefügt habe. Das Vorgehen entspricht im wesentlichen dieser Beschreibung.

Was für Festplatte sollen wir nehmen

sudo fdisk -l
 Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 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
   
 Disk /dev/sdc: 1.8 TiB, 2000398934016 bytes, 3907029168 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

Das neue Raid einrichten

 sudo mdadm --create --verbose /dev/md1 --level=1 --raid-devices=2 /dev/sdc /dev/sdb

Dann muss man lange warten. Den Status sieht man mit

  more /proc/mdstat 
  Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10] 
  md1 : active raid1 sdb[1] sdc[0]
        1953383488 blocks super 1.2 [2/2] [UU]
        [===============>.....]  resync = 75.1% (1467968256/1953383488) finish=168.6min       speed=47961K/sec
        bitmap: 5/15 pages [20KB], 65536KB chunk
  
  md0 : active raid1 sdd1[1] sda1[0]
        943718336 blocks [2/2] [UU]

Damit das Raid bei jedem Booten gestartet wird braucht man noch die Konfiguration

  sudo mdadm --detail --scan
  ARRAY /dev/md0 metadata=0.90 UUID=c5136060:5454118a:b0a93c18:e5fa7b6a
  ARRAY /dev/md1 metadata=1.2 name=yourhost.yourdmain.de:1       UUID=6a9b6c56:2700b7f1:de6b9a30:ef55e827

Die letzte Zeile ist neu um muss zu /etc/mdadm/mdadm.conf hinzugefügt werden

Filesystem einrichten, Mountpoint erstellen und erst einmal mounten

  sudo mkfs.ext4 -F /dev/md1
  sudo mkdir -p /backup4
  sudo mount /dev/md1 /backup4
  df -h -x devtmpfs -x tmpfs

Das war es dann leider noch nicht. Nach dem Neustart konnte das System nicht gebooted werden und ich bin im emergency modus gelandet. Dort habe ich erstmal den /etc/fstab Eintrag auskommentiert und konnte neu booten.

Danach konnte ich feststellen das die Raid Informationen eine andere Notation hatten

 mdadm  --detail --scan 
 ARRAY /dev/md/yourost.yourdomain.de metadata=1.2 name=yourhost.yourdomain.de:1      UUID=6a9b6c56:2700b7f1:de6b9a30:ef55e827
 ARRAY /dev/md0 metadata=0.90 UUID=c5136060:5454118a:b0a93c18:e5fa7b6a

Ich habe dann diese Zeile in die /etc/mdadm/mdadmn.conf eingetragen und konnte das Raid mit

  mdadm -A -s

starten und danach auch mounten.

Am Ende half ein

   update-initramfs -u

damit /dev/md1 beim Booten automatisch gebildet wurde und über die /etc/fstab eingebunden werden konnte.

17.9.17
Weitere Beiträge zu: Debian   Raid  

Dies ist ein privater Blog von Hagen Bauer- berufstätiger Vater, Ehemann, Naturliebhaber, Läufer, Zelter, technikverliebt.


Creative Commons License
This blog is licensed under a Creative Commons License