Hallo zusammen! Ich habe 2 (USB3) Festplatten die ich als Raid 1 Linux Software Raid verwende. Bei einer der Festplatten davon beschwert sich smartd jetzt seit einer weile wegen "8 Offline uncorrectable sectors", und damit zusammenhängend ein Selftest, der deshalb fehlschlägt. Läuft aber ansonsten einwandfrei. Dazu ein paar Fragen, zu denen ich auf DuckDuckGo nichts finden konnte: Wenn eine Festplatte kaputte, nicht mehr lesbare Sektoren findet, bekommt der Kernel das dann mit, und kann Linux die verlorenen Daten mittels der anderen Festplatte dank dem Raid sofort wiederherstellen, oder merkt das Raid davon erstmals nichts, bis man was mit den Daten machen will? Sollte ich die Festplatte langsam mal auswechseln, oder warten bis sie tatsächlich ausfällt? Sie sieht mir nicht danach aus, als ob das in nächster zeit schlimmer würde. Ich weiss leider nicht, welche der 2 (baugleichen) Physischen Platten der Logischen entspricht. Ist es möglich, eine 3te Platte zum bestehenden Raid 1 hinzuzufügen, und dann erst nachdem es sich wieder ganz synchronisiert hat, eine zu entfernen? Das wäre auch praktischer, falls eine während dem Prozess ausfällt. Schon im Voraus schon mal Danke für die Hilfe.
Ich hoffe mal das du Raid 1 mirrored und nicht striped benutzt. Bei striped könnten schon jetzt Daten weg sein. mdadm sollte sich sowieso regelmässig darüber beschweren, das du dem Array keine Spare(Ersatz-)Platte zugewiesen hast. Füge also dem Array eine 3. Platte zu, die du als Spare deklarierst. md wird dann beginnen, die Platte aufzubauen. Ist es damit fertig, kannst du die defekte Platte abmelden und die Spare als Hauptplatte hinzufügen. Welche Platte defekt ist, sollte dir der SMART Status der Platten sagen. Kommandozeile dafür habe ich gerade nicht im Kopf, weil ich alles mit Webmin administriere.
:
Bearbeitet durch User
Daniel A. schrieb: > Bei einer der Festplatten davon beschwert sich smartd jetzt seit einer > weile wegen "8 Offline uncorrectable sectors", und damit zusammenhängend > ein Selftest, der deshalb fehlschlägt. Läuft aber ansonsten einwandfrei. Das fängt sich meiner Erfahrung nach nicht mehr. Früher gings mal mit Überschreiben, aber inzwischen eher nicht mehr. Schenk die Platte einem guten Freund ;) > Wenn eine Festplatte kaputte, nicht mehr lesbare Sektoren findet, > bekommt der Kernel das dann mit, und kann Linux die verlorenen Daten > mittels der anderen Festplatte dank dem Raid sofort wiederherstellen, > oder merkt das Raid davon erstmals nichts, bis man was mit den Daten > machen will? Normalerweise hat man einen Check, der da regelmässig alles liest, damit solche Zeitbomben auffallen. Ist bei Linux üblicherweise am ersten Sonntag im Monat. Wenn die Platten aus bzw. nicht immer an sind, geht das natürlich nicht. Da kann es schon sein, dass ein harter Fehler erst beim spontanen Lesen auffällt. > Sollte ich die Festplatte langsam mal auswechseln, oder warten bis sie > tatsächlich ausfällt? Sie sieht mir nicht danach aus, als ob das in > nächster zeit schlimmer würde. Kann gut gehen, muss aber nicht. Bei RAID1/5 würde ich solche Spielchen aber lassen, wenn dir die Daten wichtig sind. Bei RAID6 bin ich etwas entspannter. > Ich weiss leider nicht, welche der 2 (baugleichen) Physischen Platten > der Logischen entspricht. Ist es möglich, eine 3te Platte zum > bestehenden Raid 1 hinzuzufügen, und dann erst nachdem es sich wieder > ganz synchronisiert hat, eine zu entfernen? Das wäre auch praktischer, > falls eine während dem Prozess ausfällt. Wenn die USB-Gehäuse eine Zugriffsled haben: Einfach ein "cat /dev/sdX > /dev/null" mit der Device-ID des von smartd angemeckerten Devices machen. Da wo es dauerleuchtet, ist deine Platte ;) Du kannst beim Linux-RAID1 noch eine dritte Platte dazuhängen. Müsste in etwa so gehen: Zuerst als Spare-Disk dazu: $ mdadm --add /dev/md0 /dev/sdX Müsste in /proc/mdstat dann mit (S) aufgeführt sein. Danach das RAID auf drei Devices vergrössern: $ mdadm --grow /dev/md0 --raid-devices=3 Nach dem Sync die kaputte Platte per remove raus und mit grow wieder auf zwei Devices runtersetzen. Viel passieren kann eigentlich nicht, mdadm macht eher selten katastrophale Fehler :)
Daniel A. schrieb: > "8 Offline uncorrectable sectors" ... Läuft aber ansonsten einwandfrei. Das ist kein gutes Zeichen. Da Festplatten diverse Reservesektoren für automatische Reparatur derartiger Defekte aufweisen, bedeutet das, daß diese Festplatte keine Reservesektoren mehr hat, was eine Folge eines wachsenden Defekts ist. Die ist hin, die hats hinter sich. Festplatten dürfen keine sichtbaren Defekte haben.
Rufus Τ. F. schrieb: > Da Festplatten diverse Reservesektoren für > automatische Reparatur derartiger Defekte aufweisen, bedeutet das, daß > diese Festplatte keine Reservesektoren mehr hat, was eine Folge eines > wachsenden Defekts ist. > > Die ist hin, die hats hinter sich. > > Festplatten dürfen keine sichtbaren Defekte haben. Bist du dir da sicher? Reservesektoren sind m.W. doch erst verbraucht wenn der Reallocated Sectors Count (05) hochläuft und nicht der C5 und C6.
Danke für die ganzen Infos. Besonders Georgs Antwort hat mir extrem geholfen, da habe ich doch noch einiges gelernt, und auch der Trick die Festplatte zu finden hat wunderbar funktioniert. Ich hab mir jetzt mal eine Ersatzfestplatte bestellt, und schaue dann, ob diese hinzuzufügen dann auch so reibungsfrei läuft. Ich versuche auch mal noch ob ich für die alte die Garantie noch in Anspruch nehmen kann, die habe ich erst vor etwa 4 Monaten gekauft. Ich habe das Gefühl, je grösser die Platten, desto schneller gehen sie kaputt.
Daniel A. schrieb: > die habe ich erst vor etwa 4 Monaten gekauft. Das klingt so, als würdest du Desktop Platten im Dauerbetrieb laufen lassen. Das hält meist nicht lange. Echte NAS Platten sind dafür gedacht und die solltest du am besten auch benutzen. WD Red benutze ich, es gibt aber auch 'Iron Wolf' von Seagate usw.
:
Bearbeitet durch User
Matthias S. schrieb: > Daniel A. schrieb: >> die habe ich erst vor etwa 4 Monaten gekauft. > > Das klingt so, als würdest du Desktop Platten im Dauerbetrieb laufen > lassen. Ja, war eine "LACIE Porsche Design Desktop Drive 8 TB" Festplatte. Laut smartd ist darin eine ST8000DM004-2CX188, Seriennummer WCT0R79Z. Also eine Seagate Festplatte. > Das hält meist nicht lange. Echte NAS Platten sind dafür gedacht > und die solltest du am besten auch benutzen. WD Red benutze ich, es gibt > aber auch 'Iron Wolf' von Seagate usw. Das war halt eine der billigsten USB Festplatten. Und falls ich an die Garantie kommen sollte, könnte sich das am ende trotzdem noch lohnen.
Matthias S. schrieb: > Das klingt so, als würdest du Desktop Platten im Dauerbetrieb laufen > lassen. Das hält meist nicht lange. Wobei die Aktivität wichtiger als die reine Rotation sein dürfte. Eine Disk, die die meiste Zeit ohne Zugriffe dreht, ist thermisch weniger belastet.
A. K. schrieb: > Matthias S. schrieb: >> Das klingt so, als würdest du Desktop Platten im Dauerbetrieb laufen >> lassen. Das hält meist nicht lange. > > Wobei die Aktivität wichtiger als die reine Rotation sein dürfte. Eine > Disk, die die meiste Zeit ohne Zugriffe dreht, ist thermisch weniger > belastet. Es gibt nur ganz wenige USB-HDD-Rahmen die mit ordentlichen Lüftern ausgestattet sind. Und ohne Lüfter wird es in einem nicht klimatisierten Raum im Sommer einfach zu heiß für eine auch nur unbelastet drehende HDD. Du kannst passiv gekühlt bei einer 5400er-Platte vielleicht gerade so die Spec mit 60°C halten, aber wenn die ein paar Wochen oder einige Monate 24x7 läuft, geht es dennoch deutlich auf die Lebensdauer.
Rufus Τ. F. schrieb: > Daniel A. schrieb: >> "8 Offline uncorrectable sectors" ... Läuft aber ansonsten einwandfrei. > > Das ist kein gutes Zeichen. Da Festplatten diverse Reservesektoren für > automatische Reparatur derartiger Defekte aufweisen, bedeutet das, daß > diese Festplatte keine Reservesektoren mehr hat, was eine Folge eines > wachsenden Defekts ist. Nö, nicht unbedingt. Offline Uncorrectable gibt an, wie viele defekte Sektoren beim Offline-Selbsttest gefunden worden sind, deren Daten nicht mehr wiederhergestellt werden können. Es bedeutet also, dass Daten verloren gegangen sind, weil sie nicht rechtzeitig auf einen Reservesektor umgezogen werden konnten, aber nicht unbedingt, dass es keine Reservesektoren mehr gibt.
Unlesbare Sektoren werden erst dann auf Reservesektoren umgezogen, wenn sie neu geschrieben werden. Vorher ergibt das keinen Sinn, eben weil unlesbar.
Rolf M. schrieb: > Es bedeutet also, dass Daten verloren gegangen sind, weil sie nicht > rechtzeitig auf einen Reservesektor umgezogen werden konnten Und eine Platte, die so etwas veranstaltet, würdest Du als "noch in Ordnung" betrachten?
Rufus Τ. F. schrieb: > Und eine Platte, die so etwas veranstaltet, würdest Du als "noch in > Ordnung" betrachten? Nein. Hab ich das irgendwo geschrieben?
A. K. schrieb: > Wobei die Aktivität wichtiger als die reine Rotation sein dürfte. Eine > Disk, die die meiste Zeit ohne Zugriffe dreht, ist thermisch weniger > belastet. Seit der grossen Google Untersuchung über die Ausfallursachen von Festplatten ist relativ klar, das die Arbeitstemperatur nur eine untergeordnete Rolle spielt. Kühlere Festplatten zeigten dort keine signikfikant geringeren Ausfälle als Platten bei höheren Temperaturen. Davon ausgenommen sind sehr hohe Temperaturen. https://research.google.com/archive/disk_failures.pdf https://storagemojo.com/2007/02/19/googles-disk-failure-experience/
:
Bearbeitet durch User
Matthias S. schrieb: > Seit der grossen Google Untersuchung über die Ausfallursachen von > Festplatten ist relativ klar, das die Arbeitstemperatur nur eine > untergeordnete Rolle spielt. Kenne ich, aber irgendeinen Grund wirds schon geben, weshalb die Lebensdauer normaler PC-Festplatten für Teilzeit-Tätigkeit spezifiziert ist, bei Serverplatten aber für Vollzeit. Dass die Disk Umdrehungen oder Zugriffe zählt und irgendwann per Pseudozufall künstlich aufgibt, glaube ich nicht recht.
:
Bearbeitet durch User
Ein periodischer Temperaturwechsel der Festplatten zwischen 20 und 32°C ist nun mal weit weniger stressig als zwischen 20 und 50°C. Je höher das Temperaturdelta um so mehr häufen sich die Ausfälle. Im Dauerbetrieb ist die Änderung klein genug um wenig Probleme zu machen trotz höherer Arbeitstemperatur. Und das viele bei Desktopplatten nicht mehr aktiv diese kühlen verschärft dort das Problem.
Rolf M. schrieb: > Offline Uncorrectable gibt an, wie viele defekte Sektoren beim > Offline-Selbsttest gefunden worden sind, deren Daten nicht mehr > wiederhergestellt werden können. > Es bedeutet also, dass Daten verloren gegangen sind, weil sie nicht > rechtzeitig auf einen Reservesektor umgezogen werden konnten Genauer gesagt bedeutet es nicht mal das. Es bedeutet, daß ein Sektor bei einem Offline-Test (also ohne Leseanforderung vom Host) nicht gelesen werden konnte. Einen Datenverlust hat das nur dann zur Folge, wenn dieser Sektor vorher Daten enthalten hat. A. K. schrieb: > Unlesbare Sektoren werden erst dann auf Reservesektoren umgezogen, > wenn sie neu geschrieben werden. Vorher ergibt das keinen Sinn, eben > weil unlesbar. Tatsächlich sind diese Sektoren nicht unlesbar sondern unschreibbar. Ob sie vor dem Beschreiben lesbar waren, ist der Platte egal. Die meisten (alle?) Platten haben einen extra SMART Zähler für die Reservesektoren. Auch ohne Kenntnis der Anzahl dieser Sektoren kann man den good/bad Status verwenden, um zu erkennen ob die Reservesektoren aufgebraucht sind. So lange es noch Reservesektoren gibt, kann man den "offline uncorrectable" Zähler auch wieder auf 0 setzen, einfach indem man die Platte einmal komplett überschreibt. Um nochmal ontopic zu werden: Daniel A. schrieb: > Ist es möglich, eine 3te Platte zum > bestehenden Raid 1 hinzuzufügen, und dann erst nachdem es sich wieder > ganz synchronisiert hat, eine zu entfernen? Ja. Dafür haben hinreichend neue Linux-Kernel und mdadm Versionen die --replace Option:
1 | $man mdadm |
2 | ... |
3 | --replace |
4 | Mark listed devices as requiring replacement. As soon as a spare |
5 | is available, it will be rebuilt and will replace the marked |
6 | device. This is similar to marking a device as faulty, but the |
7 | device remains in service during the recovery process to increase |
8 | resilience against multiple failures. When the replacement |
9 | process finishes, the replaced device will be marked as faulty. |
Wenn z.B. das RAID md0 aus sdc1 und sdd1 besteht und Fehler für sdc gemeldet werden, steckt man eine weitere Platte sde an, richtet Partition sde1 in der passenden Größe ein und fügt sie dem Array als Spare hinzu:
1 | $sudo mdadm /dev/md0 --add /dev/sde1 |
wenn das erfolgreich war, markiert man die kaputte Platte entsprechend:
1 | $sudo mdadm /dev/md0 --replace /dev/sdc1 |
Jetzt wird der md-Driver alle Daten auf sde1 kopieren und sobald sdd1 und sde1 wieder ein kompletter Mirror sind, sdc1 entfernen. Den Fortschritt kann man in /proc/mdstat sehen.
1 | $watch cat /proc/mdstat |
Axel S. schrieb: > A. K. schrieb: >> Unlesbare Sektoren werden erst dann auf Reservesektoren umgezogen, >> wenn sie neu geschrieben werden. Vorher ergibt das keinen Sinn, eben >> weil unlesbar. > > Tatsächlich sind diese Sektoren nicht unlesbar sondern unschreibbar. > Ob sie vor dem Beschreiben lesbar waren, ist der Platte egal. Unlesbare sind soweit ich weiß unter Pending zu finden. Sektoren, die nicht gelesen werden können und für einen Austausch gegen einen Reservesektor vormarkiert sind. Beim nächsten Schreibvorgang verschwindet er aus "Pending" wieder und taucht als "Reallocated" auf.
Axel S. schrieb: > ... Jetzt wird der md-Driver alle Daten auf sde1 kopieren und sobald sdd1 > und sde1 wieder ein kompletter Mirror sind, sdc1 entfernen. Den > Fortschritt kann man in /proc/mdstat sehen. Hofft der Optimist. Leider ist ein komplettes kopieren der Platte auch Stress für ein STARK beschäftigtes System und die Platte. Das kann dann sehr lange dauern und während dieser Zeit sind mir auch schon weitere Platten gestorben (da sie aus der gleichen Serie stammten). Deswegen rechtzeitig kranke Platten tauschen!
oszi40 schrieb: > Axel S. schrieb: >> ... Jetzt wird der md-Driver alle Daten auf sde1 kopieren und sobald sdd1 >> und sde1 wieder ein kompletter Mirror sind, sdc1 entfernen. Den >> Fortschritt kann man in /proc/mdstat sehen. > > Hofft der Optimist. Leider ist ein komplettes kopieren der Platte auch > Stress für ein STARK beschäftigtes System und die Platte. Von stark beschädigt war nicht die Rede. > Das kann dann > sehr lange dauern und während dieser Zeit sind mir auch schon weitere > Platten gestorben (da sie aus der gleichen Serie stammten). Wie gesagt: --replace ist da schon ein Vorteil gegenüber früher, wo man nur die kaputte Platte entfernen (--fail) konnte und erst danach eine Spare (oder mit --add neu hinzugefügte) Platte ins RAID aufgenommen wurde. Mit --replace erhält man die momentane Redundanz während des Kopierprozesses. > Deswegen rechtzeitig kranke Platten tauschen! Dieser Rat ist weniger hilfreich, als er klingt. Denn das Problem besteht ja eben genau darin, eine kranke Platte überhaupt zu erkennen, bevor sie ausfällt. Der bessere Rat ist, ein RAID Level mit mehr Redundanz zu verwenden. Ich bin deswegen bei meinem letzten Server-Upgrade von RAID-5 auf RAID-6 umgestiegen. Ich habe gerade erst vor 2 Wochen eine Platte tauschen müssen. Und ich hatte nicht nur diffuse Symptome von SMART, sondern der monatliche Check des RAID meldete zum wiederholten Male, daß 8 Sektoren auf /dev/sdc korrigiert werden mußten. Aber auch ohne die defekte Platte war das RAID immer noch redundant und es hätten noch zwei weitere Platten ausfallen müssen, damit wirklich Daten verloren gegangen wären. So habe ich vorsorglich die Platte aus dem RAID genommen, ein Advance RMA [1] bei WD aufgemacht und 2 Tage später die gelieferte Ersatzplatte eingebaut. Der Resync hat knapp 16 Stunden gedauert. [1] meine Empfehlung. Man muß zwar eine Kreditkarte angeben, kriegt die neue Platte aber sofort zugeschickt und kann dann insbesondere die Versandverpackung dieser Platte für die Rücksendung der kaputten Platte benutzen. So lange man die Rücksendung innerhalb 30 Tagen schafft, kostet das auch nichts extra.
Axel S. schrieb: > Von stark beschädigt war nicht die Rede. Ich schrieb stark beschäftigt! Ein Server, der schon total ausgelastet läuft, braucht besonders lange für ein rebuild (Taaage). Deshalb frühzeitig kranke Platten tauschen bevor noch mehr sterben.
Matthias S. schrieb: > Ich hoffe mal das du Raid 1 mirrored und nicht striped benutzt. > Bei > striped könnten schon jetzt Daten weg sein. …. Raid 1 gibt es nicht striped.
Striping ist RAID 0, und streng genommen ist es eigentlich gar kein RAID, denn das R steht für "redundant".
:
Bearbeitet durch User
oszi40 schrieb: > Ich schrieb stark beschäftigt! Ein Server, der schon total ausgelastet > läuft, braucht besonders lange für ein rebuild (Taaage). Deshalb > frühzeitig kranke Platten tauschen bevor noch mehr sterben. Wobei bessere RAID Systeme eine (ggf wählbare) Lastaufteilung zwischen Rebuild und normaler Aktivität vorsehen.
:
Bearbeitet durch User
Axel S. schrieb: > Dieser Rat ist weniger hilfreich, als er klingt. Denn das Problem > besteht ja eben genau darin, eine kranke Platte überhaupt zu erkennen, > bevor sie ausfällt. Der bessere Rat ist, ein RAID Level mit mehr > Redundanz zu verwenden. Ich bin deswegen bei meinem letzten > Server-Upgrade von RAID-5 auf RAID-6 umgestiegen. Es ist ein Irrtum, dass dies zu besserer Redundanz führt, es sei denn man muss erweitern, weil der Plattenplatz nich mehr ausreicht. Jede zusätzliche Platte erhöht das Ausfallrisiko, das ist einfach logisch. Wenn der benötigte Platz auf eine Platte passt, dann ist ein Software-RAID 1 (z.B. mit mdadm) ggf. mit 1 oder 2 Spares immer noch das sicherste und am besten Platten aus verschiedenen Serien bzw. Herstellern. Ich habe auch schon erstaunlich oft ausgefallene Hardware-Controller gesehen, ich benutze seit einigen Jahren keine mehr. Regelmässige SMART-Test sind sowieso selbstverständlich (2-3 Kurztests protag, nachts ein Langtest).
Tsun schrieb: > Es ist ein Irrtum, dass dies zu besserer Redundanz führt, es sei denn > man muss erweitern, weil der Plattenplatz nich mehr ausreicht. RAID 6 hat deiner Ansicht nach nicht mehr Redundanz als RAID 5? Oder verwechselst du das mit 5 vs 6 Disks?
Tsun schrieb: > Axel S. schrieb: >> Dieser Rat ist weniger hilfreich, als er klingt. Denn das Problem >> besteht ja eben genau darin, eine kranke Platte überhaupt zu erkennen, >> bevor sie ausfällt. Der bessere Rat ist, ein RAID Level mit mehr >> Redundanz zu verwenden. Ich bin deswegen bei meinem letzten >> Server-Upgrade von RAID-5 auf RAID-6 umgestiegen. > > Es ist ein Irrtum, dass dies zu besserer Redundanz führt [ ] du hast Ahnung von RAID-Leveln > Jede zusätzliche Platte erhöht das Ausfallrisiko, das ist > einfach logisch. Ein zusätzliche Platte [1] mit einer zweiten Prüfsumme erhöht die Ausfallwahrscheinlichkeit? Komische Welt, in der du lebst. > Wenn der benötigte Platz auf eine Platte passt, dann ist ein > Software-RAID 1 (z.B. mit mdadm) ggf. mit 1 oder 2 Spares immer > noch das sicherste Nein. Es ist das billigste, nicht das sicherste. Eine Platte darf ausfallen, danach ist Ende Gelände. 2 Spares sind in jedem Fall Overkill. Aber generell ist auch eine Spare-Platte nicht notwendig ein Vorteil. Meistens will der Admin selber bestimmen, wann das RAID repariert wird. Sonst macht es die Automatik womöglich gerade zum unpassenden Zeitpunkt. > Ich habe auch schon erstaunlich oft ausgefallene Hardware-Controller > gesehen, ich benutze seit einigen Jahren keine mehr. Klar. Deswegen sind wir bei Linux md. Einen Performance-Vorteil haben Hardware RAID-Controller praktisch nur mit einem Schreibcache, der dann aber batteriegepuffert sein muß. Und das ist dann teuer ... > Regelmässige SMART-Test sind sowieso selbstverständlich (2-3 Kurztests > protag, nachts ein Langtest). Halte ich für übertrieben. Der beste Test ist sowieso die Verwendung des Speichers. Was kümmert mich, ob ein Selbsttest einen Lesefehler bei einem unbenutzen Plattenblock findet? [1] nur statistisch. Ab RAID-5 werden Parity-Informationen nicht mehr auf einer separaten Platte gespeichert, sondern stripe-weise rotierend auf allen Platten abgelegt.
oszi40 schrieb: > Axel S. schrieb: >> Von stark beschädigt war nicht die Rede. > > Ich schrieb stark beschäftigt! Sorry. Mein Fehler!
Ich habe nun die Festplatte ausgetauscht, mit der --replace option von mdadm, wie von Axel S vorgeschlagen. Hat einwandfrei funktioniert. Die alte Platte hab ich neu partitioniert & formatiert, und damit die Festplatte am Fernseher, die ausschliesslich zum temporären Aufzeichnen einer Sendung dient, ersetzt. Die vorherige hatte immer ein korruptes Dateisystem, wenn man dann endlich mal was aufzeichnen wollte. Mal sehen, ob das mit der neuen besser wird. Und wenn diese durch die Belastung endlich ganz ausfällt, ist es nicht weiter schlimm, da die sowieso nur jeweils höchstens einmal angesehen werden.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.