RAID5 komplett defekt bei fehlerhafter HDD

RedSkall

Cadet 4th Year
Registriert
Sep. 2005
Beiträge
91
Ich habe ein Raid5 mit 5 x 4TB HDDs an einem "HP Smart Array P420" Raid-Controller konfiguriert.

Das Array hat sich jetzt in kurzer Zeit bereits 2 mal verabschiedet:
Das Array ist komplett ausgefallen mit der Meldung dass alle Daten verloren sind. Habe jetzt die Festplatten untersucht und davon waren 4 OK, eine Hatte ein paar fehlerhafte Sektoren.

Waum steigt das Raid5 komplett aus wenn eine einzelne HDD ein paar defekte Sektoren hat? Das Raid ist doch wogl genau für solche Probleme wie Festplatten-Fehler und -ausfälle da!?

Danke und Gruß,
Marco
 
Bei einem Raid 5 hast du keine Datenredundanz sondern kannst die Daten nur rekonstruieren
 
  • Gefällt mir
Reaktionen: PS828 und matze313
RedSkall schrieb:
Waum steigt das Raid5 komplett aus wenn eine einzelne HDD ein paar defekte Sektoren hat? Das Raid ist doch wogl genau für solche Probleme wie Festplatten-Fehler und -ausfälle da!?
Ähm, hast du dir eigentlich vorher auch mal angesehen was RAID5 ist?! Oder hast du einfach Random irgendein RAID Level genommen? Was "Striping" ist, weißt du? Im Prinzip hast du nix anderes als RAID0 plus verteilter Parität.

Du wolltest wohl eher RAID01 oder RAID10, naja - zu spät.
 
  • Gefällt mir
Reaktionen: blackbirdone
@andredc
Bei Raid 5 kann eine Platte ausfallen ohne dass es zu Datenverlust kommt. Die Daten bleiben auch zugreifbar (sofern wirklich nur eine Platte defekt ist) und das Raid5 wird als degraded weiterlaufen. Wird die defekte Platte getauscht, werden die Daten der defekten Platte über die Parityinformationen, die auf den restlichen Platten gespeichert sind, wieder hergestellt. Solange der Reconstruct nicht fertig ist, kann jeder weitere defekt Block auf einer anderen Platte zu Datenverlust führen.
Anm.: Darum werden im professionellen Umfeld Raidlevel mit doppelten (z.B. Raid6) oder noch höheren Paritylevel verwendet.

Wenn das Raid 5 richtig funktioniert dürfte es also zu keinem Datenverlust kommen, wenn wirklich nur eine Platte ausfällt.

Ich vermute mal stark, dass sofern alles korrekt gelaufen ist, mehr passiert ist als nur defekte Blöcke auf einer Platte.

Was dazu geführt hat, ist im Nachhinein schwer zu sagen.

Cunhell
 
  • Gefällt mir
Reaktionen: .Sentinel.
Bei einem Raid 5 darf genau 1 Platte ausfallen, egal wieviel Platten in dem Raid sind.

Ich gehe davon aus das Du mehr als eine defekte Platte hast.
Je nach Plattenmodell/Hersteller führt ein pending Sektor zum Rausfall aus dem Raidverbund.

Es ist auch egal ob es Consumerplatten oder Serverplatten sind. Ein defekter Sektor auf der Platte = untauglich im Raid. Es reicht schon wenn die Platte zu lange zum remappen des Sektors braucht, dann fliegt die aus dem Raid.

Und je mehr Platten in einem Raid 5 sind desto höher wird wieder die Ausfallwahrscheinlichkeit weil die Redundanz auf einen Plattenausfall beschränkt bleibt.

Generell gilt: ein Raid ersetzt kein Backup
 
  • Gefällt mir
Reaktionen: .Sentinel. und tony_mont4n4
Denk mal der Raid Controller hat selbst ein Problem.
Ansonsten ist raid 5 kein Problem und kann einen Ausfall ab. Durch die Parität dauert das aber etwas. Beim rebuild Strom zu trennen ist allerdings eine schlechte Idee
 
