Scrubbing allgemein, sowie die Notwendigkeit von Scrubbing bei RAID5

[Banned]

Eine simple gute Prüfsumme sichert Dir die Daten statistisch sicher ab bei egal wie vielen Bitfehlern (in der Praxis).

Wie kommst du darauf?

M.W. wird Hamming Code verwendet und dieser kann nur eine begrenzte Anzahl an falschen Bits erkennen und korrigieren, je nach Variante:

https://www.quora.com/How-many-errors-can-Hamming-code-detect

https://en.wikipedia.org/wiki/Hamming_code



Ist bei ECC-RAM ähnlich. Auch dieser kann nur eine begrenzte Anzahl an gekippten Bits erkennen.

Wenn dem nicht so wäre und ständig bei gerade zwei Bitfehlern pro Dateneinheit/Sektor Schluss wäre, würde ein Großteil der Kommunikationselektronik nicht funktionieren.

Und da wirfst du wiederum Sachen durcheinander. Hardware-Routing und die Speicherung in flüchtigem oder persistentem Speicher sind zwei paar Schuhe. Außerdem sind Bit Flips und Slient Data Corruption selten, und Systeme mit entsprechenden hohen Anforderungen an Datenintegrität sind natürlich mit z.B. ECC-RAM und entsprechendem Dateisystem ausgestattet.

 

[Skudrinka]

aktuell habe ich ein drittes Vollbackup

Dann lass das Raid bleiben.
So oder so.
Außer, dir ist die VErfügbarkeit wichtig, dann ist das ein anderes Thema.
Aber nichts anders, als die Verfügbarkeit zu erhöhen, macht ein Raid.

aktuell habe ich ein drittes Vollbackup

Sehr sehr löblich!

 

[GrumpyCat]

Wie bereits angemerkt wurde, haben Festplatten ja ohnehin einen ECC für jeden Sektor. Nur kann dieser eben nur eine bestimmte Anzahl an Fehlern erkennen.

Der ECC/FEC ist keine Prüfsumme und wird in der Praxis nicht zur Fehlererkennung benutzt. Als Prüfsumme kommt eher sowas wie CRC32 zum Einsatz. Kaputte Daten werden also vielleicht nicht immer von einzelnen Platten korrigiert, aber sicher erkannt.

Scrubbing dient dazu, zu erkennen, wenn Platten langsam sterben, aber auf die Daten auf diesen Platten extrem selten zugegriffen wird. In der Praxis ist das sehr häufig der Fall - wer liest schon ständig das komplette Fotoarchiv aus? Wär schon schön, wenn die 15TB-Platte nicht erst dann als defekt erkannt wird, wenn schon die 14TB Archivdaten weggegammelt sind und man sich dann komplett auf die anderen Platten im RAID verlassen muss.

 

[Banned]

Gelöscht

 

[GrumpyCat]

M.W. wird Hamming Code verwendet und dieser kann nur eine begrenzte Anzahl an falschen Bits erkennen und korrigieren

https://en.wikipedia.org/wiki/Low-density_parity-check_code ist so die letzte Sache zu dem Thema, aber was genau die Hersteller da in ihren Firmwares machen, weiß man nicht. Jedenfalls kann nicht nur ZFS an jeden Sektor eine Prüfsumme ranhängen, das ist kein Hexenwerk.

 

[Banned]

Der ECC/FEC ist keine Prüfsumme und wird in der Praxis nicht zur Fehlererkennung benutzt.

Also m.W. enthält ist der ECC darin enthalten:

https://www.quora.com/Where-is-the-CRC-checksum-in-the-HDD-sector-format

Als Prüfsumme kommt eher sowas wie CRC32 zum Einsatz. Kaputte Daten werden also vielleicht nicht immer von einzelnen Platten korrigiert, aber sicher erkannt.

Auch CRC32 kann nicht uneingeschränkt Fehler erkennen, hier gibt es ebenfalls Limitierungen:

https://stackoverflow.com/questions...n-capability-of-a-crc32-algorithm-over-a-memo

Ergänzung (9. Mai 2024)

