RAID Recovery
Nachdem letzte Woche eine von den vier Platten in meinem Desktop abgeraucht ist, habe ich heute mal geguckt, was da los ist. Und siehe da: Einer von den beiden Festplattenlüftern lief nicht, weil, Gründe. (Nachdem ich ihn zwei mal an jeweils andere Molex-Stecker angesteckt habe, lief er plötzlich wieder. Scheinbar Wackelkontakt.)
Jedenfalls: Beim Booten kriegt der Kernel eine Kriese, weil er /dev/md1 nicht mounten kann, weil er das RAID nicht zusammensetzen kann, weil mdadm: bad header magic und mdadm: kicking non-fresh sdc6 from array. Offensichtlich ist das was mit der dritten Platte nicht in Ordnung. Das Internet sagt, ich sollte mal versuchen, die Partition zu failen und zu entfernen, also: mdadm --manage /dev/md1 --fail /dev/sdc6 --remove /dev/sdc6, was Grundsätzlich nach etwas Streiterei mit mdadm auch tatsächlich funktioniert hat; und dann wieder hinzufügen, also: mdadm --manage /dev/md1 --add /dev/sdc6.
Das wiederum hat dann nicht funktioniert; stattdessen erhalte ich böse Meldungen im Kernel-Log, dass der SATA-Link resettet, nachdem bestimmte Sektoren der Platte nicht ansprechbar sind. Klingt also so, als wäre die Platte tatsächlich defekt.
Da ich das System vor, ich weiß gar nicht mehr, wie lang das her ist, zusammengesetzt habe, habe ich keinen blassen Schimmer, welche Platte sdc ist. Mit smartctl -a /dev/sdc kann man aber die Seriennummer auslesen, die zum Glück auch auf dem Label aufgedruckt ist. Stellt sich raus, es ist die dritte von unten. Schwupps, raus, "neue" Platte rein, Stecker alle wieder anschließen, und wieder hochfahren.
Mit fdisk schnell neu partitionieren, und dann mit dem obigen mdadm-Befehl die neue Partition dem Array hinzufügen... Blöd nur, dass das nicht so einfach geht, weil, Gründe. Erst mal wieder die ein --remove und dann auch mal --stop, und dann mit --assemble --scan neu zusammengesetzt. Ah, jetzt!
Aber, nix passiert? Sollte das Rebuild nicht automatisch starten, sobald das Spare hinzugefügt wird? Ein Blick in cat /proc/mdadm behauptet, es gäbe nichts zu sehen. Hm, also, mal mit -o ro gemountet, was jetzt auch geht, da das md1 jetzt nicht mehr als degraded markiert ist. Alle Dateien sind da, das ist schon mal gut. Aber warum wird das Array nicht... öhm... warum ist die Platte-Lampe denn jetzt an? Um... /proc/mdadm sagt jetzt auch, dass das Array jetzt im recovery ist. OK. Hm. Schön? Läuft? Na, dann kann ich in der Zwischenzeit - das Recovery soll fast 200 Minuten dauern - /dev/md0 wieder zusammensetzen und die Swap-Partition auch mit mkswap bearbeiten. Und was mache ich jetzt mit den restlichen 199 Minuten?!
Alles in Allem: Dafür, dass ich das noch nie machen musste und das originale Zusammensetzen des Arrays (n+1) Jahre zurück liegt, ging das doch recht schnell und problemlos. Also, "schnell". Ich mein, das Software-Array kann jetzt nichts dafür, dass die alten mechanischen Festplatten jetzt nicht unbedingt so wirklich schnell sind. (Nach so ca 5 Stunden bin ich übrigens wieder am Rechner vorbei gekommen und siehe da, das Recovery war dann auch fertig und das Reboot hat einwandfrei funktioniert.)
Jedenfalls: Beim Booten kriegt der Kernel eine Kriese, weil er /dev/md1 nicht mounten kann, weil er das RAID nicht zusammensetzen kann, weil mdadm: bad header magic und mdadm: kicking non-fresh sdc6 from array. Offensichtlich ist das was mit der dritten Platte nicht in Ordnung. Das Internet sagt, ich sollte mal versuchen, die Partition zu failen und zu entfernen, also: mdadm --manage /dev/md1 --fail /dev/sdc6 --remove /dev/sdc6, was Grundsätzlich nach etwas Streiterei mit mdadm auch tatsächlich funktioniert hat; und dann wieder hinzufügen, also: mdadm --manage /dev/md1 --add /dev/sdc6.
Das wiederum hat dann nicht funktioniert; stattdessen erhalte ich böse Meldungen im Kernel-Log, dass der SATA-Link resettet, nachdem bestimmte Sektoren der Platte nicht ansprechbar sind. Klingt also so, als wäre die Platte tatsächlich defekt.
Da ich das System vor, ich weiß gar nicht mehr, wie lang das her ist, zusammengesetzt habe, habe ich keinen blassen Schimmer, welche Platte sdc ist. Mit smartctl -a /dev/sdc kann man aber die Seriennummer auslesen, die zum Glück auch auf dem Label aufgedruckt ist. Stellt sich raus, es ist die dritte von unten. Schwupps, raus, "neue" Platte rein, Stecker alle wieder anschließen, und wieder hochfahren.
Mit fdisk schnell neu partitionieren, und dann mit dem obigen mdadm-Befehl die neue Partition dem Array hinzufügen... Blöd nur, dass das nicht so einfach geht, weil, Gründe. Erst mal wieder die ein --remove und dann auch mal --stop, und dann mit --assemble --scan neu zusammengesetzt. Ah, jetzt!
Aber, nix passiert? Sollte das Rebuild nicht automatisch starten, sobald das Spare hinzugefügt wird? Ein Blick in cat /proc/mdadm behauptet, es gäbe nichts zu sehen. Hm, also, mal mit -o ro gemountet, was jetzt auch geht, da das md1 jetzt nicht mehr als degraded markiert ist. Alle Dateien sind da, das ist schon mal gut. Aber warum wird das Array nicht... öhm... warum ist die Platte-Lampe denn jetzt an? Um... /proc/mdadm sagt jetzt auch, dass das Array jetzt im recovery ist. OK. Hm. Schön? Läuft? Na, dann kann ich in der Zwischenzeit - das Recovery soll fast 200 Minuten dauern - /dev/md0 wieder zusammensetzen und die Swap-Partition auch mit mkswap bearbeiten. Und was mache ich jetzt mit den restlichen 199 Minuten?!
Alles in Allem: Dafür, dass ich das noch nie machen musste und das originale Zusammensetzen des Arrays (n+1) Jahre zurück liegt, ging das doch recht schnell und problemlos. Also, "schnell". Ich mein, das Software-Array kann jetzt nichts dafür, dass die alten mechanischen Festplatten jetzt nicht unbedingt so wirklich schnell sind. (Nach so ca 5 Stunden bin ich übrigens wieder am Rechner vorbei gekommen und siehe da, das Recovery war dann auch fertig und das Reboot hat einwandfrei funktioniert.)
Trackbacks
Keine Trackbacks
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt