RAID 5 Ausfall nach Festplattentausch

  • Hallo zusammen,


    bei mir hat sich auf der TS-453 Pro mein RAID 5 verabschiedet, nachdem ich eine Festplatte mit entsprechenden SMART Warnungen tauschen wollte. Vielleicht hat jemand von Euch ja noch einen guten Ratschlag hierzu.


    Alles fing an, als in der NAS 2 Platten gleichzeitig angefangen haben rumzuzicken. Die vier Festplatten wurden damals zusammen gekauft, vermutlich waren hier zwei aus der selben Charge dabei...


    Naja auf jeden Fall hat die NAS zu diesem Zeitpunkt extrem an Leistung und Performance verloren. Die Festplattenaktivitätsleuchten am Gerät haben dann schließen lassen, dass drei Festplatten mit den IOP's auf die Erste warten. Die vermutete Festplatte habe ich dann herausgezogen, dann festgestellt, dass die gewohnte Performance wieder da ist, und sofort eine Ersatzfestplatte die ich noch rum liegen hatte zugeführt. Das RAID 5 wurde dann erfolgreich über die Platte in Schacht 1 wiederhergestellt.

    Da auch die Festplatte in Schacht 4 laut SMART nicht mehr auf der Höhe der Zeit war, habe ich mich dazu entschlossen auch Diese auszutauschen, nicht zuletzt weil die NAS sich seitdem öfter aufgehangen hat. Nach dem letzten "Kaltstart" war für mich ein Wechsel dann unumgänglich. Ich habe mich auf der GUI angemeldet und dort wie empfohlen erste einmal einen Konsistenzcheck durchgeführt. Nach ca. 45 Minuten wurde dieser abgeschlossen, das RAID 5 ist wieder auf Bereit gesprungen. Leider war die Weboberfläche hier wohl etwas zu schnell in der Anzeige. Als ich die vierte Festplatte dann aus dem Gehäuse gezogen habe, habe ich im wahrsten Sinne des Wortes rot in der Web GUI gesehen. Das Volume ist nicht mehr aktiv. Ein sofortiges wiedereinführen der Festplatte inklusive anschließendem Neustart lässt das Volume deaktiviert.

    Weil ich mit meinen eher bescheidenen Linux Kenntnissen ersteinmal nicht zu viel selbst frickeln wollte, habe ich bei QNAP ein Ticket aufgemacht. Als mir hier erklärt wurde, dass meine NAS Out of Support ist, habe ich mich dann doch selbst an die Fehlerbehebung gegeben.


    Folgendes habe ich unternommen:


    - Versuch das RAID 5 zu mounten ist mit dem Fehler "Not enough disks to start array" fehlgeschlagen. Laut Putty wurde die vierte Platte plötzlich als Spare Platte erkannt, wodurch mein RAID 5 plötzlich nur noch aus 2 Festplatten bestand. Die Festplatte in Schacht 1 (die erste die gewechselt wurde) wurde im Speichermanager als "Frei" deklariert.


    Jetzt kommt der Punkt an dem ich besser vorher hier gefragt hätte, denn entweder ist das RAID 5 ab jetzt für immer rasiert, oder es gibt doch noch Abhilfe:


    - Nachdem ich mit einem Linux Affinen Kollegen gesprochen und das Internet leergesucht habe, habe ich folgenden Befehl abgesetzt:


    mdadm --create /dev/md0 --level=5 --raid-devices=4 --chunk=64 /dev/sda3 missing /dev/sdc3 /dev/sdd3 --assume-clean


    Die Zuordnung von Festplattennummer (sda/sdb/sdc/sdd) zum Schacht habe ich vorher via mdadm gecheckt, sodass hier die Reihenfolge eingehalten wurde. Die "missing" Platte ist die ersetzte aus Schacht 1, die oben als Frei deklariert wurde.


    Nach dem Bestätigen der Neuerstellung konnte man über "cat /proc/mdstat" den Status des Rebuilds einsehen. Das Ganze lief dann ungefähr 4,5 Stunden.


    Das RAID 5 wurde nach der Fertigstellung natürlich nicht gemounted, im Speichermanager sehe ich nun den Status "Entladen". Das Kommandozeilentool "md_checker" zeigt mir die Ausgabe im Anhang.

    QNAP Speichermanager.PNG


    QNAP md_checker2.PNG


    Jetzt stellt sich für mich die Frage ob hier noch was zu retten ist oder nicht.


    Ich bedanke mich im Voraus und wünsche einen schönen Abend,

    Eric

  • Ganz sicher das der Rebuild des Raids abgeschlossen war ?

    Das dauert gut und gerne, je nach größe der Platten, schonmal 6-12 Stunden.

    Wenn nicht und hast einfach die andere Platte gezogen ... nunja.

    Wenn du kein Backup hast, würde ich mich mit dem Gedanken anfreunden das die wech sind.

    Mal schauen was die anderen dazu sagen.

  • Wenn ich das richtig interpretiere, dann war zuerst die HD 1 defekt, die wurde ersetzt und der Rebuild war ok.

    Du hast dann HD 4 gezogen, da Smart hier meldete das die auch bald das zeitliche segnet.


    Im Terminal ist aber jetzt das Laufwerk 2 als Fehlend markiert, hat jetzt also noch eine dritte HD ihr leben gelassen, genau in dem Moment wo du HD 4 gezogen hast?

    So sieht es für mich jedenfalls aus.


    In dem Fall hast du den inversen 6er im Lotto, 3 von 4 HDs fallen in kurzer Zeitliche Abfolge aus.


    Wenn du die am Rechner mit den Herstellertools nur lesend prüfst, was bekommst du da für Infos?


    Aber es sieht echt nicht gut aus für die Daten, da hilft wohl nur noch desaster recovery.

  • Jetzt stellt sich für mich die Frage ob hier noch was zu retten ist oder nicht.

    Definitiv nein. Du hast mit deinem Kommando ein neues RAID mit nicht exakt den selben Parametern erstellt. Es hätte den Namen md1 haben müssen. Die Platte die du als "missing" gekennzeichnet hast hätte sda3 sein müssen. Somit fehlen dir jetzt 3 Platten im RAID5 wo nur eine ausfallen darf.

    1. Platte war frei

    2. Platte hast du durch das "missing" rausgeworfen

    4. Platte war im Rebuild nach dem Ziehen


    Das mdadm create hat zudem die UID des RAID geändert, womit die Metadaten des LVM nicht mehr stimmen.

  • Hallo zusammen,


    erst einmal Danke für die Nachrichten.


    Die QNAP ist bei mir primär als Backupgerät für diverse Rechner im Haus im Einsatz, wodurch sich der entstehende Datenverlust in Grenzen hält. Trotzdem sehr ärgerlich, vor allem weil zwei Tage vorher auch noch die Festplatte von meinem Receiver abgesegnet hat, aber gut. An die Filme, etc. kommt man wieder ran. Wenn das Ganze das nächste Mal passiert, weiß ich ja wo ich jetzt hin muss.


    Es hätte den Namen md1 haben müssen.

    Ein Danke ersteinmal auch an dich für die Analyse meines Beitrags. Ich habe noch nen Screenshot von dem Tag gefunden, als mir das RAID um die Ohren geballert ist. Da steht als Name nämlich md0, weshalb ich mir hier nicht ganz erklären kann, warum hier md1 benötigt wird.



    Die Platte die du als "missing" gekennzeichnet hast hätte sda3 sein müssen.

    Auch hier möchte ich mich nochmal oben auf den Screenshot beziehen... Anscheinend habe ich das völlig fehlinterpretiert.


    kannst du die dazugehörige Ticketnummer posten?

    Aber klar, das wäre die Vorgangsnummer inklusive Namen: [#GCX-940-66396]: RAID 5 "Nicht aktiv"


    Das Ticket wurde heute geschlossen. Ironischerweise bekomme ich hier direkt eine Anfrage zu einer Umfrage über die Qualität des Supports. :/



    In dem Fall hast du den inversen 6er im Lotto, 3 von 4 HDs fallen in kurzer Zeitliche Abfolge aus.

    Da musste ich mal grinsen - mein Neujahrslos war nämlich in der Ziehung nicht unter den Gewinnern :D



    Nochmal ein dickes Danke an Euch für's lesen und bewerten.


    Viele Grüße,

    Eric

  • Da steht als Name nämlich md0

    Ok, dann war es wohl ein legacy Volume (Migration von einem anderen QNAP-NAS?)**. Das war deinen Angaben nicht zu entnehmen.

    Auch hier möchte ich mich nochmal oben auf den Screenshot beziehen...

    Dein jetzt geposteter Screenshot zeigt eine Diskreihenfolge von sdb3 - sda3 - sdc3 - sdd3 wobei sdb3 als "missing" gekennzeichnet ist.

    Entsprechend hätte der Befehl zumindest schonmal lauten müssen:

    mdadm --create /dev/md0 --level=5 --raid-devices=4 --chunk=64 missing /dev/sda3 /dev/sdc3 /dev/sdd3 --assume-clean

    Aber auch das hätte dir nichts genützt, da die md-Version des ursprünglichen RAID 0.90.00 war, während das RAID jetzt mit md-Version 1.0 erstellt wurde. Die default-Parameter unterscheiden sich aber bei den beiden Versionen. Sie hätten somit alle mit angegeben werden müssen.


    **) Grad hier gelesen TS-231P2 über Nacht mausetot , dass du tatsächlich migriert hast.

  • Das war deinen Angaben nicht zu entnehmen

    Ashes on my head, da hast du recht. Hab den Screenshot eben noch in meinem Ticket gefunden, als ich die Ticketnummer für Christian rausgesucht habe.


    Die default-Parameter unterscheiden sich aber bei den beiden Versionen. Sie hätten somit alle mit angegeben werden müssen.

    Joa das leuchtet ein. Habe vor kurzem durch die ganze Thematik diesen Artikel von Georg Schönberger über LVM Grundlagen studiert. Danach war mir quasi schon klar, dass ich etwas übereifrig war. Aber ich denke das kennt jeder neugierige ITler von sich selbst ;)


    Ich muss die ganze Thematik entsprechend als "Pech gehabt" und "ich habe wieder einiges gelernt" abstempeln.


    Danke Dir Michael nochmal für die Erläuterungen. Ich finde das immer sehr spannend, wenn ich mich mit Experten in Materien bewege, in denen ich erst Basics habe.


    Grad hier gelesen TS-231P2 über Nacht mausetot , dass du tatsächlich migriert hast.

    Lassen sich auf einem NAS Gerät mit LVM2 als Grundlage keine Legacy Volumes mehr erstellen, oder bist du einfach davon ausgegangen, dass ein Legacy Volume wegen fehlender Features nicht mehr eingesetzt wird? Ich werde ja wohl ziemlich bald wieder an diesem Punkt stehen ;)


    Danke und Gruß,

    Eric

  • Lassen sich auf einem NAS Gerät mit LVM2 als Grundlage keine Legacy Volumes mehr erstellen,

    Es lassen sich keine legacy Volumes erstellen. Selbst ein statisches Einzeldiskvolume wird als RAID1 mit einem Member im LVM abgebildet.

  • Vielen Dank für die Info.

    Ich werde mir dann die Tage neue Platten bestellen und das Ganze zum Anlass nehmen, die alte Struktur etwas umzubauen.