Jedenfalls kann nicht nur ZFS an jeden Sektor eine Prüfsumme ranhängen, das ist kein Hexenwerk.

Das hatte ich ja auch nie behauptet. Klar gibt es die Sektorprüfsummen, nur sind diese eben weniger komplex bzw. fehleranfälliger als die von ZFS/Btrfs.

Btw. arbeitet ZFS mit Blöcken und nicht mit Sektoren auf Hardwareebene, wie die Firmware der Festplatte.

 

[GrumpyCat]

Klar gibt es die Sektorprüfsummen, nur sind diese eben weniger komplex bzw. fehleranfälliger als die von ZFS/Btrfs.

Sagt wer?
Und wieso sollte das so sein? Weil Festplatten etwa ohne auf den jeweiligen Anwendungszweck zugeschnittene hochoptimierte Hardware auskommen müssen und Prüfsummen so schwer zu berechnen sind?

ZFS und btrfs machen zusätzliche Prüfsummen insbesondere, um gegen andere Fehler zu schützen (defektes RAM, defekte Busse, defekte CPU, Administrationsfehler wie z.B. Schreiben am Dateisystem vorbei auf das Raw Device des RAIDs; wegen mir auch defekte HDD-Controller; aber sicher nicht, weil Prüfsummen so ein Hexenwerk wären und Festplatten-Firmwares das nicht richtig könnten). Wikipedia hat da nen Haufen Text zu.

Edit: Gerade mal nachgeschaut, ZFS benutzt auch einfach nur Fletcher bzw. SHA256. Wirklich gar kein Hexenwerk. Fletcher wurde sogar ursprünglich als weniger rechenaufwendiger Ersatz für CRC entwickelt.

 

[emulbetsup]

--Bitte die Zitierregeln beachten--

Naja, die Platten habe ich jetzt nunmal. Ich möchte nur mit der hier eingesetzten Hardware eine möglichst hohe Datensicherheit und einen möglichst hohen Komfort erreichen. Das Geld habe ich ja schon ausgegeben. Mit Plattenplatz kann ich jetzt also erstmal rumaasen. Will jetzt nur nicht durch eine unnötige Designentscheidung die "Mission" gefährden.

--Bitte die Zitierregeln beachten--

Habe jetzt das EX4100 platt gemacht und lasse es jetzt als RAID10 laufen. Wie gesagt brauche ich den Platz (noch) nicht, da die QNAP im RAID5 ohnehin nur knapp über 10TB zur Verfügung stellt. Der Beitrag hat mich hier aber abgeholt, da ich mir die Frage mit dem initialen Sync auch schon gestellt hatte.

 

[Banned]

weil Prüfsummen so ein Hexenwerk wären

Nein, sie sind kein Hexenwerk, aber erfordern je nach Komplexität eben mehr Rechenleistung und Platz.

Edit: Gerade mal nachgeschaut, ZFS benutzt auch einfach nur Fletcher bzw. SHA256.

Und du willst jetzt nicht einsehen, dass es einen Unterschied bei Komplexität und Platzbedarf zwischen CRC32 und SHA256 gibt?
Je nach Komplexität und Bit-Anzahl ist eben auch die Fehlererkennung besser. Du hattest ja behauptet, CRC32 könne jegliche Fehler erkennen, aber dem ist eben nicht so:

https://stackoverflow.com/questions...n-capability-of-a-crc32-algorithm-over-a-memo


Wenn CRC32 in jedem Fall ausreichen würde, bräuchte man keine Alternativen. CRC32 bietet sich in vielen Fällen an, weil es eine relativ hohe Erkennungsrate bei gleichzeitig wenig benötigter Rechenleistung und Platz hat.

Fletcher wurde sogar ursprünglich als weniger rechenaufwendiger Ersatz für CRC entwickelt.

"Ursprünglich" heißt was in dem Zusammenhang hier in Bezug auf CRC32 vs. SHA256 bzw. hat welche Aussagekraft? Außerdem ist SHA1 halt ungleich SHA256. Auf ner Festplatte macht es alleine von der Kapazität her schon einen großen Unterschied, ob 32Bit oder 256Bit pro Sektor für die Prüfsummenberechnung verwendet werden.

 