@cunhell Sobald eine Platte im Raid 5 ausfällt müssen Daten rekonstruiert werden, bei 2 Platten die ausfallen hast du einen vollständigen Datenverlust. Die Daten sind auf alle Platten verteilt und da einige davon rekonstruiert werden müssen hast du auch keine Redundanz! (Wikipedia wegen dem bild)
 
Zuletzt bearbeitet:
Schön dass es dann doch noch User gibt die gute Ratschläge geben...


Folgendes habe ich gemacht:
1) Fürs Vertrauen habe ich Test-Daten auf das Raid geschrieben, Festplatte entfernt, geguckt was passiert - hatte alles wie erwartet funktioniert.

2) Anschließend habe ich meine Nutz-Daten angefangen zu kopieren, wobei der RAID-Verbund dann zwei mal in Folge abgestürzt war.

3) Fehlerdiagnose gemacht:
Laut SMART sind 4 von 5 HDDs einwandfrei. Die letzte hat schon Mängel. Auch ein Scan sagt dass die ersten 4 HDDs in Ordnung sind, die letzte hat beschädigte Sektoren.

Meine Eindruck ist dass die defekten Sektoren der letzten Festplatte (Befinden sich Anfang des zweiten drittels von HDD5) den Fehler verursacht haben. Das passt dazu dass der Fehler erst auftrat nach dem ich schon eine paar Stunden lang Daten kopiert hatte.

Im Log des RAID-Controllers standen unzählige Informationen, aber ich habe nichts zum Fehler gefunden ausser sowas wie "Fehler aufgetreten" -.- Und das wurde auch nur zum RAID-Verbund geloggt - nicht zu der fehlerhaften Festplatte.


Ich benutzer übliche consumer-platten, die sind von verschiedenen Herstellern und unterschiedlichen Herstellungs-Datum.


Das RAID-Array was ich da hab ist nochmal komplett gespiegelt (Hardware-mässig und auch räumlich getrennt) auf einem Drobo. Es geht mir an dieser Stelle ausschließlich um das Vertrauen. Was ein RAID5 bedeutet ist mir klar, aber ich möchte natürlich auch genau das haben.

Danke für den Artikel auf zdnet! Für mich steht erstmal fest dass ich nur noch höchstens 4 HDDs pro RAID-Array mache.

Meine Frage ist jetzt eigentlich:
Kann ich dem Raid-Controller trauen? Eigentlich hätte der einzelne Festplattenausfall nicht zum Datenverlust führen dürfen.


Gruß,
Marco
 
RedSkall schrieb:
Meine Frage ist jetzt eigentlich:
Kann ich dem Raid-Controller trauen? Eigentlich hätte der einzelne Festplattenausfall nicht zum Datenverlust führen dürfen.


So wie es sich anhört: eigentlich hast Du recht. Aber Desktop-Festplatten haben die Eigenschaften manchmal zulange zu warten, so dass sie vom RAID rausgekickt werden. Doofe Sache... das kann auch eine Desktop-Festplatte treffen mit guten SMART-Werten. NAS/Enterprise-Platten haben da eine andere Firmware.

Hatte mal ein ähnliches Problem mit mdadm/Software-RAID unter Linux. Seitdem verwende ich XigmaNAS (aka NAS4Free) mit ZFS. Da laufen selbst alte gammelige Desktop-Festplatten seit Jahren in ZFS-RAID-Modus Z1.. schon fast gruselig wie gut die noch laufen.
 
andredc schrieb:
@cunhell Sobald eine Platte im Raid 5 ausfällt müssen Daten rekonstruiert werden, bei 2 Platten die ausfallen hast du einen vollständigen Datenverlust. Die Daten sind auf alle Platten verteilt und da einige davon rekonstruiert werden müssen hast du auch keine Redundanz! (Wikipedia wegen dem bild)

