Scrubbing allgemein, sowie die Notwendigkeit von Scrubbing bei RAID5

[emulbetsup]

Um meine Backups etwas umzustrukturieren und zu automatisieren habe ich bei WD ein EX4100 im Bundle mit 4x 6TByte WD Red gekauft. Die Kombination war recht günstig und das EX4100 gab's quasi als Bonus oben drauf. Die Firmware ist natürlich nicht mit einer QNAP oder eine Synology vergleichbar, aber als reiner SMB-Share muss das Gerät auch nicht viel können.

Standardmäßig kommt das EX4100 im RAID5. Leider fehlt die Option des Scrubbings, also die regelmäßige Überwachung der geschriebenen Paritätsinformationen. Das ist wohl vor allem im Desasterfall ein Thema, weil die Paritätsinformationen afaik nur dann tatsächlich verarbeitet werden.

Jetzt treiben mich hier folgenden Fragen um:

1. Scrubbing kann auf einer QNAP nur für RAID5 und RAID6 konfiguriert werden. Warum spielt das bei RAID1 und RAID10 keine Rolle? Dort sind Informationen zweimal vorhanden. Das ist doch vergleichbar mit einem RAID5, dass die Informationen einmal speichert und zusätzlich eine Paritätsinformation bereit hält, mit der der Inhalt unter zuhilfe der anderen Datentäger rekonstruiert werden kann.

Warum hat Scrubbing bei RAID5 und RAID6 also einen Sinn? Wie wird bei einem RAID1 oder RAID10 erkannt, ob auf einem der zwei Datenbestände ein Bit gekippt ist?

2. Ich betreibe jetzt zwei NAS (das erwähnte EX4100 und ein älteres TS-431XeU), jeweils mit 4 Datenträgern im RAID5. Die QNAP macht jetzt einmal in der Woche ein Scrubbing und synchronisiert sich wöchentlich mit der EX4100, die ebenfalls im RAID5, aber ohne Scrubbing auskommen muss.

Jetzt können also an zwei Stellen Festplatten kaputt gehen. Daraus ergeben sich folgende möglich Vorgehensweisen:

1. Ich lasse beide Geräte im RAID5 und hoffe das Beste, mache also immer jeweils ein RAID-Recovery in dem NAS, das eine defekte HDD hat.

Nachteil: Ich bin bei der EX4100 auf ein Recovery angewiesen, das ohne Scrubbing auskommen musste. Das wäre in jedem Fall von einer schlechteren Qualität, als das Recovery der QNAP

---------------------

2. Theoretisch bin ich auf kein RAID-Recovery angewiesen, sondern kann ein Array komplett in die Tonne kloppen und die Daten auf ein frisches Array vom jeweils anderen NAS replizieren.

Nachteil: Ich hätte während des Kopiervorgangs (aktuell etwa 16 Stunden bei GBE) die Daten nur noch ein einziges Mal.

---------------------

3. Ich stelle das EX4100 auf RAID10 um. Die Daten sind jetzt zwar schon vollständig auf beiden Systemen gespiegelt, aber ich habe auch noch ein aktuelles Backup auf einem alten Prodesk, auf dem ein TrueNAS im RAID5 läuft. Das EX4100 sollte das zu kleine TrueNAS ersetzen. Zu klein deshalb, weil ich nur noch in Kombination mit einer externen Festplatte ein vollständiges Backup machen konnte.

Dafür müsste ich aber verstehen, warum Scrubbing bei einem RAID10 entbehrlich ist. Andernfalls ergibt das so für mich keinen Sinn.

Vielen Dank für eure Antworten!

 

[stefan92x]

Scrubbing bezeichnet ja tatsächlich die Fehlerkorrektur. Fehler korrigieren ist bei RAID1/10 aber überhaupt nicht möglich, da kann man nur vergleichen und Fehler feststellen. Darum gibt es den Begriff da in der Form halt überhaupt nicht.