[GrumpyCat]

Ich schrieb "eher sowas wie CRC32" (um Dir den Unterschied zwischen ECC wie Hamming und Prüfsummen klarzumachen) und "in der Praxis" (werden von den in Platten benutzten Prüfsummen, deren genauer Typ firmenspezifisch und nicht dokumentiert ist, alle Fehler erkannt und dann ggf. auch als Read Errors gemeldet). Von SHA1 habe ich gar nichts geschrieben.

Ich habe gestern auch nochmal gesucht, ob es irgendeinen Fall im Netz gibt, bei dem jemand von verifiziert korrekt geschriebenen Daten berichtet, die später ohne Read Error, aber defekt zurückgelesen werden (ob jetzt ZFS-Prüfsummenfehler oder z.B. defektes ZIP ist ja egal). Nix gefunden (also natürlich abseits von Noob-Foren etc.). Z.B. im Backblaze-Zuverlässigkeitsbericht gibt's auch kein Wort zu sowas, obwohl solche Fälle wenn sie denn existierten sicher festplattenherstellerspezifisch und sehr relevant wären.

Wir können uns aber einfach darauf einigen, dass Prüfsummen im Dateisystem auf jeden Fall sinnvoll sind, wenn wir auch nicht zu den Gründen dafür übereinstimmen.

 

[emulbetsup]

Wenn CRC32 in jedem Fall ausreichen würde, bräuchte man keine Alternativen. CRC32 bietet sich in vielen Fällen an, weil es eine relativ hohe Erkennungsrate bei gleichzeitig wenig benötigter Rechenleistung und Platz hat.

Zu CRC32 und seinen Grenzen kann ich etwas beitragen. Im Podcast CRE141 IPv4 oder CRE197 IPv6 ging es unter anderem genau um das Thema. CRC32 ist gut gekippte Bitkolonen zu erkennen, so wie sie bei Fehlern auf Layer 1 vorkommen. CRC32 hat aber seine Grenzen, weswegen die MTU bei Jumbo-Frames nicht deutlich über 9000 angehoben werden sollte.

 

[Banned]

alle Fehler erkannt

Nein, eben nicht! Warum willst du nicht einsehen, dass bestimmte Prüfverfahren unterschiedliche Möglichkeiten haben, was Fehler-Korrektur und -Erkennung anbelangt?

Kannst du auch hier z.B. nachlesen:

https://www.quora.com/Is-it-possibl...-of-data-and-CRC-are-inverted-but-it-looks-OK

https://en.wikipedia.org/wiki/Cyclic_redundancy_check


Je nach Länge der Datensequenz und des verwendeten Prüfverfahrens, gibt es hier unterschiedliche Erkennungsraten.

Wenn du das nicht einsehen willst, dann brauchen wir hier wirklich nicht weiterdiskutieren.


Bei Netzwerkkommunikation o.Ä., wo Daten zu einem bestimmten Zeitpunkt transferiert werden, bietet sich so ein ziemlich hoher Schutz durch CRC32. Das ist aber eben nicht vergleichbar mit Daten, die u.U. viele Jahre auf einem Datenträger liegen. Hier können sich im Rahmen von Silent Data Corruption über die Zeit mehrere Fehler kumulieren und unterschiedliche Fehlerbilder größeren Ausmaßes auftreten.

 

[Piktogramm]

Danke, für die viele Resonanz. Sehe ich das also richtig, dass ich auf dem EX4100 im RAID10 besser fahre, wenn ich auf den Speicherplatz verzichten kann. Würde das "Silent Data Corruption" unwahrscheinlicher machen, als bei einem RAID5 ohne Scrubbing? Wie gesagt, aktuell habe ich ein drittes Vollbackup