Bei Raid5 werden die Daten und die Parity-Informationen auf allen Platten verteilt (im Gegensatz zu Raid4 bei dem es eine dedizierte Parity-Platte gibt). Fällt eine Platte aus, können die fehlenden Informationen transparent aus den gespeicherten Parity-Informationen hergestellt werden. Die Performance ist schlechter, der Zugriff aber immer noch uneingeschränkt möglich.
Die Informationen müssen aber rekonstruiert werden, damit wieder eine Platte der Raidgruppe ausfallen kann.
So lange also in einem Raid5 nur eine Platte kaputt ist, kannst Du die Daten immer noch nutzen und die kaputte Platte, sofern getauscht wird im Hintergrund wieder hergestellt. Man musst den Reconstruct NICHT abwarten bevor man die Daten wieder abrufen kann. So lange der Reconstruct nicht fertig ist oder die Platte gar noch nicht getauscht ist, läuft das Raid im Status degraded. Tritt im degraded Status allerdings nur ein weiterer Blockfehler auf den verbliebenen Platten auf, hat man Datenverlust. Darum werden eben bei professionellen NAS-Systemen
Raidkonfigurationen verwendet, die auch den Ausfall von zwei Platten oder mehr verdauen OHNE das der Zugriff
gestört ist.

Cunhell
 
RedSkall schrieb:
Waum steigt das Raid5 komplett aus wenn eine einzelne HDD ein paar defekte Sektoren hat?
Wenn man wie Du einen Hardware RAID Controller verwendet, dann muss man unbedingt HDDs mit TLER/ERC verwenden, sonst passiert früher oder später genau das was Dir hier passiert ist.

TLER steht für Time Limited Error Recovery und ist das gleiche wie Error Recovery Control (ERC) von Seagate und Command Completion Time Limit (CCTL) bei Samsung und Hitachi. Was sich unterscheidet und was man einstellen kann, ist wie lange die HDD eben versucht einen Sektor doch noch erfolgreich zu lesen, wenn das beim ersten Versuch nicht klappt. Es gibt aber ein Tool das sich WDTLER nennt und man kann es auch mit "smartctl -l scterc,70,70 <device>" einstellen, aber nicht bei allen Platten! Bei denen wo man es einstellen kann und wo es ab Werk auch meist kürzer voreingestellt ist, spricht man von HDDs die TLER / ERC / CCTL haben, bei den anderen sagt man sie hätten es nicht. Das ist der einzige Unterschied, sonst funktionieren die gleich und bei denen mit TLER kann man die Zeit höher stellen, wenn glaubt es würde so einen Unterschied machen, ob die HDD nur 7s (i.d.R. der Default bei Platten mit TLER wie der WD Red) oder z.B. 14s (Default der Green) versuchen eine problematischen Sektor doch noch zu lesen.

Die Einstellung ist aber nur für den Timeout, der darf nicht länger sein als der Timeout den das RAIDs auf Antworten der Platten wartet, da sie Platten sonst aus dem RAID fliegen. Außerdem ist es in einem echten RAID (RAID 0 ist nur ein AID 0) ja nicht tragisch, wenn ein Sektor nicht gelesen werden kann, da die Daten aus der Parity rekonstruiert werden können. Aber Hardware RAID Controller warten gewöhnlich nur 8s auf eine Antwort und werfen eine HDDs als defekt aus dem RAID, wenn diese eben nicht innerhalb dieser 8s antwortet und genau dies dürfte bei Dir passiert sein.
andredc schrieb:
Bei einem Raid 5 hast du keine Datenredundanz
Falsch, man hat bei einem RAID 5 eine einfache Redundanz. Richtig ist aber, dass RAIDs keine Backups ersetzen !
Rego schrieb:
Was verwendest Du denn für Platten?
Das ist die entscheidende Frage, ich fürchte die falschen.
Rego schrieb:
Wenn es Standard-Consumer HDDs sind, wirst Du mit diesen Platten wahrscheinlich sowieso keinen vollständigen Rebuild schaffen.

https://www.zdnet.com/article/why-raid-5-stops-working-in-2009/
Vergiss den Artikel, der ist voller Fehler wie z.B. die Aussagen mit der UBER von 1:10^14, es gibt auch Consumer HDDs mit 1:10^15 und die Formel zur Berechnung der theoretischen Wahrscheinlichkeit einer fehlerfreien Rebuilds multipliziert die Wahrscheinlichkeiten HDDs, die beträgt bei einer UBER von 1:10^14 eben (12TB-Kapazität)/12TB, bei 1:10^15 sind es (120TB-Kapazität)/120TB, da 10^14Bit etwa 12TB an Daten entsprechen.