RAID1/10 schützt dich halt davor, dass eine Festplatte abschmiert, und dann weißt du halt auf welcher die Daten kaputt sind. Das ist aber auch schon alles was du damit machen kannst.

 

[emulbetsup]

Das heißt ein RAID5 ohne Scrubbing ist nicht anfälliger als ein RAID1 oder RAID10, aber ein RAID5 mit Scrubbing ist besser, weil Fehler proaktiv erkannt werden können?

 

[Skudrinka]

Bei Raid 5/6 kann eben über Prüfsummen festgestellt werden, ob ein Fehler vorliegt.
Das geht mit 1/0 nicht. 0 schon mal gar nicht.
Und bei 1, woher soll das System wissen, was richtig ist? - Welche Datei die originale unbeschädigte ist? - Das geht nicht.

Immer schön an Backups denken.
Raid erstetzt kein Backup.
Raid schützt nicht vor Datenverlust.

Ergänzung (9. Mai 2024)

Das heißt ein RAID5 ohne Scrubbing

Bist du dir sicher das auf der Nas ein klassisches RAID 5 läuft?

 

[emulbetsup]

Soweit ich das beurteilen kann, ja:

 

[GrumpyCat]

Es geht beim Scrubbing nicht darum, Fehler zu korrigieren, sondern sie überhaupt zu finden - bevor es eine Applikation macht.

Steht auch so in https://en.wikipedia.org/wiki/Data_scrubbing#RAID

Prüfsummen auf RAID-Ebene sind gut und schön, aber die Platten selbst nutzen ja schon Prüfsummen und melden ggf. Lesefehler an das OS und geben nicht etwa fehlerhafte Daten raus. Die Prüfsummen auf RAID-Ebene sind eher zusätzliche Sicherung und ggf. ein Indikator für Fehler an anderer Hardware (RAM, CPU...).

Mit Parität hat Scrubbing erstmal nichts zu tun. Scrubbing kann man auch prima ganz ohne RAID machen.

 

[emulbetsup]

Bei Raid 5/6 kann eben über Prüfsummen festgestellt werden, ob ein Fehler vorliegt.
Das geht mit 1/0 nicht. 0 schon mal gar nicht.
Und bei 1, woher soll das System wissen, was richtig ist? - Welche Datei die originale unbeschädigte ist? - Das geht nicht.

Woher weiß er das bei einem RAID5. Dann hat er im Zweifelsfall A-B-C und die Paritätsinformation, aber er kann ja nicht wissen ob A, B, C oder die Paritätsinformation falsch ist?

EDIT:

Es geht beim Scrubbing nicht darum, Fehler zu korrigieren, sondern sie überhaupt zu finden - bevor es eine Applikation macht.

Ok, das erklärt es.

 

[GrumpyCat]

aber er kann ja nicht wissen ob A, B, C oder die Paritätsinformation falsch ist?

Die Platte, die beim Lesen des jeweiligen Sektors "read error" zurückliefert, ist ein heißer Kandidat.

Davon ab gibt es auch auf Dateisystem-Ebene noch Prüfsummen. Das ist nicht das gleiche wie Parität.

 

[emulbetsup]

Ja, aber dafür muss die Platte aber einen Lesefehler ausgeben und nicht einfach nur das gekippte Bit.

 

[GrumpyCat]

KEINE Platte gibt einfach gekippte Bits raus. Wer erzählt denn so nen Schrott? Die Platten benutzen intern schon alle möglichen Arten von Sicherungs- und Korrekturcodes, weil das bei den Datenmengen heutzutage schon statistisch ansonsten Wahnsinn wäre und Prüfsummen einfach auch so gut wie kostenlos umzusetzen sind. Steht alles auf Wikipedia.

 

[Banned]

1. Scrubbing kann auf einer QNAP nur für RAID5 und RAID6 konfiguriert werden. Warum spielt das bei RAID1 und RAID10 keine Rolle?

