Festplatte im Software Raid austauschen


U

Unifex

New Member
Oh man, man kommt aus dem Basteln nicht mehr raus, wenn man einen Server bei Hetzner hat ;)

Ich prüfe gerade einen meinen Server im Bereich Festplatten und erhalte diese Ausgabe:

Code: 
cat /proc/mdstat

Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] [linear] [multipath]
md1 : active raid1 sda2[0]
      524224 blocks [2/1] [U_]

md2 : active raid1 sda3[0]
      114598848 blocks [2/1] [U_]

md0 : active raid1 sda1[0]
      2096064 blocks [2/1] [U_]

unused devices: <none>

Bedeutet das, dass die zweite Festplatte abgeraucht ist also sdb?

Weil irgendwie werden alle Partitionen und Festplatten auch richtig angezeigt:

Code: 
cat /proc/partitions
major minor  #blocks  name

   8        0  117220824 sda
   8        1    2096128 sda1
   8        2     524288 sda2
   8        3  114598912 sda3
   8       16  117220824 sdb
   8       17    2096128 sdb1
   8       18     524288 sdb2
   8       19  114598912 sdb3
   9        0    2096064 md0
   9        2  114598848 md2
   9        1     524224 md1

Ich bin verwirrt ;)
 
Es heißt zumindest, dass sich die Partitionen aus den RAIDs verabschiedet haben. Üblicherweise tun sie das nicht ohne Grund - vor allem nicht alle auf einmal.
Es wäre also angezeigt, die Platte austauschen zu lassen und die RAIDs anschließend mit der neuen Platte wieder aufzubauen.
 
Last edited by a moderator:
Ich kenne das sonst echt nur, wenn die kaputten Raids auch mit einem F gekennzeichnet sind. Also z.B. so :

Code: 
md0 : active raid1 sdb1[2][B](F)[/B] sda1[0]
      2096064 blocks [2/1] [U_]

Aber das F für failed wird nicht angezeigt.

Code: 
md0 : active raid1 sda1[0]
      2096064 blocks [2/1] [U_]

Wie ist das möglich?

Kann ich noch irgendwelche Tests machen, um zu schauen ob die Platte echt kaputt ist?
 
Das md-RAID loggt solche Vorfälle, du müsstest im kern.log fündig werden. Wenn die Platte nicht als defekt deklariert wurde, ist sie offenbar (ggf. kurzfristig) gar nicht mehr "anwesend" gewesen. In diesem Fall zeigt dir mdstat, dass ein Teil des RAID-Arrays schlicht fehlt.

Generell: SMART-Werte geprüft? Ohne Grund fliegt da nichts.
 
Also das ist echt merkwürdig. Folgendes habe ich gemacht:

Code: 
smartctl -H /dev/sda
smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.4.6-030406-generic] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED


smartctl -H /dev/sdb
smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.4.6-030406-generic] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

Beide festplatten scheinen okay zu sein. Nur die zweite ist aus welchen Gründen auch immer nicht im Raid eingetragen, obwohl die Partitionsdaten mit dem ersten Laufwerk übereinstimmen.


Kann ich denn jetzt ohne weiteres das Laufwerk sdb wieder ins Raid einfügen?

Also so?

Code: 
mdadm /dev/md0 -a /dev/sdb1
mdadm /dev/md1 -a /dev/sdb2
mdadm /dev/md2 -a /dev/sdb3
 
Unifex said:
Kann ich denn jetzt ohne weiteres das Laufwerk sdb wieder ins Raid einfügen?

Also so?

Code: 
mdadm /dev/md0 -a /dev/sdb1
mdadm /dev/md1 -a /dev/sdb2
mdadm /dev/md2 -a /dev/sdb3
Click to expand...


Kann mir jemand diese Frage bitte beantworten. Kann durch dieses Vorgehen etwas beschädigt werden an den Daten?
 
Unifex said:
Kann mir jemand diese Frage bitte beantworten. Kann durch dieses Vorgehen etwas beschädigt werden an den Daten?
Click to expand...
Eigentlich nicht. Das RAID "weiß", dass die verbliebenen Partitionen neuer sind als die auf der zweiten Platte. Im Zweifelsfall fallen die Partitionen wieder aus dem RAID raus. Im Worst case (wenn die zweite Platte entsprechend defekt ist) nimmt sie den Bus mit und das System stürzt ab. Da die erste Platte noch ok ist, sollte ein Reboot allerdings kein Problem sein.

