Raid 6 nach Ausfall einer Platte: Wiederaufbau klappt: Danach wird Platte vom System ausgeworfen

    Hi Dennis!

    Zitat von Crazyhorse

    Aber von einem Rebuildschaden kann man nicht sprechen, denn der Prozess ist ja nichts weiter wie eine Blockkopie von vielen HDs auf eine neue.

    Ich bin mir nicht sicher, ob man bei (sehr!?) großen Arrays nicht doch von Rebuildschäden sprechen kann.


    Anbei ein Auszug aus dem Wikipedia Artikel, den ich in #11 angeführt habe:

    Zitat

    Rebuild

    [...] Die ursprüngliche Bedeutung „RAID“ [...] und dessen Priorität „Ausfallsicherheit durch Redundanz“ wandelt sich in der Praxis mehr und mehr zu einem System, dessen Priorität in der „Maximierung des zur Verfügung gestellten Speicherplatzes durch einen Verbund von günstigen Festplatten maximaler Kapazität“ liegt.

    Der ehemals kurzzeitige „Betriebszustand“ Rebuild, in dem verfügbare Hotspare-Festplatten sehr kurzfristig den Normalzustand wiederherstellen konnten, entwickelt sich dabei zu einem tagelangen Notfallszenario.

    Der verhältnismäßig lange Zeitraum unter maximaler Beanspruchung erhöht dabei das Risiko eines weiteren Hardwareausfalls oder anderer Störfälle beträchtlich.

    Der letzte, unterstrichene Absatz dürfte dann heutzutage beim Rebuild eines großen Arrays der Knackpunkt sein.


    Gruß!

    Tim

    Toll, vielen Dank für die vielen Hilfestellungen und Meinungen.


    Ich habe heute per RMA eine neue Red 8 TB bekommen und habe sie diesmal (vor dem Einbau) mit dem WD eigenen Tool dem Quick wie auch dem ausführlichen Test unterzogen.

    (Mit Schenker Core I7 hat das ca. 10 Std gedauert) : Zum Glück: Keine Fehler, alles gut.
    Nun werde ich die Platte am Freitag in das NAS einsetzen und schauen
    (und natürlich danach auch berichten), was passiert ist .
    Dauert dann allerdings, (mit dem Wissen aus den 2 vorherigen Versuchen ca. 48 Std.)
    Drückt mir mal die Daumen. :)

    Gibts hier eigentlich noch einen Unterschied und / oder eine Empfehlung zwischen:

    1) Einstecken im laufenden Betreib oder

    2) Herunterfahren, einstecken und hochfahren?

    Das ist mal wieder super ungenau!


    Was ist ein großes Raid?

    3, 4, 8, 12, 24, 40 HDs?


    Um wie viel genau wird das Risiko erhöht?

    1%, 2%, 5%, 10%, 50%, 100%?


    Bei den HD Mengen die wir hier einsetzen, also meist 2, 4, 8 HDs, spielt das noch keine so große Rolle.

    Irgendwann erwischt es eine HD, dann die zweite dann die dritte usw.


    Wer von uns hier lastet seine HDs, was die IOs angeht wirklich dauerhaft aus?

    90+% der Zeit ideln die rum.

    Wir lassen hier keine Serverfarm mit 1k VMs aufwärts drauf laufen, dafür gibts andere Hardware.

    Also lasse die Kirche mal im Dorf.


    Denn selbst, wenn man alles falsch macht, wie Blackblaze (40 Standard HDs in einem Blade, davon ca. 10 in einem Rack), sind die Ausfallraten im Rahmen.

    Gut die teile jede Datei in 16+4 Teile, müssen die aber auch, da bei den 40k HDs jeden Tag mindestens 1 stirbt.


    Im profi Bereich geht es eh in Richtung virtual hotspare.

    Hi Dennis!


    Hast Du Dir den verlinken Wikipedia Artikel angeschaut? Dort werden Deine Fragen beantwortet.


    Zitat von Crazyhorse

    Wer von uns hier lastet seine HDs, was die IOs angeht wirklich dauerhaft aus?

    90+% der Zeit ideln die rum.

    Dennis, mir geht es um den REBUILD! Und da idelt mal so gar nix rum.


    Zitat von Crazyhorse

    Denn selbst, wenn man alles falsch macht, wie Blackblaze (40 Standard HDs in einem Blade, davon ca. 10 in einem Rack), sind die Ausfallraten im Rahmen.

    Gut die teile jede Datei in 16+4 Teile, müssen die aber auch, da bei den 40k HDs jeden Tag mindestens 1 stirbt.


    Im profi Bereich geht es eh in Richtung virtual hotspare.

    Was hat das alles mit dem Thema hier - Plattenausfälle im Privatbereich - zu tun?


    Das mit der Kirche und dem Dorf gilt wohl eher für Dich.


    Gruß!

    Tim

    der von nescafegold beschriebene ablauf sieht doch so aus:

    • neue, offensichtlich gesunde ("inter check bestanden") festplatte als austauschplatte von nas akzeptiert, wiederaufbau des raid beginnt
    • wird ohne beanstandung abgeschlossen
    • auf dem raid wird gearbeitet (kopiervorgänge); keine beanstandungen währenddessen; nas wird in ruhezustand versetzt
    • nach erneuter inbetriebnahme wird die festplatte als im laufenden betrieb ausgeworfen gemeldet, mit dem folgerichtigen (!) hinweis, dass der raid nun wieder unvollständig ist

    ich denke, die drei zitierten meldungen ("finished hot-removing", "raid degraded", "disk disconnected") werden genauso ausgegeben, wenn ich im laufenden betrieb eine raid-platte von hand rausziehe. mit keinem wort geht das protokoll hier auf einen etwaigen festplattenfehler (schadhafte sektoren, schlechte smart-werte ...) ein.


    ist das aufgeführte "hot-removing" aus sicht des systems immer ein akt "höherer gewalt" (den es nur zur kenntnis nehmen und vermelden kann) oder kann das system selbst einen solchen vorgang einleiten, ohne dass die kontakte wirklich abgezogen wurden?

    daraus ergäben sich für mich die folgenden fragestellungen bzw schlussfolgerungen:

    1. wenn in der nas-terminologie damit lediglich das rein physische trennen des kontakts gemeint ist, bliebe ja nur der "wackelkontakt" -- und die frage nach fehlern auf dem datenträger stellten sich zu diesem zeitpunkt noch gar nicht -- fast zwingend müsste nescafegold dann von "verspannter" komponenten-geometrie als ursache für ein spontanes abstöpseln der platte aus- und entsprechende maßnahmen angehen ...
    2. ist, in diesem licht betrachtet, das zeitgleiche/zeitnahe vorhandensein/auftreten von festplattenfehlern -- die, wohlgemerkt und merkwürdigerweise, nicht vom system, sondern erst nachträglich mit externem werkzeug festgestellt wurden -- dann nur ein unglücklicher zufall, mit dem leider immer zu rechnen ist? dann können wir nur auf weiterhin gutes einvernehmen mit plattenherstellern hoffen und dies nescafegold als wunsch mit auf den weiteren rma-weg geben.

    natürlich wünsche ich ihm, dass mit der dritten garantie-platte die strähne abbricht ...

    Zitat von sagusch

    kann das system selbst einen solchen vorgang einleiten, ohne dass die kontakte wirklich abgezogen wurden?

    Ja, kann es und macht es auch wenn vermehrt Lese-/Schreib- oder Kommandofehler auftreten oder die Platte sich gar nicht mehr meldet.

    ohne den geringsten hinweis auf das warum auszugeben? nur lapidar: removed und disconnected?


    wenn es sich denn im vorliegenden fall so verhielte, hieße das für nescafegold, dass mit einer auch nach dem rebuild noch kerngesunden platte der fall erstmal gelöst wäre ...

    Einmal editiert, zuletzt von sagusch ()

    @ Dr. Mike:


    Vielleicht hier nochmals die Fakten:(Systemeldungen) im Verlauf,

    und passen diese Meldungen zu Deiner Einschätzung?


    Code
    541,"Information","2019-03-08","20:08:48","System","127.0.0.1","localhost","[Storage & Snapshots] Started rebuilding RAID group "1". Priority: Resync First."
