Raid 5 vs. Raid 10

[Rickmer]

Also zu den empirischen Lesefehlern kann ich nur auf meinen bereits erwähnten Selbsttest mit "Seagate Archive 5 TB (ST5000AS0011) Platten im Raid 5 erzählen. Ist aber nur Erfahrung keine Studie . Als das Raid 5 sich im Rebuild befand flog spätestens bei ca 60-70% des Rebuild die zweite Platte aus dem Verbund, was mMn auf einen Lesefehler und aus Raid-Logik-Sicht stehenbleiben der HDD und dem nötigen Kick aus dem Verbund.

Die Seagate Archive HDDs benutzen definitiv SMR

Ich hatte mal eine (Seagate Archive HDD 8TB v2) in einem Raid 5 mit anderen HDDs und die war mehrfach rausgeflogen nicht weil sie kaputt war, sondern zu 95% Sicherheit weil die mit SMR ein Timeout überschritten hatte. Danach musste jedesmal ein Rebuild laufen.
(Das Rebuild war übrigens auch jedesmal erfolgreich. Das war 1x die Archive HDD v2, 2x Exos 5E8 (SMR) und 1x Exos 7E8 (CMR). Das wurde mittlerweile durch 3x Toshiba Enterprise Capacity 14TB abgelöst.)

 

[conf_t]

Woher der Timeout genau kam weiß ich nicht, ob Lesefehler oder SMR bedingt oder beides, aber Timeouts sollte unbedingt beim Rebiuld verhindert werden -> ungeeignete HDD und um mehr ging es mir doch nicht, als dem TE zu zeigen, dass "Augen auf bei HDD Wahl" und viele Probleme durch die falsche HDD Wahl entstehen.

 

[Groug]

SMR funktioniert alleine im RAID schon

Warum haben dann die NAS Hersteller SMR Platte von der Kompatibilitätsliste genommen? Die müssen beim neu beschreiben auch die umliegenden Sektoren neu schreiben. Das kann zu lange dauern und führt dann zu einem Timeout -> Platte fällt aus dem Raid.

 