Schlimmer wiegt die Tatsache, dass solange du keine gesicherte Erkenntnis hast, wieso die Platte aus den RAIDs gefallen ist, du ihr nicht mehr vertrauen kannst. Deine RAIDs sind hinterher vielleicht wieder zusammengebaut aber du hast keine verlässliche Redundanz zurück.

SMART kann da auch nur Hinweise liefern. (Zumal deinem Post nicht zu entnehmen ist, ob die Platten jemals einen extended selftest gemacht haben oder nicht.)Es sind schon genug Platten ohne einen SMART-Hinweis gestorben (meiner eigenen Erfahrung nach gefühlt mehr als solche, die sich angekündigt haben).

Platten, die sich verabschieden hinterlassen normalerweise Spuren in den Systemlogs. Die solltest du auswerten um abschätzen zu können, ob die Platte noch taugt oder nicht. Was nützt es dir, die Platte wieder zu benutzen, wenn nach drei Tagen die RAIDs wieder auseinander fallen?
 
elias5000 said:
Platten, die sich verabschieden hinterlassen normalerweise Spuren in den Systemlogs. Die solltest du auswerten um abschätzen zu können, ob die Platte noch taugt oder nicht. Was nützt es dir, die Platte wieder zu benutzen, wenn nach drei Tagen die RAIDs wieder auseinander fallen?
Click to expand...


Danke für die Antwort.

Speziell bei Hetzner ist meine Erfahrung, dass die keine Platte austauschen werden, die den Selbsstest besteht.

Warum die draussen ist, aus dem Raid ist mir ein Rätsel. Theoretisch kann das schon Monate her sein, dass das der Zustand ist.

Vielleicht wurde an dem Server ja auch alles für das Raid vorbereitet, nur der letzte Schritt nicht.

Vor drei oder vier Wochen hatte ich einen Freeze auf dem Server. Vielleicht ist es auch da passiert.

Ich werde heute Nachmittag mal so starten:

Code: 
mdadm /dev/md1 -a /dev/sdb2

Da dürfte die Replizierung oder Recovery am schnellsten gehen und somit auch zeitnah ein Fehler auftreten oder hoffentlich eben nicht.
 
So, ich habe es mal versucht aber es kam eine Meldung:

Code: 
mdadm /dev/md1 -a /dev/sdb2
mdadm: /dev/sdb2 reports being an active member for /dev/md1, but a --re-add fails.
mdadm: not performing --add as that would convert /dev/sdb2 in to a spare.
mdadm: To make this a spare, use "mdadm --zero-superblock /dev/sdb2" first.

Kann mir jemand diese Meldung bitte erklären? Was hat das zu bedeuten?

Zusatz:

Ich erhalte bei der Abfrage von md1 folgende Ausgabe:

Code: 
mdadm --detail /dev/md1
/dev/md1:
        Version : 0.90
  Creation Time : Sun Jul 15 14:28:19 2012
     Raid Level : raid1
     Array Size : 524224 (512.02 MiB 536.81 MB)
  Used Dev Size : 524224 (512.02 MiB 536.81 MB)
   Raid Devices : 2
  Total Devices : 1
Preferred Minor : 1
    Persistence : Superblock is persistent

    Update Time : Tue Jul 29 06:25:12 2014
          State : clean, degraded
 Active Devices : 1
Working Devices : 1
 Failed Devices : 0
  Spare Devices : 0

           UUID : 2e4e1746:e8cff316:776c2c25:004bd7b2
         Events : 0.995

    Number   Major   Minor   RaidDevice State
       0       8        2        0      active sync   /dev/sda2
       1       0        0        1      removed
 
Last edited by a moderator:
Unifex said:
Code: 
mdadm /dev/md1 -a /dev/sdb2
mdadm: /dev/sdb2 reports being an active member for /dev/md1, but a --re-add fails.
mdadm: not performing --add as that would convert /dev/sdb2 in to a spare.
mdadm: To make this a spare, use "mdadm --zero-superblock /dev/sdb2" first.
Kann mir jemand diese Meldung bitte erklären? Was hat das zu bedeuten?
Click to expand...

Da steht Sinngemäß: /dev/sdb2 ist der Meinung bereits Member des RAID-Verbunds zu sein, ein re-add schläg aber fehl (Vermutlich, weil das RAID selbst von sdb2 nichts mehr wissen will sondern es als removed führt).
Mit --zero-superblock kannst du die RAID-Informationen in der Partition entfernen und sie dann als neue Partition hinzufügen.
Da sdb2 sowieso aus dem RAID raus ist kannst du nicht viel kaputt machen, wenn du den Superblock entfernst.
 