Es spielt bei RAID1 auch eine Rolle. Nur muss man hier zwischen Raid Scrubbing und Data Scrubbing unterscheiden.

https://blog.synology.com/ger/was-ist-data-scrubbing-2-mechanismen-zur-datenbereinigung/


Da QNAP als Dateisystem nicht ZFS oder Btrfs für Consumer-NAS anbietet, gibt es hier kein Scrubbing. Es ist also trotzdem sinnvoll, nur eben nicht sinnvoll möglich mit dem Gerät (siehe unten).

Dort sind Informationen zweimal vorhanden. Das ist doch vergleichbar mit einem RAID5, dass die Informationen einmal speichert und zusätzlich eine Paritätsinformation bereit hält, mit der der Inhalt unter zuhilfe der anderen Datentäger rekonstruiert werden kann.

Richtig.

Warum hat Scrubbing bei RAID5 und RAID6 also einen Sinn?

Wie gesagt, es hat immer einen Sinn.

Wie wird bei einem RAID1 oder RAID10 erkannt, ob auf einem der zwei Datenbestände ein Bit gekippt ist?

Bei einem Data-Scrub über die Prüfsumme des Dateisystems; bei einem RAID-Scrub über die Prüfsumme des Sektors auf der Festplatte.

Fehler korrigieren ist bei RAID1/10 aber überhaupt nicht möglich,

Doch, ist es. Man hat die Daten schließlich gespiegelt. Wird auf dem einen Laufwerk ein Fehler festgestellt, kann dieser aus der Redundanz korrigiert werden.

Die Sache ist, dass RAID-Scrubbing für RAID1 und RAID10 wenig sinnvoll ist, weil dabei fälschlicherweise Fehler (Nicht-Übereinstimmungen) gemeldet werden können:
https://wiki.archlinux.org/title/RAID (Siehe 6.1.2)


Scrubbing mit RAID1 und 10 ist also nur aussagekräftig über Data Scrubbing, was ein entsprechendes Dateisystem (ZFS/Btrfs) voraussetzt.

 

[Skudrinka]

KEINE Platte gibt einfach gekippte Bits raus.

Natürlich können sie das tun.
Eine Platte erkennt kein gekipptes Bit, welches bereits gespeichert ist.
Daher gibt es kluge Dateisysteme mit Paritäten und Prüfsummen, um sowas zu finden und zu beheben. Wie ZFS und Btrfs.

 

[Banned]

KEINE Platte gibt einfach gekippte Bits raus.

Wenn aber nichts mehr zu retten ist, wird einfach gar nichts mehr ausgegeben, was dann im Endeffekt auf das Gleiche rauskomme: Korrumpierte Datei.

Es ist aber auch möglich, dass die Platte den Fehler gar nicht erkennt. Das ist zwar ein Extremfall, aber möglich. Der ECC der Sektoren kann m.W. nur zwei fehlerhafte Bits erkennen. Bei Silent Data Corruption (wenn sich gekippte Bits kumulieren) kann es dann irgendwann zu einem Fehler kommen, der nicht mehr erkannt wird.
Die Prüfsumme von ZFS/Btrfs gibt hier höhere Sicherheit.

 

[GrumpyCat]

Eine Platte erkennt kein gekipptes Bit, welches bereits gespeichert ist.

Jeder einzelne Sektor bekommt von der Firmware Prüfsummen mitgeschrieben. Wie anders sollte überhaupt ein Read Error generiert werden? Wie sollte SMART schwebende Sektoren erkennen können? Wie sollten reallocated Sectors überhaupt zustandekommen, wenn die Firmware doch einfach fröhlich alles als gültig annehmen würde?

Ich benutze hier auch btrfs und ZFS, aber schüttle doch gerne den Kopf drüber, was die Leute da für Fehlannahmen zu haben.

 

[Skudrinka]