555,"Information","2019-03-10","15:41:46","System","127.0.0.1","localhost","[Storage & Snapshots] Finished rebuilding RAID group "1". Volume: DataVol1."

    Im Laufe bis zur nächsten Zeile 11 Stunden im/mit neuen Raid, dann

    Code
    584,"Information","2019-03-11","03:00:11","System","127.0.0.1","localhost","[S3] System entered sleep mode." (Zeitplan)
585,"Information","2019-03-11","10:17:16","System","127.0.0.1","localhost","[S3] System resumed."
586,"Information","2019-03-11","12:00:00","System","127.0.0.1","localhost","[S3] System entered sleep mode." (Zeitplan)
587,"Information","2019-03-11","12:01:27","System","127.0.0.1","localhost","[S3] System resumed."  (per Hand aufgeweckt)

    (also keine Probleme)


    ABER JETZT:

    Code
    588,"Information","2019-03-11","12:01:56","System","127.0.0.1","localhost","[Storage & Snapshots] Finished hot-removing disk "Host: Disk 8"."
589,"Warning","2019-03-11","12:02:01","System","127.0.0.1","localhost","[Storage & Snapshots] RAID group "1" is degraded. Volume: DataVol1."
590,"Error","2019-03-11","12:02:05","System","127.0.0.1","localhost","[Hardware Status] "Host: Disk 8": Disconnected."

    Führt diese Auflistung zu neuen oder weiteren Erkentnissen/Hypothesen?
    Die Platte scheint also mit Nichten kerngesund zu sein, obwohl sie doch , zumindest nach den Auflistungen 555 oben das Raid 6 wieder aufgebaut hatte?

    Wie schon gesagt, habe neue Platte von WD bekommen, getestet mit WD Tool vor Einbau: alles GUT, und nun in 2 Tagen Einbau, da das NAS nicht bei mir steht. ICH BIN GESPANNT.
    Dann müsste ja nach SAGUSCH wirklich alles gut verlaufen - ob ich das noch erlebe? :)

    Hallo liebe Mithelfer,

    nach einem langen Wochenende und einer ganz neuen (dritte Mal !) getauschten Platte (RMA) wollte ich nun mein Raid 6 aus dem degrated Zustand wieder neu aufbauen.(SCHACHT 8 )
    Vorher ausführlicher Test mit WD TOOL anstandlos durchlaufen)

    Dies klappte, wie schon das letzte Mal zunächst alles wunderbar. Das NAS hatte alle Arbeiten anstandlos verrichtet.

    Von:

    Code
    764,"Information","2019-03-22","14:20:33","System","127.0.0.1","localhost","[Storage & Snapshots] Started rebuilding RAID group "1". Priority: Resync First."

    bis

    Code
    791,"Information","2019-03-24","09:54:40","System","127.0.0.1","localhost","[Storage & Snapshots] Finished rebuilding RAID group "1". Volume: DataVol1."

    Danach habe ich das NAS mehrmals Herunter und Heraufgefahren, in den Ruhezustand versetzt, die FP wurden ebenso mit Spin Down heruntergefahren - alles schien in Ordnung.

    Dann Smart Test durchgeführt - alles ok - Danach Kopieren und Lesen auf dem NAS:

    Code
    798,"Information","2019-03-24","16:01:41","System","127.0.0.1","localhost","[Disk S.M.A.R.T.] Host: Disk 8 Rapid Test started."
