@Banned
Du hast meine Aussage zitiert und dann deine Aussage mit einem "Außer" eingeleitet. Duden.de zur Präposition "außer"
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.
emulbetsup schrieb:
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!
Der Ton macht die Musik und so - haste bestimmt schon mal gehört. 
