Software RAID1 wiederherstellen

[cc_aero]

Hallo liebe Leute,

ich habe eben bemerkt das eines meiner SW-RAID1-Arrays auf meinem Wheezy-Home-Server "degraded" ist. Die Ursache war das sich eine HDD scheinbar nicht mehr ansprechen ließ.

Nach einem Reboot des Systemes ist de HDD wieder ansprechbar - Smart-Werte sehen gut aus und zeigen keine Aufälligkeiten.

Wie gehe ich nun am besten vor, um die ausgefallene HDD wieder in mein RAID-Array hinzuzufügen?
Das Problem ist, das ich nicht weiß wie lange die HDD bereits ausgefallen ist und wieviele Daten seither angelegt wurden.

Muss ich die Daten von der "aktueller" HDD auf die ausgefallene händisch kopieren, oder kann ich die Platte einfach wieder zum Array hinzufügen und die Daten werden automatisch syncronisiert?
Zu sagen ist noch, das das Array keine Systemdaten enthält und auch nicht zum booten verwendet wird.

"mdadm -D" gibt folgendes zu dem Array aus:

root@mastertux:/dev# mdadm -D /dev/md3
/dev/md3:
        Version : 1.2
  Creation Time : Thu Sep 12 23:24:13 2013
     Raid Level : raid1
     Array Size : 1953382208 (1862.89 GiB 2000.26 GB)
  Used Dev Size : 1953382208 (1862.89 GiB 2000.26 GB)
   Raid Devices : 2
  Total Devices : 1
    Persistence : Superblock is persistent

    Update Time : Fri Mar 21 10:20:42 2014
          State : clean, degraded
 Active Devices : 1
Working Devices : 1
 Failed Devices : 0
  Spare Devices : 0

           Name : mastertux:3  (local to host mastertux)
           UUID : 628538d2:5f4da1bb:f8b79be1:1e9270fc
         Events : 24571

    Number   Major   Minor   RaidDevice State
       0       8       33        0      active sync   /dev/sdc1
       1       0        0        1      removed

Dann hab ich noch mit einem weiteren RAID1-Array ein Problem - lt. "cat /proc/mdstat" wurde es als "auto read only" markiert.

Hier die Ausgabe von "cat /proc/mdstat":

root@mastertux:/dev# cat /proc/mdstat
Personalities : [raid1]
md3 : active raid1 sdc1[0]
      1953382208 blocks super 1.2 [2/1] [U_]

md2 : active raid1 sda3[0] sdb3[1]
      482872128 blocks super 1.2 [2/2] [UU]

md1 : active (auto-read-only) raid1 sda2[0] sdb2[1]
      4878272 blocks super 1.2 [2/2] [UU]

md0 : active raid1 sda1[0] sdb1[1]
      498368 blocks super 1.2 [2/2] [UU]

unused devices: <none>

Lt. "mdadm -D" dürfte das Array allerdings in Ordnung sein:

root@mastertux:/dev# mdadm -D /dev/md2
/dev/md2:
        Version : 1.2
  Creation Time : Thu Sep 12 23:24:03 2013
     Raid Level : raid1
     Array Size : 482872128 (460.50 GiB 494.46 GB)
  Used Dev Size : 482872128 (460.50 GiB 494.46 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Fri Mar 21 10:23:51 2014
          State : clean
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           Name : mastertux:2  (local to host mastertux)
           UUID : 916a28f2:4a141dd8:6a4e532e:1cc90791
         Events : 140

    Number   Major   Minor   RaidDevice State
       0       8        3        0      active sync   /dev/sda3
       1       8       19        1      active sync   /dev/sdb3

Was hat es damit aufsich? Und wie kann ich das wieder beheben?

Viele Dank im Vorraus

 

[Twostone]

Du brauchst die Daten nicht "händisch" wieder auf die Platte zu kopieren, das kann der device mapper schon selber. Lediglich das RAID wiederherstellen und den Rebuild anstoßen, sollte er nicht schon automatisch neustarten.

Das auto-read-only ist eigentlich nichts weiter problematisches, es sollte zum ersten Schreibvorgang wieder zurück auf readwrite wechseln. tut es das nicht, versuche mdadm --readwrite /dev/md2, mache danach einen reboot und schau, ob es wieder zurück auf auto-read-only springt.

Wenn Du schon dabei bist, mach mal das Gehäuse auf und kontrolliere mal die Spannungsversorgungen für die Laufwerke. Sich spontan verabschiedende Platten hatten bei mir meist mit ausgeleierten Steckverbindern zu tun.

 

[cc_aero]

Danke schon mal für die Antwort.

Ich hab jetzt versucht die HDD wieder zum Array hinzuzufügen - Der Rebuild wird auch automatisch angestoßen. Jedoch scheint die HDD doch ein Problem zu haben.

Sobald der Rebuild zu laufen anfängt, verabschiedet sich die HDD wieder - in /var/log/messages sieht man dann auch haufenweiße fehlermeldungen zu dazu (zB "sd 5:0:0:0: [sdd] Unhandled error code" oder "ata6: hard resetting link", etc)

Daher werde ich, sobald ich wieder physikalisch bei der Maschine bin, die Kabelverbindungen checken - Stromkabel werde ich mal checken, sowie das SATA-Kabel. Könnte das auch ein Problem mit dem MoBo sein?


Das zweite "Problem"-Array manuell auf "readwrite" setzen funktioniert -> allerdings bleibt es nach einem Reboot wieder auf "auto readonly"

 

[Twostone]

Wann hast Du denn das letzte Mal Änderungen an der Hardware vorgenommen, und wann traten die ersten Fehler in Relation zu dem Zeitpunkt der Änderungen auf? Wenn die Festplatten ein paar Monate ohne Probleme liefen, ohne daß Du etwas geändert hast (und sei es nur, einen Stecker umgesteckt oder die Festplatte in einen anderen Einschub), dann kann es eher nicht an der Verkabelung liegen.

Ich hatte allerdings auch schon fehlerhafte Kabel, die ähnliche Probleme verursachten, das Problem war schlechte Kontaktgabe. Gerade bei billigen mini-SAS-Kabeln ist die Chance, ein montagsprodukt zu erhalten, recht hoch.

Es kann aber auch sein, daß sich die Steuerungselektronik der Festplatte verabschiedet. Je nach Alter und Umgebungsbedingungen kann es natürlich auch der Controller sein.

Wenn allerdings die Hardware recht neu ist und stets im klimatisierten Schrank nach Spezifikationen betrieben wurde, ist es eher unwahrscheinlich, von Montagsprodukten mal abgesehen.

Der erste Ansatz wäre, die Kabel und Verbindungen zu betrachten. Danach die Spannungen, die das Netzteil abgibt, insbesondere die 12V-Schiene für 3,5"-Platten, die 5V-Schiene für 2,5"-Platten, auch unter Lastbedingungen. Da das aber von Elektrofachkräften durchgeführt werden sollte, würde ich Dir davon abraten.

Tausche mal die Kabel durch, mal die Platten, und schaue mal, ob sich der Fehler verschleppt. Bleibt er immer auf dem gleichen Anschluß, egal welche Platte oder welches Kabel Du verwendest, wird es der Port sein. Wandert der Fehler mit dem Kabel, ist's das Kabel, hat nur diese eine Platte, egal mit welchem Kabel oder auf welchem Port, den Fehler, ist's die Platte. Diese einfachen Maßnahmen darfst Du selber durchführen.

Sinnvoll ist es, alle anderen Platten abzustöpseln und nur mit der Platte, die den Fehler hat, und einer Ersatzplatte zu testen.

Nicht vergessen, den Rechner auszuschalten, von der Netzversorgung trennen und das Netzteil entladen, bevor Du in das Gehäuse hereingreifst.

 

[cc_aero]

Die Hardware ist eigentlich relativ jung - das System wurde Oktober 2013 zusammen gestellt und ist seither ohne Unterbrechung im Dienst gewesen. An der Hardware wurde nichts verändert.

Auch die Temperaturen waren immer im grünen Bereich.

Ich hab das System jetzt mal heruntergefahren und die Kabelverbindungen gecheckt. Hat alles sehr gut ausgesehen. Ohne was ausgewechselt zu haben, hab ich das System wieder gestartet und den Rebuild des Arrays angestoßen - seit her läuft das System wieder Problem los.

Ich werde das mal weiter beobachten.