799,"Information","2019-03-24","16:03:38","System","127.0.0.1","localhost","[Disk S.M.A.R.T.] Host: Disk 8 Rapid Test result: Completed without error."

    7 Std später. nach Aufwecken aus dem Ruhezustand das wieder:

    Code
    824,"Information","2019-03-24","23:14:02","System","127.0.0.1","localhost","[Storage & Snapshots] Finished hot-removing disk "Host: Disk 8"."
825,"Warning","2019-03-24","23:14:07","System","127.0.0.1","localhost","[Storage & Snapshots] RAID group "1" is degraded. Volume: DataVol1."
826,"Error","2019-03-24","23:14:11","System","127.0.0.1","localhost","[Hardware Status] "Host: Disk 8": Disconnected."


    Woran kann es nur liegen, dass der gesamte Rebuild Prozess klappt, danach auch weitere Stunden keine Fehlermeldungen kommen, und dann immer wieder diese Fehelermeldung 824 bis 826.

    Ich habe dies nun 3 Mal mit immer neuen Platten von WD (RMA) durchgeführt.


    QNAP HOTLINE Schrieb mir "nur", dass kein Fehler auf dem Backplane zu finden sei.

    WER HAT HIER AHNUNG und kann mir irgendwie helfen?

    Das 3 HDs einen Fehler haben, die zuvor jeweils einen ausführlichen Test mit dem Herstellertool bestanden haben ist äußerst unwahrscheinlich.

    Die Konstante in dem Ganzen ist aber das NAS, bzw. die Backplane.


    Es kann aber auch ein Problem im Bereich der Firmware vorliegen, die beim aufwecken aus dem S3 nicht lange genug auf die nach und nach anlaufenden HDs wartet. Und dann eine HD fälschlicherweise aus dem Verbund schmeißt.

    Bei vielen neuen Modellen ist der Ruhezustand ja gar nicht mehr dabei, vielleicht genau aus so einem Grund (Mutmaßung meinerseits).


    Zudem sind Fehler im Bereich Backplane jetzt nicht so selten bei QNAP, je nach Modell kann man da schon fast Serienfehler vermuten.

    Wie verhält es sich über einen längeren Zeitraum, wenn du statt dem Ruhezustand das NAS runter fährst und bei Bedarf über WOL sauber bootest.

    leider hat mein frommer wunsch nach beendigung deiner pechsträhne nichts gebracht, nescafegold; allzumal es wohl überhaupt nichts mit pech zu tun hat.


    wie crazyhorse möchte ich mittlerweile den fokus auch nicht mehr auf "disk 8" als ursächliche fehlerquelle legen, sondern auf "schacht 8", also auf die schnittstelle zw platte und nas und damit auf alles, was dahinter halt so kommt (hard wie soft, platinen wie firmware). und damit läge der ball bei qnap und nicht bei wd ...


    nescafegold, aus deinen beiden letzten protokollauszügen geht hervor, dass "hot-removing" jeweils bei einer rückkehr aus dem ruhemodus erfolgte. war das auch beim ersten mal der fall? dann kann dieser sachverhalt ja auch im sinne von crazyhorse als eine art konstante gesehen und als verursacher in betracht gezogen werden.


    nun ist das aushängen der festplatte (durch was auch immer ausgelöst) das eine. das andere, mindestens genauso gravierende, sind doch die offensichtlich dabei in mitleidenschaft gezogenen festplatten (was sich dr_mike nicht vorstellen kann). sehe ich es richtig, dass du die austauschplatten jeweils vor dem anschließen einem test unterzogen hast, der immer ohne befund endete, und dann vor der rücksendung an wd wieder überprüft und dabei jedesmal sektorenfehler festgestellt hast? das besagt doch, dass die platten mit dem "hot-removing" nachteilig verändert wurden.


    eigentlich kann hier nur noch qnap helfen oder gibt es nas-betreiber, die solches oder ähnliches erlebt haben und vlt sogar lösen konnten?

    Hallo zusammen!


    Bei einer Arraygröße von 8x 8 TB ist meiner Ansicht nach bei den Software-RAIDs der QNAP in Verbindung mit einem URE-Wert der Platten von 10-14, die Wahrscheinlichkeit, dass ein Rebuild ohne direkten oder nachgelagerten Fehler über die Bühne geht, "nicht allzu groß".


    Aus der eigenen Praxis kann ich einen Fall berichten, der erst wenige Wochen zurückliegt.


    In einem RAID5 über 8x 6 TB ist eine Platte ausgefallen. Nach dem Tausch der Platte (hot-swap) ist es bei ca. 70% des Rebuild zu einem Fehler ('bad sectors') auf einer weiteren Platte gekommen.

    Nach ein wenig Recherche, habe ich mich dazu entschieden, den Rebuild nicht erneut zu versuchen und habe das RAID neu aufgesetzt (diesmal als RAID6).


    Das Neuaufsetzen ist erfolgreich verlaufen und seither sind keine Probleme mehr aufgetreten.


    Dass dieser eine Fall nicht repräsentativ ist, ist mir klar.

    Ich möchte damit nur einen weiteren Denkansatz ins Spiel bringen.


    Gruß!

    Tim

    3 Mal editiert, zuletzt von Timpov ()

    danke für diese HInweise.

    Bleiben die Frage offen:

    Wieso ist zunächst einmal alles ok - ohne Fehlermeldung nach Rebuild?

    Erst Stunden nach Abschluß, nach "Schlafen" gehen oder auch nach Herunterfahren, nach Kopieren und Lesen, dann erfolgen die Fehlermeldungen/Auswurf?


    Zu Timpuv:

    Bei mir ist immer nur die Platte 8 /Schacht 8 betroffen.

    Hi Nescafegold!


    Hm, erst durch Deinen direkten Hinweis habe ich kapiert, dass bisher immer Platte 8 betroffen ist/war. Da hätte ich besser genauer gelesen.

    Diese Tatsache macht meinen Ansatz dann sicher nicht wahrscheinlicher.


    Gruß!

    Tim

    Du könntest ja mal was testen.
    Das NAS herunterfahren -> Eine Platte von Schacht 1-7 herausnehmen und dann extern mittels 1:1 Kopie auf die vermeintlich defekte Platte kopieren.
    "Defekte Platte" in den jeweiligen Schacht setzen und booten.
    Das NAS macht hier dann keinen Rebuild, sondern fährt ganz normal hoch. Hab ich schon mehrmals getestet also ich ältere Platten gegen neuere getauscht habe ;)

    Dafür habe ich so ein externes Gerät von Lindy genommen, wo man 2 SATA Platten einstecken kann.

    Somit kannst du zumindest dann sicher die Platte ausschließen.


    Wenn auch es extrem unwahrscheinlich ist, daß es hier überhaupt noch an der Platte liegt.

    Zitat von immo2014

    NAS Kisten immer durchlaufen lassen

    … kostet dafür Geld und erhöht nicht unbedingt die Lebensdauer, besonders wenn aus "unerfindlichen Gründen" die HDD's nicht in Sleep Modus gehen …


    Meine NAS'en fahren täglich runter und werden auch mitunter nur wöchentlich gestartet, habe seit Jahren kein Problem damit.

    Hallo zusammen,

    die letzten drei Beiträge helfen mir nicht wirklich bei meinem Problem.

    Ich suche den Auslöser für:

    Code
    "Finished hot-removing disk "Host: Disk 8"

    So, nachdem ich nun eine neue RMA Platte von WD wieder (3.Mal) bekomme habe, habe ich sie zunächst mit dem WD Tool auf Fehler ausführlich getestet: Ergebnis : Keine Fehler
    Im Anschluß in den Schacht 8 (auch hier: das 3.Mal) eingeschoben.


    Zur Erinnerung:

    Ich hatte einen Raid 5, bestehend aus 4x 8 TB WD Red Platten.

    Diesen hatte ich dann, durch Einschub von 4 gleichen weiteren 8TB WD Red Platten zu einem Raid 6 erweitern wollen.

    Es wurde das Raid 6 auch vollständig aufgebaut.

    Danach habe ich kopiert, geschrieben etc, mehrmals Heruntergefahren-Hochgefahren oder auch das NAS in den Ruhezustand gebracht und wieder aufgeweckt. (ebenso mehrmals)

    Nach jeweils längerer Zeit (7 bis 10 Std) wurde immer im Schacht 8 die 8TB Platte vom System "abgestoßen":

    Code
    826,"Error","2019-03-24","23:14:11","System","127.0.0.1","localhost","[Hardware Status] "Host: Disk 8": Disconnected."