Da du in deinem eigenem Thread ignoriert wirst:
Egal welches Raidlevel und egal ob überhaupt Raid zum Einsatz kommt. Es sollte regelmäßig ein Selbsttest stattfinden. Bei einzelnen Laufwerken also ein Dateisystemcheck und bei Raidleveln Scrubbing. Genauso wie bei Backups die Backups und vor allem deren Wiederherstellbarkeit regelmäßig geprüft gehören!
Ein Raid10 hat rechnerisch eine kleinere Ausfallwahrscheinlichkeit als ein Raid5, aber das zählt fast nur für die Betriebssicherheit. Für die Sicherheit der Daten bringt das nur bedingt etwas, gerade auf einem NAS sind die Daten ja tendenziell immer irgendwie Erreichbar. Ransomware oder Nutzerfehler können da die Daten ja immer noch beeinflussen.

 

[Banned]

Ein Raid10 hat rechnerisch eine kleinere Ausfallwahrscheinlichkeit als ein Raid5,

Außer wenn der blöde Fall eintritt, dass genau zwei HDDs aussteigen, die aufeinander gespiegelt werden.

RAID10 ist in meinen Augen wirklich keine gute Wahl, außer man will möglichst hohe Schreibgeschwindigkeit auf die Datenträger.
Man verliert 50% der Gesamtkapazität an die Redundanz, und ist außerdem, anders als z.B. mit RAID6 (was immer nur zwei Platten für die Parität braucht), nicht vor einem URE beim Rebuild geschützt, wenn eine Platte ausfällt.

Ohne den Vorteil von RAID6 und ohne die Möglichkeit des Scrubbing, würde ich es mir gut überlegen, ob ich 50% Kapazität verschenken will, oder doch lieber RAID5 nehme.

Ist bei dir schließlich ohnehin schon das Backup. Fehler beim Lesen werden so oder so dann über den ECC korrigiert, wenn möglich, und irgendeine Statusanzeige wird das Teil von WD doch wahrscheinlich haben.

 

[Piktogramm]

@Banned
WAHRSCHEINLICHKEIT steht da. Wahrscheinlichkeiten sind immer statistische Werte, die nur sehr bedingte Aussagen zu konkreten, vereinzelten Gegebenheiten wie du eines beschreibst. An der Wahrscheinlichkeit über eine (große) Menge ändert sich entsprechend überhaupt nichts.

Und Pauschal stimmt es nicht, dass Scrubbing unter Raid1 nicht möglich ist. Dateisysteme können das und mdadm kann es auch. Wenn man da irgend ein fertiges NAS-System nutzt, muss man im Zweifelsfall mal die Dokumentation lesen ob/wie entsprechende Checks erfolgen bzw. angestoßen werden können.

 

[emulbetsup]

--Bitte die Zitierregeln beachten--

Danke für deine Antwort. Für mich habe ich das jetzt so verstanden:

RAID5 hat bei den üblichen Implementierungen ein erhöhtes Risiko für Daten-Corruption, weil...

1. ...die zu den Daten abgelegten Paritätsinformationen von der Maschine berechnet werden. Das ist komplexer, als das zweifache Ablegen der gleichen Daten auf zwei verschiedene Datenträger. Bei einem RAID5 können damit allerhand Fälle von inkonsistenter Hardware, wie auch defekter RAM, zu falschen Ergebnissen führen.

2. ... @kieleich hat angesprochen, dass bei den üblichen Implementierungen von RAID5 und RAID6 das Ergebnis einer vorherigen Berechnung unüberprüft weiterverwendet wird. Der Grund des initialen Sync bei einem RAID5 hatte ich mich auch schon gefragt und so ergibt das Sinn. Das bedeutet aber auch, dass fehlerhafte Paritäten sich zu fehlerhaften Paritäten fortsetzten können.

3. ... der Rebuild eines RAID5 neben den hier genannten Punkten, auch so schon für das ganze System eine höhere Belastung ist. Ein Komplettverlust durch Ausfall eines weiteren Datenträgers ist während einem Rebuild wahrscheinlicher, als bei einem RAID1 oder RAID10.

Aus diesen Gründen erscheint mir Scrubbing bei RAID5 sehr sinnvoll und ich habe für mich beschlossen kein RAID5 ohne Scrubbing betreiben zu wollen. Deswegen habe ich jetzt das RAID5 des EX4100 wieder aufgelöst und in ein RAID10 umgewandelt, weil es eben Fälle gibt, bei denen sich fehlendes Scrubbing bei RAID5 negativ auswirkt.

