ubuntuusers.de

Ich habe hier ein eher komisches Verhalten vom Software-RAID. Erhalte seit kurzem die Meldung das eine Partition fehlerhaft ist. Also wirklich nur die Partition einer Platte und nicht die ganze Festplatte. Mein Aufbau, zwei HDDs, jeweils drei Partitionen die zu drei Software-Raids zusammengefasst wurden. md2 ist dabei als / gemountet und somit auch die kritische Stelle. Was kann diesen Fehler verursachen?

# cat /proc/mdstat 
Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md2 : active raid1 sda3[0](F) sdb3[1]
      2896184639 blocks super 1.2 [2/1] [_U]
      
md1 : active raid1 sda2[0] sdb2[1]
      524276 blocks super 1.2 [2/2] [UU]
      
md0 : active (auto-read-only) raid1 sda1[0] sdb1[1]
      33553336 blocks super 1.2 [2/2] [UU]
      
unused devices: <none>

# mdadm --detail /dev/md2
/dev/md2:
        Version : 1.2
  Creation Time : Thu Mar  1 18:33:28 2012
     Raid Level : raid1
     Array Size : 2896184639 (2762.02 GiB 2965.69 GB)
  Used Dev Size : 2896184639 (2762.02 GiB 2965.69 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

    Update Time : Sat Sep 29 16:32:16 2012
          State : active, degraded
 Active Devices : 1
Working Devices : 1
 Failed Devices : 1
  Spare Devices : 0

           Name : rescue:2
           UUID : 00c19646:ba5bc891:cb83150c:9524a610
         Events : 318263

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

       0       8        3        -      faulty spare   /dev/sda3

Sieht so aus, als ob die Partition aus dem Raid ausgestiegen ist.

Hast du dein Reassembling schon probiert?

Nein noch nicht, mach das ungern am Wochenende, wo ich nicht die Mögklichkeit habe, einen neue Platte einbauen zu lassen. Mich würde aber als Analyse interessieren, hat es wirklich nur die Partition aufgeschmissen oder ist die ganze Platte kaputt und mdadm merkt das bei nur bei md2 weil das fast die komplette Platte ausmacht und die anderen irrelevant klein sind. Denn Icinga hat seit diesem Ausfall auch kein einzigen I/O mehr verzeichnet.

Vor diesem Ausfall hatte ich lt. Aufzeichnung ca. 3 Stunden langen einen Read I/O von 120ksec/s, was schon etwas sehr viel ist.

Aus irgendeinem Grund ist die Platte jedenfalls rausgeflogen. Das kann harmlose Gründe haben (etwa wenn die Platte im Standby war und zu lange zum aufwachen gebraucht hat). Kann aber auch einfach ein Defekt sein.

Das Kernel-Log (dmesg) zum Zeitpunkt des Ausfalls wäre da aufschlussreich, oder auch ein Blick in die SMART-Daten bzw. ein langer Smart-Selftest der Platte.

frostschutz schrieb:

bzw. ein langer Smart-Selftest der Platte.

Hab ich heute ausgeführt, ist jedoch etwas kryptisch für mich: http://pastebin.ubuntu.com/1252412/. Außer den Pre-fails, die für mich nicht gut klingen ^^

Tja, die Platte ist futsch, würde ich sagen. (Reallocated Sectors, Pending Sectors und Read Failure im Selbsttest)

Leider Gottes ja, dmesg Einträge sehen auch nicht gut aus :/ http://pastebin.ubuntu.com/1252447/

Edit: So, Festplatte getauscht, resync läuft.

Damn, irgendwann bricht der resync einfach ab und die neue Platte geht auf Spare. Scheint so, als hätte es die andere Platte auch erwischt: http://pastebin.ubuntu.com/1253760/ md arbeitet beim resync zu low-level, als das ich einfach die Datei identifizieren könnte, die sich auf diesem Sektor befindet und diese einfach lösche und alles ist gut ?!?

Tja, zig Software-RAIDs haben schon einige Ausfälle bei mir überstanden, aber irgendwann kommt immer dieses eine, das total feigelt 😐

Scheint dann ein Fall für Datenrettung zu sein, mit ddrescue oder dd conv=noerror,sync. Oder eben Backup herstellen. Bei RAID ist es sehr wichtig Festplattenausfälle zeitnah mitzubekommen, daher mdadm und smartmond so einrichten, daß es regelmäßig Selbsttests fährt und bei Problemen eine Mail schickt. Und wenn eine Platte hustet, tauschen. Platten gehen nur selten zeitgleich kaputt - aber ohne Überwachung merkt man den Defekt der anderen Platte erst wenn es zu spät ist.

Wenn auf beiden Platten nur bestimmte Sektoren defekt sind, kannst du ja deren Daten von der jeweils anderne Platte holen, mit etwas Glück geht es dann ohne Datenverlust ab, sonst halt Pech gehabt... kommt drauf an was und wieviel defekt ist und wie lange die Platten schon nicht mehr synchron laufen

Daten- und Systembackup ist natürlich vorhanden. sda wurde mittlerweile schon ausgetauscht. Am laufenden System hält eigentlich nur mehr sdb die Daten, die neue sda sollte resyncen, bricht aber eben mit dieser Meldung in dmesg nach einigen Stunden (gerade eben bei ca. 26%) ab.

Zum Monitoring hatte ich ein Plugin für Nagios/Icinga, aber wie es aussieht, war dies nicht ausreichend 😐

Also um eine weitere Downtime zu vermeiden, hab ich mir folgende Vorgehensweise erdacht/ersucht:

1. ich entferne die neue /dev/sda3 aus dem Raid und formatier diese mit ext3/4

2. mounte diese unter /mnt, kopier per rsync das System und die Daten auf ext-Partition.

3. Änderung der fstab, dass / auf die neue /dev/sda3 zeigt → reboot

4. Lösche das kaputte Raid md2. aus md0 und md1 entferne ich noch die sdb-Platte

5. /dev/sdb austauschen lassen.

6. Partitionstabelle kopieren

7. Die neue Platte wieder in md0 und md1 einbinden

8. Mit folgenden Befehl wieder ein neues Raid erzeugen

    mdadm -C /dev/md2 --force --level=1 --raid-devices=2 missing /dev/sdb3

9. danach die fstab wieder umbiegen das / auf /dev/md2 zeigt → reboot

10. /dev/sda3 auf Typ fd ändern und ins Raid hinzufügen → resync und danach hoffentlich wieder ein funktionierendes RAID1

Kann mir einer der Software-RAID Experten das absegnen?

Du kannst ein RAID erstmal mit nur einer Platte machen, dort Daten drauf kopieren ; und spätere dann weitere Platten einbinden und syncen lassen. Das spart dann das Zurückkopieren der Daten da sie ja schon beim ersten Kopieren auf dem neuen RAID waren.

Wenn du die Platte direkt mit ext formatierst und dann was drauf kopierst dann ist das kein RAID und läßt sich nachträglich nur schwer zu einem machen

Ergo ein md3 (nur mit sda3) erstellen, Daten dort raufkopieren, und nach Festplattentausch die neue sdb3 dort hinzufügen. Gibt dann zwar ne Zahlenlücke, aber das sollte egal sein. Stimmt spar ich mir den Rückkopierschritt 😀

Die md-Zahlen lassen sich ändern. Entweder indem du einfach die mdadm.conf editierst, oder (dauerhafter) mit einem entsprechenden --update beim Starten des Arrays.

Wobei eine Zahlenlücke das kleinste Problem sein sollte 😊 Danke für die Hilfe, werde das heute Nacht mal angehen. 👍