825,"Warning","2019-03-24","23:14:07","System","127.0.0.1","localhost","[Storage & Snapshots] RAID group "1" is degraded. Volume: DataVol1."
824,"Information","2019-03-24","23:14:02","System","127.0.0.1","localhost","[Storage & Snapshots] Finished hot-removing disk "Host: Disk 8"."
823,"Information","2019-03-24","23:13:30","System","127.0.0.1","localhost","[S3] System resumed."

    Die neue 3. RMA Platte von WD habe ich nun wiederum (nach Herunterfahren) eingeschoben, gebootet: das Raid 6 hat sich nach ca. 48 Stunden (ca.23 TB) wieder aufgebaut - keine Probleme ! :


    Code
    855,"Information","2019-03-26","18:49:08","System","127.0.0.1","localhost","[Storage & Snapshots] 
Finished rebuilding RAID group "1". Volume:

    Danach den ausführlichen Plattentest innerhalb des NAS durchgeführt:

    Code
    858,"Information","2019-03-27","13:40:14","System","127.0.0.1","localhost","[Disk S.M.A.R.T.] Host: Disk 8 Complete Test result: Completed without error."


    Somit habe ich die ersten 24 Std geschafft (uff), dass das Raid 6 nicht wieder durch den Ausfall der Platte8, besser gesagt, des Schachtes 8 degraded wird.

    Um zu isolieren, was den "Finished hot-removing disk" Vorgang auslöst, hier alle Tätigkeiten , die zum Ausfall geführt haben können, was ich ja nun schon 2x erleben "durfte" :


    1) Herunterfahren

    2) Booten

    3) Kopieren/Schreiben

    4) Lesen

    5) Papierkorb löschen

    ____________________________________
    6) in den Ruhezustand versetzen

    7) aus dem Ruhezustand aufwecken


    Bis auf 6) und 7) habe ich bis jetzt weitere 8 Stunden verbracht, ohne dass ich ein "removing disk" erhalten hätte.


    Meine Hypothese ist nun, ausgelöst durch die vielen hilfreichen Gedanken von Euch, dass evtl. das "in den Ruhezustand versetzen", wahrscheinlich eher "aus dem Ruhezustand Aufwecken", der Auslöser sein könnte.

    Ich werde hierzu weiter berichten, wenn ich dies einige Male durchgeführt habe.



    ICH HABE ALLERDINGS NOCH EINE FRAGE:


    Wenn eine Platte einmal mit der Meldung "Finished hot-removing disk" ausgeworfen wurde, ist es dann nicht mehr möglich (-die Daten sind doch ok auf der Platte : "Raid6 erstellt", "keine Fehler auf der Platte") diese Platte nochmals ins Raid einzubinden ohne Rebuild ?

    Oder muß man dann immer der Prozess "Rebuild" neu durchlaufen werden ?

    Wie immer vielen Dank für gute Hinweise!