[#Franz]

Ja, aus dem Grund setze ich RAID 5 ein. Es ist günstiger und hat mich auch noch nicht enttäuscht. Ich kann nicht unterschreiben und bin auch nicht der einzige hier, dass RAID 5 eine bessere Verfügbarkeit herstellt (das meinst du wohl doch mit "Sicherheit"), also JBOD. Es ist halt wie ich schon in eigentlich jedem Post hier geschrieben habe alles eine Frage des Setups und des Gesamtkonzepts.
Wenn du für dich zu der Überzeugung gekommen bist, dass RAID 5 nicht sicher genug für den heimische Einsatz ist, dann kann ich da eh nicht gegen Anreden. Warum fragst du dann noch - liest sich bei dir alles wie gesetzt.

Jetzt unabhängig davon welche Lösung du einsetzt - Backup und Verfügbarkeit sind immer relativ teuer - aber günstiger als eine professionelle Datenwiederherstellung im Labor und erfolgsversprechender. Wer das Geld für ein Backup nicht ausgeben will, dem sind die Daten nicht wichtig genug.

Backups alle paar Monate sind reichlich wenig......


Man kann es mal kurz so zusammenfassen:

Man sollte immer mindestens die doppelte Kapazität in HDDs planen um das Backup auch bereitstellen zu können. Will man noch Verfügbarkeit, wird es entsprechend der RAID-Wahl noch mehr. Also um 4 HDDs nutzbar zu machen braucht man mit Backup und RAID 5 mindestens 9, bei RAID 6 mindetens 10 und bei 10 eben noch mehr.

Datenverfügbarkeit und Backups sind nicht kostenlos. In Unternehmen sind gerade Backups, Security, Datenschutz, Redundanzen u.ä. - alles was nicht so intensiv in der Endkundensparte vorhanden ist - absolute kostentreiber

Ich bin ja dankbar, dass du für RAID 5 sprichst. Ich hatte ja gehofft, dass ich hier im Forum Entwarnung zum Einsatz von RAID 5 bekomme.
So wie ich es verstanden habe würdest auch du nur RAID 5 mit einen vollständigen Backup einsetzen. Da muss ich mir dann wohl nochmal Gedanken machen wie ich das kostengünstig umsetzen kann.

Danke für die vielen Infos!

 

[conf_t]

So wie ich es verstanden habe würdest auch du nur RAID 5 mit einen vollständigen Backup einsetzen.

Nein. Ich würde immer mindestens ein vollständiges Backup vorhalten, Raid (alles, außer 0) ist nur die Kür um im Idealfall mir das Einspielen des Backups zu sparen. So bleiben die Daten auch während des Rebuilds verfügbar, beim Neueinrichten und Backupeinspielen hat man ja daruf keinen Zugriff. Wenn ich ein Backup einspielen würde müsste ich warten bis das abgeschlossen ist. Es spart mir auch die Neueinrichtung und das setzen der Berechtigungen auf Ordner (ja auch privat habe ich eine Berechtigungsstruktur). bei 17 TB dauert das eine Weile - erst recht bei nur 1 Gbit/s Netzwerk
Auch bei einem JBOD, RAID1, 6 oder 10 würde ich immer mit versionierten Backup fahren. Und RAID 0 käme mir nie in die Tüte.

Und um mit dem System Geld zu verdienen (also außerhalb des privaten und Hobbybereichs) würde ich auch nicht auf RAID5 setzen. Aber dafür ist es korrekt umgesetzt imho ausreichend. Ich kann mich nur wiederholen über überwiegend geplante 50 Rebuilds in 6 Jahren an 4 Systemen (DSM) - keiner mit Fehlern.

 

[DerNiemand]

Mit dem Nachbarn und Wasser ist mir schon zweimal passiert.




Hast Du regelmässig Deinen Z1-Pool geschruppt?

Nein, beim Resilvern.
Seitdem nur noch striped mirror und reg. ECC.

 

[GrumpyCat]

Wenn es nur um die Verfügbarkeit ginge bräuchte es doch kein RAID 5, dann bietet doch RAID 0 das gleiche.

Bitte? RAID0 verringert die Verfügbarkeit der Daten gegenüber dem Fall "überhaupt kein RAID eingesetzt", weil die Daten schon nicht mehr verfügbar sind, wenn eine von zwei Platten ausfällt. Das hat offensichtlich eine höhere Wahrscheinlichkeit, als dass mindestens eine einzelne bestimmte Platte ausfällt. Bei JBOD ist's das gleiche Problem.

RAID5 erhöht die Verfügbarkeit der Daten gegenüber dem Fall "überhaupt kein RAID eingesetzt".

 

[M-X]

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

Ich glaube jetzt kommen wir zum Kern der Frage, du sagst zwar du hast ein Backup aber nicht für alles dh du denkst das RAID5 könnte ja für den Rest der Daten eine gute Backup Lösung sein.

Dem ist nicht so. RAID ist kein Backup!

 

[conf_t]

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 muss meinen Festplatten mal dringend sagen, dass sie viel zu zuverlässig sind. Würde ich beim nächsten Rebuild meinen ersten Ausfall erleben - dann käme ich auf eine Rebuild-Fail von knapp unter 2 % und nicht 25%. Die sind das Problem äußerst theoretisch angegangen. Da wurde irgendwas zuviel oder zuwenig berücksichtigt - da stimmt irgendwas nicht in dem Artikel..... In dem Artikel liegt aber defintiv 1 Interpretationsfehler, bzw. eine Undeutlichkeit vor. Unabhängig davon ob die gerechneten Fehlerraten stimmen nimmt der Autor an, dass bei einem URE die Platte aus dem Raid fliegt weil sie in ein Timeout läuft. Wo wir wieder bei NAS-Platten wären, die zwar dann auch in einen Lesefehler laufen, wenn einer auftritt, ihn aber nicht versuchen zu beheben, also ignorieren und es halt zu lassen, dass ein Bit oder mehr umkippt, dafür laufen sie in kein Timeout und bleiben im RAID und der Rebuild wird fortgesetzt. Bei NAS Platten bedeutet eben das Auftreten eines URE eben nicht gleich ein timeoutbedingten Ausschluss der Platte aus dem Array. Es ist eher von einer korrupten Datei am Ende auszugehen.

 

[GrumpyCat]

Wo wir wieder bei NAS-Platten wären, die zwar dann auch in einen Lesefehler laufen, wenn einer auftritt, ihn aber nicht versuchen zu beheben, also ignorieren und es halt zu lassen, dass ein Bit oder mehr umkippt

Uuuuuuh. Quelle?

 

[conf_t]

War vereinfacht ausgedrückt, hatte grad keine Zeit zu suchen (und man beschäftigt sich ja nicht täglich intensiv damit). Was ich meinte war die Funktion von TLER / ERC / CCTL, mit deren Hilfe eine NAS HDD eben nicht aus dem Verbund fliegt trotz Lesefehler. HDDs ohne TLER, wie Desktop HDDs würden aus dem RAID Array fliegen, was bei einem degraded Raid zu einem Problem wird.
Aber eben die TLER Funktion hat der Link von @#Franz unterschlagen bei der Fail-Rate. Auch daher sind die Rebuild-Fails in dem Link wesentlich schlechter als sie in Realtität sind. Und wenn das schon nicht berücksichtigt wurde, will ich gar nicht wissen was noch in der Rechnung fehlt. Der Link ist mit absoluter Vorsicht zu genießen. Auch wird immer bei dem "Draufhauen auf RAID 5" gerne TLER vergessen......

Deshalb dränge ich ja in fast jedem Post darauf, dass alles mit "der richtigen" Festplatte steht und fällt.


1) Daten werden gelesen
2) HDD hat problem einen Sektor zu lesen und startet die Recovery
3) Recovery dauer zu lange (> 7 Sekunden); TLER, ERC, the CCTL option wird an das System gesendet
4) Die HDD meldet einen Lesefehler (URE ist eingetreten)
5) Das RAID versucht aus bestehenden Paritäts Daten die fehlenden Daten zu rekonstruieren.
6) Beim Rebuild eines degraded Raids fehlt die Parität oder die original Daten je nach gerade erfolgter Operation und ss wird ein Sektor eben nicht so wiederhergestellt wie ursprünglich vorhanden. Kann also zu 1 korrupten Datei o.ä. führen. Aber nicht zu einem geschrotteten RAID Array - ohne TLER bzw. vergleichbaren Mechanismen wäre das Raid Array geschrottet, weil die Disk aus dem Array gekickt wird.