(wenn sich gekippte Bits kumulieren

Diese Abhängigkeit ist mir auch neu.
Interessant und macht plötzlich viel Sinn. 🤷‍♀️

 

[kieleich]

Standardmäßig kommt das EX4100 im RAID5. Leider fehlt die Option des Scrubbings, also die regelmäßige Überwachung der geschriebenen Paritätsinformationen. Das ist wohl vor allem im Desasterfall ein Thema, weil die Paritätsinformationen afaik nur dann tatsächlich verarbeitet werden.

Man kann Parität auf zwei Arten berechen

einmal, Daten1 ^ Daten2 ^ Daten3 (XOR) = Parität

einmal, AlteDaten ^ AlteParität ^ NeueDaten (XOR) = NeueParität

die zweitere Variante hat das Problem. Sie ist nur korrekt wenn die alte Parität vorher schon korrekt war

war die Parität falsch dann ist es auch nach neu schreiben immer noch wieder falsch

das Problem ist das es schlauen leuten eingefallen ist die zweite Variante trotz dem zu verwenden weil dieses Performanter sein kann, als von allen Platten die Daten zur Parität Berechnung einzusammeln. schreiben eines einzelnen Sektors auf dem RAID, betrifft dennen eben nur 2 Platten (die Platte auf der die Daten liegen, sowie deren Paritätsplatte) statt 4 oder noch mehr Platten je nachdem wie groß das RAID ist

und deswegen gibt es den ganzen Quatsch. mit dem initialen Sync bei der erstellung des RAIDs. solange man keine daten darauf geschrieben hat, wäre der ja gar nicht not wendig. mit den daten würde dann sowieso die richtige parität geschrieben werden. aber leider nein

mit der falschen Parität hast du RAID 0 und ein einzelner Ausfall bricht dir das Genick da alles, falsch hergestelt wird beim neubau

insgesamt muss man daher schon sagen das RAID 5 etwaige Daten Korruption wahrscheinlicher macht gerade wenn man, nie testet ob dier Parität stimmt

bei RAID 1 hat man dieses spezielle Problem nicht hier gibt es keine Parität und alle Daten werden immer auf alle Platten geschrieben als Spiegelung da spielen die alten Daten keine Rollen. natürlich müssen sie am Ende trotzdem identisch sein und das sollte man auch mal testen, warum QNap oder sonst das nicht anbietet, keine Ahnung!

 

[stefan92x]

Doch, ist es. Man hat die Daten schließlich gespiegelt. Wird auf dem einen Laufwerk ein Fehler festgestellt, kann dieser aus der Redundanz korrigiert werden.

Ja was ich meinte war, dass man dazu von woanders wissen muss, welches Laufwerk den Fehler hat. RAID1 an sich kann das nicht ermitteln, sondern nur feststellen, dass es Unterschiede gibt.

 

[GrumpyCat]

Es ist aber auch möglich, dass die Platte den Fehler gar nicht erkennt. Das ist zwar ein Extremfall, aber möglich. Der ECC der Sektoren kann m.W. nur zwei fehlerhafte Bits erkennen.

Du wirfst hier ECC/FEC und Prüfsummen durcheinander. Eine simple gute Prüfsumme sichert Dir die Daten statistisch sicher ab bei egal wie vielen Bitfehlern (in der Praxis). 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.

 

[Banned]

Interessant und macht plötzlich viel Sinn. 🤷‍♀️

Ja, macht es tatsächlich.

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. Wenn nun ein Laufwerk nie überprüft wird (was man z.B. mit chkdsk /r machen kann), dann können mit der Zeit irgendwann so viele Bits pro Sektor kippen, dass es eben nicht mehr erkannt wird. Die Prüfmechanismen von ZFS/Btrfs sind da komplexer bzw. können in höherem Maße Fehler erkennen (frag mich nicht, wie hoch ).

 

[emulbetsup]

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