Ein RAID ersetzt nunmal kein Backup, auch wenn es Fälle auffangen kann, in denen man normalerweise ein Backup benötigen würde. Die wichtigen Daten liegen bei mir jetzt auf zwei NAS. Die sehr wichtigen Daten liegen zusätzlich nochmal bei den Schwiegerleuten oder in der Cloud. Das ist jetzt vom Standard her sehr viel besser, als das was ich teilweise in der Vergangenheit hatte.

--Bitte die Zitierregeln beachten--

Scrubbing beherrscht das WD nicht. Eine Datenträgerüberprüfung kann man als Benutzer anstoßen, aber nicht als Cronjob konfigurieren. Scrubbing gibt's in allen RAID-Modi nicht. So lange ich aber nicht unerkannt defekte Daten zurückbekommen kann, kann ich mich auch nicht aus Unwissenheit auf ein korruptes Backup verlassen. Im Desasterfall kann ich mich also immer darauf verlassen, dass ein fehlerfreier Resync auf einem neuen Datenträger zu einem konsistenten Ergebnis führt. Das war mir vor Erstellung des Threads unklar.

Danke dafür!

 

[andy_m4]

Bei Netzwerkkommunikation o.Ä., wo Daten zu einem bestimmten Zeitpunkt transferiert werden, bietet sich so ein ziemlich hoher Schutz durch CRC32.

Bei Netzwerkkommunikation kommt auch noch hinzu, das das auf mehreren Layern abgesichert ist.
Ethernet hat ne Prüfsumme. Auf IP-Ebene kommt noch eine weitere Prüfsumme hinzu. Obendrauf hast Du dann häufig auch noch mal ne Verschlüsselung (HTTPS und Co) wo es auch noch mal auffällt, wenn was kaputt gegangen ist.

 

[Banned]

WAHRSCHEINLICHKEIT steht da. Wahrscheinlichkeiten sind immer statistische Werte, die nur sehr bedingte Aussagen zu konkreten, vereinzelten Gegebenheiten wie du eines beschreibst. An der Wahrscheinlichkeit über eine (große) Menge ändert sich entsprechend überhaupt nichts.

Das ist mir schon klar. Ich wollte es nur etwas weiter ausführen bzw. auf den möglichen Fall hinweisen. Habe doch an keiner Stelle gesagt, dass du unrecht hättest.

Und Pauschal stimmt es nicht, dass Scrubbing unter Raid1 nicht möglich ist.

Ich weiß nicht, ob du dich damit auf mich beziehen wolltest, aber ich hatte auf der ersten Seite schon breit dargelegt, dass es natürlich geht bzw. unter welchen Umständen bzw. mit welchen Einschränkungen. Also gar keine Divergenz hier.

 

[Piktogramm]

@Banned
Du hast meine Aussage zitiert und dann deine Aussage mit einem "Außer" eingeleitet. Duden.de zur Präposition "außer"

1. abgesehen von [...]

https://www.duden.de/rechtschreibung/auszer_Praeposition
Du hast also eine Ausnahme zu ner allgemeinen, statistischen Aussage formuliert. Was Inhaltlich schlicht Käse war und ist.
Und nein, der zweite Paragraph mit Trennzeile bezieht sich allgemein und nicht nur auf dich.

RAID5 hat bei den üblichen Implementierungen ein erhöhtes Risiko für Daten-Corruption, weil...

1. ...die zu den Daten abgelegten Paritätsinformationen von der Maschine berechnet werden. Das ist komplexer, als das zweifache Ablegen der gleichen Daten auf zwei verschiedene Datenträger. Bei einem RAID5 können damit allerhand Fälle von inkonsistenter Hardware, wie auch defekter RAM, zu falschen Ergebnissen führen.

