Raid 5 vs. Raid 10

[#Franz]

Hallo zusammen,

ich habe eine Verständnisfrage. Ich habe mir vor kurzem eine Synology DS420+ um meine alte Single HDD WD MyCloud zu ersetzen.
Natürlich mit dem Ziel die Ausfallsicherheit zu erhöhen, wenn eine HDD den Geist aufgibt und in Zukunft den Speicher erweitern zu können. Deswegen habe ich mich auch für ein 4-Bay NAS und nicht 2-Bay NAS entschieden.

Ich nutze die NAS nur privat und hauptsächlich als Foto / Dokumenten Backup. Wäre natürlich Schade wenn da was verloren geht, aber kein Weltuntergang. Zudem muss ich ja ohnehin die wichtigsten Daten nochmal örtlich getrennt sichern im Falle eines Brand, Diebstahl oder ähnlichen. Das ist mir klar. Dennoch sollten die Daten auf der NAS eine gewisse Sicherheit haben (gerade gegenüber einer Single-HDD Lösung).

Ursprünglich hatte ich vor Raid 5 einzusetzen, da ich diese Lösung für ziemlich smart hielt. Eine HDD kann ausfallen und man kann dennoch 2/3 (bei 3 HDDs) oder 3/4 (bei 4 HDDs) des gesamten Speichers nutzen. Natürlich ist mir klar, dass wenn eine zweite HDD ausfällt alle Daten weg sind, aber das Risiko wollte ich eingehen. Hierfür setze ich Seagate Ironwolf 12TB Festplatten ein. Jetzt habe ich aber einige Artikel gelesen, die dringend vom Einsatz von Raid 5 abraten, besonders bei größeren Festplattengrößen.

Hier geht es nicht nur um die Gefahr, dass eine 2. Festplatte ausfällt während man die 1. defekte austauscht (das Risiko würde ich ja in Kauf nehmen), sondern um die Wahrscheinlichkeit des Auftreten eines URE (Unrecoverable Read Error) während des Raid 5 Rebuild. Und genau hier setzt es mit meinen Verständnis aus. In den Artikeln wird das Auftreten eines einzigen URE als absolute Katastrophe dargestellt.

Aber warum sollte eine einzelner Bit-Lese-Fehler meine gesamten 36TB an Daten unbrauchbar machen?

Das geht nicht in meinen Kopf rein. Nach meinen Verständnis würde das nur bedeuten, dass eine Datei nicht mehr herstellbar ist. Kann natürlich immer noch blöd sein, aber das ist trotzdem ein völlig anderes Schadensbild als der Verlust aller Daten. Das würde ja sogar bedeuten, dass es sicherer ist bei dem Ausfall einer Festplatte in einen Raid 5 System diese Festplatte nicht auszutauschen und Raid 5 ohne Ausfallsicherheit weiter zu betreiben. Das macht doch keinen Sinn?

Die Lösung scheint zu sein besser auf Raid 6 oder Raid 10 zu setzen. Das schränkt allerdings die Erweiterung meines NAS extrem ein und kostet natürlich nochmal mehr.

 

[DerNiemand]

Naja da ist dann meist ein ganzer Sektor von betroffen. Und wenn dort die Informationen für das Dateisystem gespeichert sind, kann das schon ziemlich mies werden.

Aber ja, Raid 5 ist veraltet und sollte nicht mehr verwendet werden. Evtl. noch ein RaidZ1 mit ZFS, aber auch das wird nicht empfohlen.

 

[Fujiyama]

Da man ja immer ein Backup haben sollte, wär mir persönlich das URE Problem egal.

 

[Don_2020]

RAID 6 ist besser als RAID 5. Da können 2 HD gleichzeitig ausfallen.

 

[M-X]

Wenn deine Anforderung nicht ist dass das NAS 24/7 erreichbar sein muss solltest du das Geld lieber in ein vernünftiges Backup stecken. Hardware Fehler (des Controllers), Cryptomalware, aus verstehen löschen etc, gegen all diese Szenarien hilft ein RAID einfach nicht.

 

[Don_2020]

LTO-8 ist gerade aktuell.

 

[up.whatever]

Das würde ja sogar bedeuten, dass es sicherer ist bei dem Ausfall einer Festplatte in einen Raid 5 System diese Festplatte nicht auszutauschen und Raid 5 ohne Ausfallsicherheit weiter zu betreiben.

Nein, das führt zum gleichen Problem. Ob die Daten beim rebuild oder beim Dateizugriff nicht gelesen werden können ist unerheblich. Ohne rebuild weißt du nur noch nicht, dass deine Daten futsch sind.

Natürlich sind damit nicht direkt alle 36TB weg, aber das RAID ist ein Blockdevice und kennt keine einzelnen Dateien. Aus Sicht des RAID muss alles, was nicht 100%ig konsistent ist, als defekt angesehen werden.

 

[GrumpyCat]

Die Idee bei einem RAID ist, dass es vollständig funktioniert, immer verfügbar ist und nicht Lesefehler hier und da liefert. Und genau so benehmen sich die Implementierungen auch. Insofern "löscht" ein einzelner Lesefehler bei einem Rebuild Deine Daten nicht komplett, da hast Du schon recht, und man kommt auch spätestens mit Frickelei an die unbeschädigten Daten ran. Das geht aber komplett an der Praxis vorbei, für die RAID gedacht ist: Das soll einfach immer funktionieren und verfügbar sein und nicht absehbar häufig ein paar Tage Downtime wegen Frickelei brauchen und dann "nur ein paar Sektoren Daten verlieren".

 

[jonderson]

Die Lösung scheint zu sein besser auf Raid 6 oder Raid 10 zu setzen. Das schränkt allerdings die Erweiterung meines NAS extrem ein und kostet natürlich nochmal mehr.

Es ist immer eine Risikoabwägung.
Raid 6 erfordert mehr Leistung und ist langsamer.

Ich wollte das nicht in Kauf nehmen.
Deswegen habe ich über mehrere Festplatten verteilt ein Raid 5. Dabei werden immer 1TB je Festplatte je Raid 5 verwendet. Zusätzlich wird dies bei wichtigen Daten über LVM nochmals gespiegelt, wobei der Spiegel kein Raid ist (Falls mdadm fucked up ist...).

Zusätzlich steht noch ein Hot-Swap fürs Raid5 bei sehr wichtigen Daten bereit. Ja während des Recovery kann etwas schief gehen, aber wie gesagt Risikoabwägung...

Raid 0 halte ich übrigens für überflüssig.
So etwas wird heute z.B. durch ein LVM, also Volume Groups, gelöst.

 

[Humptidumpti]

Aber warum sollte eine einzelner Bit-Lese-Fehler meine gesamten 36TB an Daten unbrauchbar machen?

Das passiert ja nur in den wenigsten Fällen. Meistens liegt der Bit Fehler im Bereich einer Datei, welche dann im schlimmsten Fall nicht mehr lesbar oder nutzbar ist.

Theoretisch möglich ist aber auch ein Fehler im Bereich der Raid Meta Daten, was die Sache dann aber doof macht wenn man kein Backup hat.

Nutze einfach das Raid 5. Wenn du eh ein Backup hast musst du dich um theoretische Vorgänge eh nicht sorgen.

 

[conf_t]

Aber warum sollte eine einzelner Bit-Lese-Fehler meine gesamten 36TB an Daten unbrauchbar machen?

Kommt ganz auf die HDD an.
Erstens nimmt man dann besser keine WD RED und ähnliche Consumer HDDs, sondern die "besseren" Ironwolf oder Toshiba MG-Serie. Da bekommt man von vorn herein Platten (bei Ironwolf erst ab >= 6 TB) die eine UBER von 1:10^15 haben. Also 1 Lesefehler auf 125 TB gelesene Daten. Bei den von WD Red (pro und auch plus) Platten hat man 1:10^14 oder 10:10^15 (was das gleiche wie 1:10^14 ist), und da tritt statistisch alle 12,5 TB ein unkorrigierbarer Lesefehler auf.

Warum ein unkorrigierbarer Bit-Fehler so ein riesen Problem darstellt ist bei RAIDs mit NON-NAS Platten ein riesen Problem. Da hilft RAID 6 auch nur bedingt. Also auch bei den eben angezählten WD Red ist das nicht sooo dramatisch wie bei Desktopplatten (Seagate Baracuda, WD Black, WD Blue und früher WD Green, Toshiba X300,....)

Also wenn du Desktopplatten einsetzt und es kommt zu einem Lesefehler, der auch nicht behebbar ist (durch z.B. CRC), versuchen Desktopplatten so lange den Block Daten erneut zu lesen, bis er es schafft. Weil die Platte dann solange unresponsible bleibt, wird sie aus dem RAID geworfen. Also hast du dann im RAID 5 plötzlich 2 fehlende Platten und damit hat 1 Bitfehler dein ganzes RAID geschrottet.

Habe ich selbst mit Seagate 3x 5 TB Backup-Platten (technisch Desktopplatten) im RAID 5 mal im Rahmen einer Diskussion hier vor 8 Jahren mehrfach ausprobiert. Ein Rebuild ist mit solchen Desktopplattten schlicht unmöglich.

NAS Platten, mit niedriger UBER (wie WD Red oder Toshiba N300), verhindern das dauerhafte "unresponsible" und fliegen dann nicht aus dem RAID, wenn ein Bitfehler auftritt. Hier ist halt damit zu rechnen, dass eine oder mehrere Dateien nach dem Rebuild defekt sind. Hier kann man das Problem mit Raid 6 umschiffen. Bei einem 4-Bay NAS kann man dann auch aber auch zu Raid 10 greifen.

Mit NAS Platten die dann noch eine UBER von 1:10^15 haben, ist man dann auf dem Königsweg.

Preislich geben sich die Platten auch nicht mehr viel. Also ich würde lieber - bei jedem Paritäts-Raid auf Platten mit UBER größer/gleich 1:10^15 setzen.


Wie schon erwähnt ist natürlich eine ordentliche Backup-Strategie (Versionierung + Offline + möglichst verschiedene Ort) wichtiger, als die Gedanken zum RAID.

 

[I'm unknown]

Ich nutze die NAS nur privat und hauptsächlich als Foto / Dokumenten Backup. Wäre natürlich Schade wenn da was verloren geht, aber kein Weltuntergang.

Wichtig ist nur auch das Verständnis dass ein RAID kein Backup ist sondern nur eine Methode um die Performance, die Verfügbarkeit oder beides zu verbessern.

Zudem muss ich ja ohnehin die wichtigsten Daten nochmal örtlich getrennt sichern im Falle eines Brand, Diebstahl oder ähnlichen.

Auch wegen Ransomware, unbeabsichtigtes Löschen, Dateisystemfehler, etc.

Daher ist eine Datei auf einem RAID mit Redundanz nicht viel Sicherer als auf einem einzelnen Medium. Ein Backup ist mehr das was du im zweiten Zitat hier geschrieben hast .

 

[Groug]

Ursprünglich hatte ich vor Raid 5 einzusetzen, da ich diese Lösung für ziemlich smart hielt. Eine HDD kann ausfallen und man kann dennoch 2/3 (bei 3 HDDs) oder 3/4 (bei 4 HDDs) des gesamten Speichers nutzen.

Das ist falsch, du verlierst da keine Kapazität nur Parität. Dh. das Volumen ist immer noch so groß ist aber nicht mehr vor Ausfall geschützt.

Aber warum sollte eine einzelner Bit-Lese-Fehler meine gesamten 36TB an Daten unbrauchbar machen?

Weil ein Raid nicht auf Dateibasis sondern auf Blockbasis arbeitet. Aus Sicht des Dateisystems ist das eine große Platte.

 

[puri]

Das Problem bei RAID5 mit sehr wenigen großen Festplatten ist wohl, dass die Wahrscheinlichkeit recht groß ist, dass Bits kippen. Das fällt normalerweise nicht auf, schlimmstenfalls ist halt eine Datei kaputt. Beim Rebuild dagegen, wird jedes Bit gelesen und geschrieben und wenn (siehe Mail weiter oben), hier was nicht stimmt, gilt das ganze RAID als Schrott. So gesehen sind RAID 1- basierte Kombinationen hier die bessere Wahl, weil im schlimmsten Fall dann nur eine Datei von der verbliebene HDD kaputt ist, aber nicht mehr und auch nichts verworfen wird, wird ja nur wieder gespiegelt..
Für ein RAID 5 mit sehr großen Platten braucht man ein Dateisystem, welches ständig selbst aktiv die Inhalte überprüft und ggfs. neu schreibt. Ich glaube REFS kann sowas..

 

[Groug]

Das Problem bei RAID5 mit sehr wenigen großen Festplatten ist wohl, dass die Wahrscheinlichkeit recht groß ist, dass Bits kippen. Das fällt normalerweise nicht auf, schlimmstenfalls ist halt eine Datei kaputt.

Dafür sollte man das Raid zyklisch prüfen. checkarray kann das zB. bei mdraids machen.

Für ein RAID 5 mit sehr großen Platten braucht man ein Dateisystem, welches ständig selbst aktiv die Inhalte überprüft und ggfs. neu schreibt. Ich glaube REFS kann sowas..

Da wäre wohl zfs sinnvoller. Das realisiert das "Raid" gleich im Filesystem. Oder btrfs, wobei das mit Raid5 und höher noch nicht ausgereift ist.

 

[GrumpyCat]

Für ein RAID 5 mit sehr großen Platten braucht man ein Dateisystem, welches ständig selbst aktiv die Inhalte überprüft und ggfs. neu schreibt. Ich glaube REFS kann sowas..

Das kann man auch so bei beliebigen Dateisystemen machen lassen (nennt sich "Scrubbing"). Nur ist das über die Jahre immer weniger praktikabel geworden, jedenfalls im betrieblichen Einsatz, da die Platten größer geworden sind, die Lesegeschwindigkeiten sich aber kaum verändert haben: Früher hat das Scrubbing vielleicht 100GByte/100MBytes/Sek = 1000 Sekunden = ca. 17 Minuten gedauert (bei 100GB-Platten). Heute dauert's z.B. 18TB/150MBytes/Sek = 120000 Sekunden = 2000 Minuten = ca. 33 Stunden. Und die ganze Zeit bringt das Array schlechte Performance. Oder man macht das mit sehr nachrangiger Priorität, nur braucht das Scrubbing dann noch länger, also weiß man nicht mehr täglich, dass alle Platten noch gut sind, sondern vielleicht nur alle zwei Wochen...

 

[jonderson]

Ich weiß nicht warum hier immer davon ausgegangen wird, komplette Platten als Raid zu nutzen.
Halte das komplett unpraktikabel.
Warum nicht z.B. 1TB Partitionen als Raid nutzen und dafür mehrere Raids machen?

 

[I'm unknown]

Oder man macht das mit sehr nachrangiger Priorität, nur braucht das Scrubbing dann noch länger, also weiß man nicht mehr täglich, dass alle Platten noch gut sind, sondern vielleicht nur alle zwei Wochen...

Und die Platten verschleißen dabei nicht unerheblich. Sieht man ja an den Daten die für die Jährliche Schreibleistung angegeben sind...

 

[#Franz]

Das passiert ja nur in den wenigsten Fällen. Meistens liegt der Bit Fehler im Bereich einer Datei, welche dann im schlimmsten Fall nicht mehr lesbar oder nutzbar ist.

Theoretisch möglich ist aber auch ein Fehler im Bereich der Raid Meta Daten, was die Sache dann aber doof macht wenn man kein Backup hat.

Nutze einfach das Raid 5. Wenn du eh ein Backup hast musst du dich um theoretische Vorgänge eh nicht sorgen.

Naja, mein Backup ist ja nicht auf Tagesbasis und wird nicht alle zukünftigen Daten (36TB) umfassen. Das wäre mir einfach zu kostspielig.

Verstehe immer noch nicht wie ein einzelner Bit-Lesefehler so eine Auswirkung haben kann. Vielleicht habe ich aber andere Anforderungen / Erwartungen als jemand im professionellen Bereich. Eine korrupte Datei wäre schade aber keine Katastrophe.
Die Ironwolfs mit 12TB kommen ja auf eine URE von 1 zu 10^15.

Laut diesem Artikel (https://www.digistor.com.au/the-latest/Whether-RAID-5-is-still-safe-in-2019) soll die Rebuilding Fail Rate bei 25% (4 HDDs / 12TB / 10^15 URE). Ich hätte es so verstanden die Wahrscheinlichkeit, dass ein Single Bit Fehler auftritt bei 25% liegt. Im Artikel klingt es aber so als ob die Wahrscheinlichkeit bei 25% liegt, dass das komplette Raid unbrauchbar wird.

 

[jonderson]

Und die Platten verschleißen dabei nicht unerheblich. Sieht man ja an den Daten die für die Jährliche Schreibleistung angegeben sind...

SSDs vielleicht, bei HDDs halte ich das für vernachlässigbar.
Habe eine Festplatte die hat mehr als 9 Jahre bloße Betriebszeit... ( 79105 Stunden )
Klar kommt die nur noch als absoluter Notnagel zum Einsatz (Hot-Swap), aber sie läuft und läuft und läuft....