Wenn also die HDD beim Rebuild recovern muss, fliegt eine TLER fähige Platte nicht zwingend aus dem Verbund.

 

[I'm unknown]

Das heißt ich sollte mir dann wohl lieber ein 2x 6-Bay NAS anschaffen, 12x12TB, und RAID 10 verwenden.

Das erhöht die Performance und die Verfügbarkeit, ist aber nach wie vor kein Backup!

Wenn es nur um die Verfügbarkeit ginge bräuchte es doch kein RAID 5, dann bietet doch RAID 0 das gleiche.

Nein, ein RAID 0 erhöht nur die Performance.

Verfügbarkeit bei Raid 5/6/10 ist grob gesagt nur dass wenn eine Platte ausfällt die Daten für die User noch zugänglich sind (spart einem Arbeitgeber Geld wenn mal eine einzelne Platte ausfällt da die Leute noch weiterarbeiten können und nicht warten müssen bis ein Backup zurück gespielt wurde).

Gegen alles weitere wo ein Backup schützt hilft es nichts. Daher ist ein Raid eben oft sehr sinnvoll aber eben absolut kein Backup.

Es ist wichtig dass du das verstehst und dein Speicherkonzept so aufstellst dass du kein unnötig hohes Risiko hast für dich wichtige Daten zu verlieren. Ob du jetzt täglich ein Backup von dem komplettem Raid benötigst, nur einen Teil davon oder gar von manchen Daten gar keine Sicherung kannst nur du entscheiden.

Nur wenn du das in der Planung als sicheren Hafen ansiehst kann der Ärger in einem Schadenfall halt extrem hoch sein!

 

[Rickmer]

Verfügbarkeit bei Raid 5/6/10 ist grob gesagt nur dass wenn eine Platte ausfällt die Daten für die User noch zugänglich sind (spart einem Arbeitgeber Geld wenn mal eine einzelne Platte ausfällt da die Leute noch weiterarbeiten können und nicht warten müssen bis ein Backup zurück gespielt wurde).

Gegen alles weitere wo ein Backup schützt hilft es nichts. Daher ist ein Raid eben oft sehr sinnvoll aber eben absolut kein Backup.

Das sehe ich etwas anders...

1. ist das Backup meistens nur tagesaktuell, nicht Stunden- oder Sekundenaktuell, da geht also mehr als 'nur' die Wartezeit bis das Backup eingespielt ist verloren (abgesehen davon, dass dazu noch die Zeit kommt, Ersatzhardware zu beschaffen und einzubauen wenn man nicht 'ne cold spare auf Lager hat).
(Nahezu) verlustfreies und flottes Failover ist mehr Sache von Replication als Backup und Replication ist zwar der Zwilling vom Backup aber dann doch was anderes.

2. Das Backup ist auch irgendwo drauf gespeichert... wäre schon ziemlich kacke wenn monatelange Backupketten weg sind bloß weil eine HDD auf Streik geht.
(Klar, Backup Copy und/oder Kopie auf Band oder Cloud sollten trotzdem noch vorhanden sein - hat aber nicht jeder und läuft auch nicht immer perfekt. Ich kann dir ein Lied singen von Administratoren die zu faul sind die Bänder zu wechseln, geschweige denn die dann auch noch offsite aufzubewahren...)

 

[zak1976]

mal ehrlich, hier wird ja richtig viel Mi.t geschrieben.
Also bei einhergehenden Raid 5 und Raid 6 Systemen, mit einem aktuellem Raid Controller werden die Raidsysteme permanent auf Fehler überprüft, da passiert rein gar nix.
Raid 6 wird bei großen Kapazitäten eingesetzt um, während einer Rebuild Phase ausreichend Schutz für die Daten zu bieten, sollte in diesem Fall eine weiter Platte versagen, kann die Redundanz weiterhin hergestellt werden. Kauft man fertige Systeme sind die verbauten Festplatten immer aus unterschiedlichen Chargen, da sollte man auch drauf achten, wenn man sowas selbst aufbaut.
Nochmal an all die Schlauberger, die immer "Backup" anführen, ist immer leicht gesagt, aber dann müsst ihr auch mal Lösungen aufzeigen, anstatt immer klugzuscheissen, bei >40TB ist das gar nicht mal so einfach und auch nicht günstig ... Lösungsansätze sind gerne gesehen, wer kauft sich z.B. privat eine LTO8 Lösung und entspr. Software? Ich kenne hier keinen ...

 

[M-X]

Dafür hast du das ganze jetzt ausgegraben ? RAID bleibt halt kein Backup da kannst du noch so viele ** um dich werfen.

 

[conf_t]

Lösungsansätze sind gerne gesehen, wer kauft sich z.B. privat eine LTO8 Lösung und entspr. Software?

Ich antworte nur, weil das eine konkrete Frage ist und das wird die einzige Antwort bleiben.

Ein zweiter Storage, als bspw. zweites NAS, das nur für Backupzwecke eingeschaltet wird. Wer will schon LTO? Bisschen mehr Fantasie, bitte! Mein Haupt NAS hat 3x 20 TB im RAID 5 und mein Backup NAS 4x 18 TB im RAID 5. Das ganze im VPN Verbund mit 3 anderen Haushalten und man kann sogar die 3-2-1 Regel einhalten. In dem Verbund haben wir in Summe 238 TB Brutto Kapazität installiert, auf 6 Geräten. Dabei ist das Verhältnis zwischen Backupspeicher und Hauptspeicher so gewählt, dass ich sogar noch über Monate eine Versionierung anlegen kann. Man muss sich nur von Anfang an im Klaren sein, dass man für 1 MB Nutzspeicher das 2-4 fache an Brutto Speicher braucht, je nach gewünschter Verfügbarkeit und Versionierung des Backups

 

[Rickmer]

mal ehrlich, hier wird ja richtig viel Mi.t geschrieben.

Joa, u.A. auch von dir.
Für die Aussage hast du ein über 3 Jahre altes Thema ausgegraben?

Kauft man fertige Systeme sind die verbauten Festplatten immer aus unterschiedlichen Chargen

Bezweifel ich sehr stark.

Nochmal an all die Schlauberger, die immer "Backup" anführen, ist immer leicht gesagt, aber dann müsst ihr auch mal Lösungen aufzeigen, anstatt immer klugzuscheissen, bei >40TB ist das gar nicht mal so einfach und auch nicht günstig ... Lösungsansätze sind gerne gesehen, wer kauft sich z.B. privat eine LTO8 Lösung und entspr. Software? Ich kenne hier keinen ...

Backup Copy auf ein zweites System z.B. bietet sich an. Am besten in einem anderen Gebäude.
Wenn die Daten dir das nicht wert sind - tjoa, brauchst du die >40TB Daten dann auch wirklich?

 

[puri]

Sehe ich auch so - RAID und Backup haben nichts miteinander zu tun. Gerade, wenn die Platten älter sind und in einem größeren RAID mal eine ausfällt. Da beim Rebuild dann die Platten Tage/Wochenlang maximal belastet werden, passiert es gerne mal, dass dann gleich die nächste ausfällt, was bei einm RAID5 dann Exitus des gesamten Systems bedeutet.. Ich habe letzthin erst ein RAID5 mit 10 HDDs um eine HDD erweitert - der Rebuild hat 31 Tage gedauert - zum Glück ist nichts passiert, obwohl die Platten wirklich 24/7 auf Volllast gelaufen sind.. War auch nur der Backup-Server, also nichts produktives - sonst wäre ich das Risiko wahrscheinlich gar nicht eingegangen.

 

[Banned]

Ich habe letzthin erst ein RAID5 mit 10 HDDs um eine HDD erweitert - der Rebuild hat 31 Tage gedauert - zum Glück ist nichts passiert,

Das ist dann aber auch kein Rebuild im klassischen Sinne, wo eine HDD ausfällt und ersetzt wird. Das geht erheblich schneller.
In deinem Fall wäre Backup-Einspielen dann auf jeden Fall die bessere Variante gewesen. Würde ich auch jedem empfehlen, der sein RAID erweitern will, auch wenn es mittlerweile möglich ist, das auch direkt zu machen (Umbau).

 

[puri]

Das ist dann aber auch kein Rebuild im klassischen Sinne, wo eine HDD ausfällt und ersetzt wird. Das geht erheblich schneller.

Ich weiß nicht, ob ein echter Rebuild schneller wäre. Wenn ich mich recht erinnere, werden ab RAID5 ja die Daten zusammen mit der Parity-Informationen in "Streifen" über alle Platten verteilt. Sowohl beim echten Rebuild, wie auch beim Erweitern müssen alle Daten gelesen und neu geschrieben werden. Beim Rebuild auf eine Platte weniger, als beim Erweitern, was bei meinen 10 Platten dann vielleicht 10% gespart hätte. Bei einem RAID4 mit eigener Parity-Platte mag das anders aussehen (Hier ist der Rebuild grundsätzlich deutlich schneller). War auch nur ein Test, weil ich zu faul war das Raid zu löschen und neu aufzubauen und die 26 TB Robocopydaten neu kopieren zu lassen. Während des Rebuilds war die Schreibleistung um 50% langsamer (da aber täglich nur incrementelles Robocopy mit wenigen Dutzend GB war es vernachlässigbar) aber die Leseleistung praktisch unverändert (beim Transfer in Backup Exec und aufs Band)