Bei dem RAID hier wären es also bei Platten mit einer UBER von 1:10^14 dann 8/12 = 0,66667 Wahrscheinlichkeit pro Platten ihre ganze Kapazität fehlerfrei lesen zu können und dies hoch 4, also 0,1975 oder knapp unter 20%, als Wahrscheinlichkeit dass alle 4 Platten fehlerfrei gelesen werden können, wie es für ein Rebuild eines RAID 5 aus 5 HDDs bei Ausfall einer Platte nötig ist. Also schon deutlich mehr als 0, obwohl das RAID über 12TB groß ist. Bei HDDs mit einer UBER von 1:10^15 wäre es sogar 116/120 = 0,96667 pro Plkatte und 0,96667 ^4 = 0,8732 und damit über 87% Chance auf einen erfolgreichen Rebuild.

Jeweils ohne die MTBF, also die Wahrscheinlichkeit eines Komplettausfalls einer Platte während des Rebuild zu berücksichtigen, denn auch bei einer MTBF von einer Millionen Stunden und 10 Stunden für das Rebuild, ist die Gefahr eines Totalausfalls gerade 1:100.000 und im Vergleich zu dem Risiko das das Rebuild wegen eines unkorrigierbaren Lesefehlers scheitert, daher vernachlässigbar gering. Das ist bei einem RAID 6 anders, da dort die Wahrscheinlichkeit das ein Rebuild bei einer ausgefallenen HDD wegen eines unkorrigierbaren Lesefehlers minimal ist, denn es bleibt ja noch ein einfache Redundanz, damit kann das RAID bei einem Lesefehler die Daten anhand der verbliebenen Redundanz korrigieren und es ist extrem unwahrscheinlich das dabei eine zweite Platten an der gleichen Adresse ebenfalls einen unkorrigierbaren Lesefehler hat. Die UBER spielt daher beim RAID 6 keine Rolle, solange nie mehr als eine HDD ausgefallen ist.
RedSkall schrieb:
Ich benutzer übliche consumer-platten, die sind von verschiedenen Herstellern und unterschiedlichen Herstellungs-Datum.
Es gibt unterschiedliche Consumer HDDs, die billigsten wie WD Green/Blue, Seagate Desktop/Barracuda oder Toshiba P300/X300 sind einfache Desktopplatten ohne TLER und sie sind auch so kostenoptimiert, dass sie keine Vorrichtungen haben um mit den Vibrationen umzugehen die die anderen HDDs im Gehäuse erzeugen. Solche Modelle sind definitiv für diesen Einsatz untauglich! Dafür wären NAS Platten wie die WD Red, Seagate IronWolf oder Toshiba N300 haben TLER/ERC und Vorkehrungen um mit den Vibrationen umgehen zu können und sind daher für bis zu 8 HDDs pro Gehäuse zugelassen.

Also ich fürchte Du hast hier für den Einsatzzweck ungeeignete Platten verwendet, dies geht eine Weile gut und nun stehst Du vor den Konsequenzen dieser Fehlentscheidung. Datenrettung von RAIDs ist nicht einfach, es gibt aber durchaus Tool die dies können, aber erstmal brauchst Du mindestens so viel freie HDD Kapazität um die geretteten Daten dort abzuspeichern, dann beim Retten kopiert man die Daten immer auf ein anderes Laufwerk und stellt sie niemals an Ort und Stelle wieder her, denn wenn dies schiefgeht, hat man keine zweite Chance mehr.
 
  • Gefällt mir
Reaktionen: RedSkall, rocketworm, Rego und eine weitere Person
Ich habe jetzt zum austesten nen Software-RAID eingerichtet: ZFS (Z1 RAID).

Ob meine HDDs TLER/ERC unterstützen finde ich noch raus.

Meine meisten HDDs sind WD Purple. Hab nochmal nachgeschaut: Steht nicht dass sie für Servereinsatz ausgelegt sind, aber schon für hohen Workload. Werde dann mit der Zeit HDDs austauschen in vernünftige. Wenn dann die WD Red.
 
Die Software RAID dürften meist einen viel längeren Timeout für die Antwort eines HDD haben und dann ist TLER/ERC egal, denn auch HDDs ohne antworten ja dann z.B. wie die alten Green nach 14s mit einem Lesefehler, wenn sie einen Sektor nicht mehr korrekt lesen können.
 