Wenn du der Datenverarbeitung nicht vertrauen kannst sind alle Überlegungen zur Fehleranfälligkeit von Speicherlösungen für den Allerwertesten. Die naive Grundannahme ist daher, dass die Datenverarbeitung funktioniert und an der Stelle ist es dann egal ob Paritäten berechnet werden oder nicht, denn unter der zugrundeliegenden Annahme funktioniert das ja immer.
Je kritischer die Daten sind, desto weniger naiv sollte man bei dieser grundlegenden Annahme der perfekten Datenverarbeitung sein. Bei NAS-Systemen im Endkundenbereich bleibt so oder so keine Alternative zur naiven Annahme.
Es ist aber halt Humbug anzunehmen, dass Paritätsberechnung ein Problem sei. Für Raid1 braucht es ja mindestens Checksummen um feststellen zu können, welche Kopie der Daten valide ist. Wenn da bei der Datenverarbeitung Fehler passieren, sind die Checksummen genauso falsch.

2. ... @kieleich hat angesprochen, dass bei den üblichen Implementierungen von RAID5 und RAID6 das Ergebnis einer vorherigen Berechnung unüberprüft weiterverwendet wird. Der Grund des initialen Sync bei einem RAID5 hatte ich mich auch schon gefragt und so ergibt das Sinn. Das bedeutet aber auch, dass fehlerhafte Paritäten sich zu fehlerhaften Paritäten fortsetzten können.

So pauschal wie falsch. Je nach Implementierung ist das Verhalten abweichend und meist gibt es noch weitreichende Konfigurationsmöglichkeiten der Implementierungen.
Beispiel Btrfs: https://btrfs.readthedocs.io/en/latest/Auto-repair.html
BTRFS für Linux (Kernel 6.8) ist das derzeitige Verhalten, dass Checksummen geprüft werden, wenn Daten gelesen werden. Jedoch gibt es eine diese Prüfung nur für die gelesene Daten und nicht für das Dateisystem als Solches bzw. alle "kalten" Daten.

Wenn ZFS, madam, Intel SoftwareRaid, Windows Softraid, Hardwarecontroller zum Einsatz kommen sollte man als Anwender entsprechend mal die Dokumentation lesen! Oder sich eingestehen, wie viel des eigenen Konzepts nach Prinzip Hoffnung funktioniert.

3. ... der Rebuild eines RAID5 neben den hier genannten Punkten, auch so schon für das ganze System eine höhere Belastung ist. Ein Komplettverlust durch Ausfall eines weiteren Datenträgers ist während einem Rebuild wahrscheinlicher, als bei einem RAID1 oder RAID10.

Wenn Laufwerke über den Jordan gehen ist daher meist auch vorgesehen eine Kopie der Daten zu ziehen und mit der Kopie weiter zu arbeiten. Die Belastung der Laufwerke ist meist kleiner und es geht sowieso schneller als ein Rebuild.
Imho sind Rebuilds maximal Leuten anzuraten, die genau wissen was sie tun und die abschätzen können wie sie mit etwaigen, negativen Folgen umzugehen haben.

Aus diesen Gründen erscheint mir Scrubbing bei RAID5 sehr sinnvoll und ich habe für mich beschlossen kein RAID5 ohne Scrubbing betreiben zu wollen. Deswegen habe ich jetzt das RAID5 des EX4100 wieder aufgelöst und in ein RAID10 umgewandelt, weil es eben Fälle gibt, bei denen sich fehlendes Scrubbing bei RAID5 negativ auswirkt.

Nein.. Datenhalden und Backups ohne durchgängiges Monitoring und regelmäßigen Test funktionieren nach dem Prinzip Hoffnung. Monitoring und Tests sind bei jeder Datenhaltung und jedem Backup anzuraten. IMMER!

 

[Banned]

Und nein, der zweite Paragraph mit Trennzeile bezieht sich allgemein und nicht nur auf dich.

Er dürfte sich nicht nicht nur auf mich, sondern gar nicht auf mich beziehen, da ich sowas schließlich nie gesagt hatte (um sich mal auf dein Klugscheißer-Level zu begeben).

Bzgl. der Verwendung von "außer" hast du recht. Da habe ich tatsächlich ein in diesem Zusammenhang falsches Wort benutzt (lass dir versichert sein, dass ich es auch ohne albernen Dudenverweis verstanden hätte, aber wenn du Zeit und Spaß dran hast ...) Also steinigt mich! Der Ton macht die Musik und so - haste bestimmt schon mal gehört.