Atkatla schrieb:
Du hast dann also eine gewisse Wahrscheinlichkeit, dass auf jeder der im RAID beteiligten Festplatte irgendwo Bits liegen können, die nicht korrigierbar sind. Im Normalfall kann die Information über die Paritätsinformation des RAID5 wiedergewonnen werden. Fällt nun aber eine der Platten aus, kann dies nicht mehr sauber geschehen.
Bei einem Rebuild eines RAID 5 kann dies nicht nur "nicht mehr sauber geschehen" geschehen, sondern gar nicht, weil es in dem Moment einfach gar keine Redundanz mehr gibt. Wenn ein Sektore mehr Bitfehler hat als die ECC korrigieren kann, dann wirft die Platte einen Lesefehler aus statt korrupte Daten zu liefern. Die meisten RAID Lösungen brechen den Rebuild Vorgang dann ab, weil damit keine komplett Datenkonsistenz mehr garantiert werden kann, denn die Daten des betroffenen Sektors sind nun ja verloren und Datenkonsistenz kann nun nur noch durch das Zurückspielen des Backups erzielt werden.
Atkatla schrieb:
vor allem wenn sie alle mehr oder weniger gleichzeitig am Ende der
Badewannenkurve der Ausfallwahrscheinlichkeit angekommen sind.
Dann hätte man die HDD aber längst wechseln sollen, denn entweder sind diese nicht für die Art des Einsatzes geeignet oder schon über die 5 Jahre vom Hersteller geplanter Nutzungsdauer hinaus.
Atkatla schrieb:
Im Unternehmenseinsatz, wo korrumpierte Daten oder das komplette Wiedereinspielen Zeit und Aufwand kosten, setzt man aber auf RAID6, um diese Fehlerquellen deutlich zu reduzieren bzw. zu eliminieren.
Oder eben auf Platten wie die mit 15k rpm die sogar eine UBER von 1:10^16 haben und bei Enterprise SSDs sind 1:10^17 normal.
computerbase107 schrieb:
Um Bit-Fehlern im RAID vorzubeugen gibt es z.B. von QNAP die Anwendung RAID-Scrubbing im QTS, was regelmäßig angewendet
Das ist bei RAIDs üblich, jedes normale Enterprise Linux wird automatisch einmal im Monat (jede ist übertrieben, man sollte auch das Workload Rating der Platten nicht schon mit dem Scrubbing überziehen) für ein md SW RAID einrichten. Aber Bitfehlern beugt man damit nicht vor, sondern man will diese nur möglichst rechtzeitig erkennen und beheben, denn wenn dabei einer auffällt wird der entsprechende Sektor auf der Platte überschrieben, eben bevor ein Rebuild erforderlich ist. Solche Probleme die dann in den S.M.A.R.T. Werten können z.B. durch unerwartete Spannungsabfälle während Schreibvorgängen passieren, wenn dann der Sektor nicht komplett geschrieben werden konnte und die Daten des Sektor nicht zur ECC dahinter passen. Oder wenn die Platte beim Schreiben einen Stoß oder Vibrationen (zumal wenn sie keinen ausreichenden Schutz vor Vibrationen hat) erlitten hat und daher die Köpfe aus der Spur gekommen sind und Daten auf der Nachbarspur überschrieben wurden. Auffallen werden solche Fehler nur, wenn der Sektor dann wieder gelesen wird und damit dies eben nicht erst beim Rebuild passiert, macht man eben regelmäßig Scrubbing.
Solche Sektoren bei denen die Daten nicht zur ECC passen, sind die die man bei Einzellaufwerken dann als schwebende Sektoren in den S.M.A.R.T. Werten sieht und die sieht man bei einem echten RAID mit Redundanz eben nicht, weil das RAID die Daten mit Hilfe der Redundanz eben wiederherstellt und den Sektor überschreibt, so dass der Controller der Platte die "neuen" Daten nach dem Schreiben prüft, wenn die nicht lesbar sind dann wird ein Reservesektor an dessen Stelle verwendet und danach ist der Sektor auf jeden Fall nicht mehr schwebend.
![c[A]rm[A]](https://pics.computerbase.de/forum/avatars/m/4/4429.jpg?1531926676){kind=avatar}