Du hast geschrieben das Du in dem Controller-Log nichts findest, aber es müsste doch zu sehen sein welche Platte er als 'aus Verbund rausgeflogen' markiert hat. Ich würde mal einen Versuch machen und gezielt eine Platte aus dem Raid 5 rausnehmen, also im Betrieb Sata-Kabel an der Platte abziehen.
Und dann mal schauen was der Controller macht.

Bei Deinen Platten würde ich auch mal schauen ob da nicht welche mit Shingled Magnetic Recording (SMR) dabei sind. Diese Dinger machen viel schneller ärger.
 
Nene, ich hab schon im Log den Eintrag gefunden dass HDD 5 rausgeflogen war. Aber mehr (Was für ein Fehler ist passiert?) stand dort nicht.

Danke und Gruß
 
RedSkall schrieb:
hab schon im Log den Eintrag gefunden dass HDD 5 rausgeflogen war.
Das wird ja dann wohl die mit den Fehlern gewesen sein:
RedSkall schrieb:
Laut SMART sind 4 von 5 HDDs einwandfrei. Die letzte hat schon Mängel. Auch ein Scan sagt dass die ersten 4 HDDs in Ordnung sind, die letzte hat beschädigte Sektoren.
Wobei "beschädigte Sektoren" unklar ist, waren es nur schwebenden Sektoren oder wiederzugewiesene Sektoren? Schwebende Sektoren sind nicht zwangsweise beschädigt im Sinn von Schäden an der Oberfläche wo die Daten des Sektors stehen, dies kann sein, muss aber nicht. Schwebende Sektoren sind erstmal einfach nur Sektoren deren Daten nicht mehr zur ECC passen die hinter jedem Sektor steht und die mit deren Hilfe auch nicht mehr korrigiert werden können. Da die korrekten Daten nicht mehr feststellbar sind, gibt die Platte statt falscher Daten einen Lesefehler als Antwort, wenn man versucht diese schwebenden Sektoren zu lesen. Das kann auch anderen Gründe als defekte Oberflächen haben, z.B. einen Stromausfall während eines Schreibvorgang der dazu führt, dass eben nicht die ganze Daten plus der neuen ECC geschrieben wurden oder wegen eines Stoßes oder Vibrationen ist der Kopf beim Schreiben aus der Spur gekommen und hat Daten auf der Nachbarspur überschrieben. Einfache Desktopplatten sind für letzeres besonders anfällig wenn mehrere HDDs im Gehäuse arbeiten, da bei ihnen auch Sensoren um Vibrationen zu erkennen die von den anderen HDDs erzeugt werden, eingespart wurden.

Auch arbeiten HDDs nicht 100%ig und die Hersteller geben die Fehlerhäufigkeit auch in Form der UBER an, wobei eine UBER von 1:10^14 bedeutet, dass je 10^14 gelesener Bits was etwa 12TB gelesener Daten entspricht, ein Lesefehler und damit schwebender Sektor im Rahmen der Erwartungen liegt.

Die Controller merken sich die schwebenden Sektoren und prüfen die Daten nach dem erneuten Schreiben auf diese Sektoren, dann verschwinden diese einfach oder werden eben durch Reservesektoren ersetzt, wenn die Oberfläche einen Schaden hat.

RedSkall schrieb:
Aber mehr (Was für ein Fehler ist passiert?) stand dort nicht.
Braucht es auch nicht, da die Platte aus dem RAID geflogen ist, hatte sie vermutlich kein TLER und schon beim Versuch einen Sektor zu lesen der ebene nicht mehr korrekt lesbar ist, bei dem HDD dann also länger als die 8s gebraucht hat die ein HW RAID Controller üblicherweise auf eine Antwort warten, fliegt sie als defekt aus dem RAID. Meist hat die Platte dann einen schwebenden Sektor und wenn sie wirklich geschafft hat nach mehr als 8s die Daten doch noch korrekt zu lesen, dann nicht einmal das. Das sind dann die Fälle wo die Leute sich wirklich richtig wundern warum eine HDD aus dem RAID geflogen ist deren S.M.A.R.T. keinerlei Probleme zeigen.
 
Zurück
Oben