elias5000 said:
Da steht Sinngemäß: /dev/sdb2 ist der Meinung bereits Member des RAID-Verbunds zu sein, ein re-add schläg aber fehl (Vermutlich, weil das RAID selbst von sdb2 nichts mehr wissen will sondern es als removed führt).
Mit --zero-superblock kannst du die RAID-Informationen in der Partition entfernen und sie dann als neue Partition hinzufügen.
Da sdb2 sowieso aus dem RAID raus ist kannst du nicht viel kaputt machen, wenn du den Superblock entfernst.
Click to expand...

Danke für die ausführliche Erklärung. Habe die Supervlocks gelöscht und dann ging es wieder.

Raid läuft jetzt wieder normal. Ich werde es die nächsten Tage genauer beobachten, ob da Auffälligkeiten sind.

Arbeiten an den Festplatten und an der Netzwerkkarte bringen mich immer ins schwitzen ;)
 
Unifex said:
Raid läuft jetzt wieder normal. Ich werde es die nächsten Tage genauer beobachten, ob da Auffälligkeiten sind.
Click to expand...
Falls noch nicht geschehen, konfiguriere dir mal smartd und mdmonitor, so dass deine Platten regelmäßig SMART-Selftests machen (ist per default nicht aktiviert) und dass du Notifications bekommst, wenn eins der RAIDs wieder Probleme bekommt.
 
elias5000 said:
und dass du Notifications bekommst, wenn eins der RAIDs wieder Probleme bekommt.
Click to expand...

Das Problem dabei ist, dass auf den Produktivservern keine Mail Dienste laufen, sondern es einen zentralen SMTP Server gibt.

So viel ich weiß, können diese Notifications nicht mit SMTP versendet werden oder doch?

Übrigens: Das Raid läuft noch ganz normal. Keine Fehler.
 
Unifex said:
So viel ich weiß, können diese Notifications nicht mit SMTP versendet werden oder doch?
Click to expand...
ssmtp wäre ein minimalst-"MTA", der eigentlich nichts weiter als eine Bridge zwischen sendmail zu einem externen MTA ist.

Wenn du gar nicht möchtest, dass Mails von dem System ausgehen, bliebe noch Monitoring des RAID über eine Software wie z.B. Nagios/NRPE (was eigentlich sowieso Pflicht ist bei einem Produktivsystem).
 
Ein etwas anderes Raid Problem bei einem Hetzner Software-Raid

Hallo liebes Forum,

Ich wollte kein neues Thema aufmachen, da mein Problem eigentlich auch in diesen Thread ganz gut passt.

Ich habe bei Hetzner einen Rootserver und mittlerweile auch schon mehrfach dort Platten tauschen müssen. Normalerweise ist das kein Problem.

  • Alte Festplatte aus dem Raid raus
  • neue Festplatte von Hetzner einbauen lassen
  • Recovery System booten
  • neuer Festplatte GPT verpassen
  • booten und die einzelnen Partitionen wieder dem Raid hinzufügen.

Diesmal klappt aber bei einer Partion der komplette Rebuild nicht mehr. Im Kern.log steht dabei folgendes:

Code: 
Oct 30 kernel: [ 8765.932461] md/raid1:md2: sda: unrecoverable I/O read error for block 780144256
Oct 30 kernel: [ 8765.932515] md: md2: recovery interrupted.
Oct 30 kernel: [ 8766.069937] RAID1 conf printout:
Oct 30 kernel: [ 8766.069939]  --- wd:1 rd:2
Oct 30 kernel: [ 8766.069941]  disk 0, wo:0, o:1, dev:sda3
Oct 30 kernel: [ 8766.069942]  disk 1, wo:1, o:1, dev:sdb3
Oct 30 kernel: [ 8766.083975] RAID1 conf printout:
Oct 30 kernel: [ 8766.083976]  --- wd:1 rd:2
Oct 30 kernel: [ 8766.083978]  disk 0, wo:0, o:1, dev:sda3

Sieht für mich aus, als ob auf der Festplatte sda ein defekter Block ist. Dummerweise ist das die Festplatte, wo momentan die Daten drauf liegen, die ich gerne auch auf sdb hätte, da sdb vorher getauscht wurde.

Kann man defekte Blöcke überspringen? Wie sollte ich am besten vorgehen?

Mit freundlichen Grüßen

Lyn
 
You must log in or register to reply here.

Back
Top