Große Arrays als Raid5 laufen lassen?

Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
mal davon abgesehen, dass du bissl Off-Topic bist (siehe Threadtitel):
-die Thematik ist doch schon relativ ausdiskutiert und man ist der Meinung, dass bei grossen Arrays RAID6 RAID5 vorzuziehen ist?
Weiß nicht, ob du nun mich ansprichst, oder die restlichen Diskussionsteilnehmer. Eigentlich ist die Frage doch ganz einfach: Sind mir meine Daten der finanzielle Mehraufwand eines RAID6 gegenüber einem RAID5 wert?

-hast du den Thread überhaupt durchgelesen oder wolltest du nur deinen Senf dazugeben? ;)
Ich finds irgendwie amüsant, wie man ohne Ende Kohle in Daten-Sicherungstechnik steckt ohne zu analysieren, wodurch man denn am häufigsten Datenverlust hat. Ansonsten hast natürlich Recht, Thema verfehlt :F.

-machts den Eindruck, als hättest du nur soviel Daten, dass du nur theoretisch redest, ohne Bezug zur Praxis?
Da muss ich dann widersprechen, sind zwar jetzt keine 20+TB wie bei manch anderem hier, aber ~7TB sinds dann doch.

-wenn man verschiedene Datenarchive hat, die einzeln jeweils viele TB gross sind, kommt man bei einzelnen HDDs und "kleinen" Partitionen gar nicht drumherum, alles zu zerhacken und zu verschachteln, bzw hat nie alles im Überblick, wie es in grossen Partitionen aus grossen RAIDs der Fall ist?
Ich würd keine Backups in Archive oder Container packen, wenn es sich vermeiden lässt. Sowas würd ich höchstens mit der System-Partition machen.

-ich kenne einen, der alles auf einzelnen Festplatten hat, sowie die Platten vom Server auch noch als Netzlaufwerk verbunden hat. er hat das Problem, dass er im Alphabet zuwenig Buchstaben hat :p
Vielleicht sollte man ihm mal zeigen, wie man Laufwerke/Partitionen in Verzeichnisse mountet? Unter Linux ist das ja Standard, aber selbst Windows kann das!

-und warum sollten alle Server oder NAS nur mit 1xGbit angebunden sein? ich hab 2 PCs mit je 2xGbit. ich kenne Leute mit Mainboards mit 4xGbit und solche, die Netzwerkkarten mit 4xGbit verbauen. dann gibts noch die mit 10Gbit ...
Uh, das hab ich gar nicht behauptet, ich habe nur auf die Mehrzahl der NAS-/Server-Benutzer spekuliert. Aber in diesem Forum hast du sicherlich recht, dass es einige hier nutzen werden, aber ist es denn die Mehrzahl der RAID5-User? Trunking/Link Aggregation fähige Switche (vor allem mit höherer Portanzahl) wird man auch nicht wie Sand am Meer hier im Forum verstreut sehen.

mfg Oli
 
Zuletzt bearbeitet:
ist ein raid eigentlich beliebig erweiterbar? sprich erst einmal mit 3 oder 4 platten anfangen und später weitere integrieren? ist es möglich von einem raid 5 in ein raid 6 zu wechseln?
 
grundsätzlich ja, kommt auf den Controller an, aber ja, kann man, das eine nennt sich online capacity extension (Erweiterung), das andere nennt sich Raid level migration (Veränderung von 5 auf 6 oder weitere)
 
grundsätzlich ja, kommt auf den Controller an, aber ja, kann man, das eine nennt sich online capacity extension (Erweiterung), das andere nennt sich Raid level migration (Veränderung von 5 auf 6 oder weitere)

Bei der online capacity extension ist einfach zu beachten, dass danach entweder die bestehende Partition vergrössert werden muss, oder eine neue Partition erstellt werden muss.
Die vergrösserung von verschlüsselten Partitionen kann heikel werden... Nur so als Tipp :)

Gruss Mete
 
Yepp, richtig, die Erweiterung an sich aber ist kein Problem, "normalerweise" mit Bordmitteln von Win auch kein Thema, Stichwort diskpart. Auch bei anderen OS.
Oder eben eine neue Partition. Verschlüsselung ja, da gehe ich auf Nummer sicher und entferne die Verschlüsselung und erweiter dann, gut dauert, aber sicherer ist das.
 
ok viele dank! jetzt brauch ich nur noch einen raid-controller mit 8 internen anschlüssen und passende 2tb platten (24/7). anfang wird dann erstmal mit 3 oder 4 platten sein und wird dann später bei bedarf erweitert.

wo liegt denn der unterschied bei de wd-platten zwischen re4 und re4-gb? was gäbe es noch als alternative?
 
Hallo zusammen und vorerst ein großes sorry, das ich diesen Thread nochmals rauskrame...aber was soll ich nun einen neuen Thread erstellen wenn ich nach vielem Belesen nur eine Frage habe, auf die leider nirgends so direkt eingegangen wird ;)

Folgendes: In allen Erklärungen zum Thema URE wird das Entstehen der URE´s erklärt, ob meine Platten nun einen BER von 10^14 oder 10^15 ist mir hierbei erstmal egal, dem würde ich sowieso nicht vertrauen :shot:

Die eigentliche große Gefahr besteht ja nun vor allem beim Rebuild im Falle des Plattenausfalls, zumindest so wie ich das verstanden habe.
Wenn ich also nun einen Plattenausfall habe (sagen wir mal bei einem Raid5 von 4x4TB) oder einen URE auf einer Platte bekomme, durch den mein Raid5 degraded wird, sind meine Daten aufgrund der Parität ja nach wie vor vorhanden und auch lesbar. In so einem Fall sollte man nun in erster Linie ein aktuelles Backup ziehen (da mein bestehens Backup ggf. schon älter ist) und KEINEN Rebuild mit einer neuen Platte starten. Selbst wenn beim Backuperstellen bzw. beim Lesen der gesamten Daten nun ein weiterer URE auftreten sollte, ist doch lediglich diese Datei nicht lesbar, alle anderen Daten jedoch schon, das Raid5 wäre nun nicht komplett ausgefallen...oder würde ein weiterer URE bei einem bereits herabgestuften Raid5 einen Totalausfall verursachsen? Kann ich mir nicht vorstellen, sicherlich wäre nur dieser Block verloren.

Nach dem Backup könnte ich nun ein Rebuild versuchen. Sollte dieser fehlschlagen aufgrund eines weiteren URE während des Rebuilds, ist mein Raid5 zwar futsch und alle Daten weg, aber ich habe ja den aktuellen Stand gesichert.

Sehe ich das bisher alles korrekt? Denn das würde bedeuten, das ich ohne Weiteres ein Raid5 einsetzen kann und wäre im Falle eines kompletten Festplattenausfalls nach oben beschriebener Vorgehensweise sicher. Ich müsste nur darauf achten, das mein Controller im Falle eines URE´s kein eigenständiges/automatisches Rebuild der vorhandenen Festplatten startet, denn die eigentliche Gefahr bei Raid5 im Zusammenhang mit großen Festplatten und URE ist der Rebuild...richtig?

Und am Ende noch eine kleine Frage zum Windows ReFS: Wenn ich in Windows 10 einen Storagepool mit beschriebener Konfiguration und dem Dateisystem ReFS erstellen würde, hilft mir das in irgendeiner Weise oder ist die Warscheinlichkeit von URE´s genau so hoch?

Vielen Dank für eventuelle Antworten :hail:
 
Zuletzt bearbeitet:
Definiere Plattenausfall! Ist es schon ein Ausfall wenn ein unkorrigierbaren Bitfehler auftritt? Ein Rebuild einer RAID5 bricht dann ab, aber die UBER beschreibt wie häufig damit zu rechnen ist, ohne das die HDD damit ihre Spezifikationen verlässt, also als defekt zu werten wäre. Bei einer UBER von 1:10^14 ist das einmal etwa pro jeweils rund 12TB gelesener Daten der Fall, bei 1:10^15 einmal alle etwa 120TB. Wobei so ein Fehler nicht zwangsweise kommen muss, aber eben kann und damit ist die HDD dann immer noch im perfekten Zustand, ein Rebuild eines RAID 5 wäre aber gescheitert wenn dabei eine Platte so einen Fehler hat.

Vergiss also nicht, dass RAIDs eben keine Backups ersetzen und wenn man dies berücksichtigt, dann ist man einigermaßen sicher, denn Sicherheit ist immer relativ und nur auf einem RAID 5 sind die Daten relativ unsicher, auf einem RAID6 ein wenig sicherer und mit einem Backup steigt die Sicherheit, mit zwei Backups noch mehr usw.

Serverfilesysteme wie ZFS, btrfs oder ReFS würde ich nur mit Server-HW und Backup nutzen, also auf einem Rechner mit ECC-RAM und wo natürlich der Rest der HW dies auch unterstützt, also Board und CPU. Diese FS erwarten einfach die Korrektheit der Informationen im RAM, wenn Daren dort korrumpiert werden, zerschießt man sich schneller die Daten auf der Platte als bei normalen Filesystemen, weil nach deren Logik inkorrekte Daten immer auf Fehlern der Platten beruhen und die Fehler dann dort korrigiert werden, womit korrekte Daten im Zweifel kaputt korrigiert werden, nur weil das RAM nicht zuverlässig ist. Dann nie ohne Backup, weil RAID keine Backups ersetzen und denn zumindest es für ZFS kein Tool gibt um ein korruptes Filesystem zu recovern. Dies auch nicht wirklich nötig, Profis setzen lieber das FS neu auf spielen das letzte Backup zurück, weil man eben recht gut abschätzen kann wie lange man dafür brauchen wird und die Frage wann das System wieder laufen wird, oft vor der Frage kommt was passiert ist. Sowas wie chkdsk mit unbekannter Zeitdauer und vor allem kaum abschätzbaren Erfolg, kann man da nicht brauchen.
 
Serverfilesysteme wie ZFS, btrfs oder ReFS würde ich nur mit Server-HW und Backup nutzen, also auf einem Rechner mit ECC-RAM und wo natürlich der Rest der HW dies auch unterstützt, also Board und CPU. Diese FS erwarten einfach die Korrektheit der Informationen im RAM, wenn Daren dort korrumpiert werden, zerschießt man sich schneller die Daten auf der Platte als bei normalen Filesystemen, weil nach deren Logik inkorrekte Daten immer auf Fehlern der Platten beruhen und die Fehler dann dort korrigiert werden, womit korrekte Daten im Zweifel kaputt korrigiert werden, nur weil das RAM nicht zuverlässig ist. Dann nie ohne Backup, weil RAID keine Backups ersetzen und denn zumindest es für ZFS kein Tool gibt um ein korruptes Filesystem zu recovern. Dies auch nicht wirklich nötig, Profis setzen lieber das FS neu auf spielen das letzte Backup zurück, weil man eben recht gut abschätzen kann wie lange man dafür brauchen wird und die Frage wann das System wieder laufen wird, oft vor der Frage kommt was passiert ist. Sowas wie chkdsk mit unbekannter Zeitdauer und vor allem kaum abschätzbaren Erfolg, kann man da nicht brauchen.

Gute Hardware, ECC RAM und Backups verringern die Wahrscheinlichkeit eines Datenverlusts.
Diese Aussage ist unwidersprochen und so wahr wie tags ist es meist heller als nachts.

Deine wirklich ganz persönliche Meinung dass moderne CopyOnWrite Dateisysteme mit Prüfsummen über Treiber, Controller, Kabel, Backplane und Platte ganz allgemein weniger robust gegen Probleme , egal ob Ramprobleme oder andere sein sollen, wird weder von den ZFS Entwicklern noch der Mehrzahl der ZFS Gemeinde geteilt. Im Gegenteil. ZFS ist Crashresistent By Design. Ein atomarer Schreibvorgang witd entweder komplett oder nicht durchgeführt. Ein Crash beim Schreiben ist bei ZFS aus Sicht des Dateisystems unkritisch, bei anderen führt es zu einer potentiellen Matadaten Korruption das erst ein fschk/chkdsk beseitigen kann. Im Falle eines Raid z.B. eines Mirrors führt das ohne ZFS eventuell auch zu einer unentdeckten Raid Korruption. Alle Updates im Raid werden nacheiander ausgeführt. Ein Crash beim Schreiben und ein Mirrorteil hat neue Daten, die andere Hälfte nicht. One ZFS gibts wenig Möglichkeit das zu verhindern (z.B. Cache+BBU) und keine dasd zu reparienen (mangels Prüfsummen). Bei ZFS passiert das nicht per Design (nennt sich Write Hole Problem)

Ich würde mich schon als Profi sehen. Das Wiederaufsetzen eines FS mit Restore ist aber das allerletze was ich machen möchte. Auf keinen Fall ist es die primäre Verteidigungs-Strategie gegen Datenverlust. Erstmal ist das Backup nie ganz aktuell. Dann sind in Zeiten von Ransomware viele Backups nötig da eine Infektion schleichend verläuft. Auch ist es nicht wirklich lustig ein 50TB+ restore zu machen. ZFS, ausreichendes Raid-Levels und viele Snaps + Disaster Backup ist da erheblich professioneller.

Und ja, chkdsk/fsch im Offline Modus das Tage dauern kann, kann tatsächlich niemand brauchen. Das gibts mit neuen CopyOnWrite Dateisystemen aber auch nicht mehr (Selfheaiing. die Reparieren sich im Betrieb selbsständlg - soweit möglich).

Ach Ja
Ein Lesefehler im degraded Raid Z1 (Pendant zi Raid 5/aber ohne Write Hole Problem daher anderer Name) führt im Gegensatz zu Raid-5 nicht zu einem Abbruch des Rebuild sondern zu einer fehlerhaften Datei. ZFS Raid-Z1 kennt ja im Gegensatz zu Raid-5 die tatsächlich betroffene Datei und kann den Fehler eingrenzen. Dies ganze Uber Diskussion ist da aus ZFS Sicht erheblich entspannter bis obsolet. Wenn das passiert, einfach die eine Datei aus dem Backup wiederherstellen und Uber Problem ist beseitigt. Uber ist ein Raid-5/6 Problem das durch ZFS als gelöst/entschärft gesehen werden kann.

BTRFS kann ja noch kein stabiles Raid 5/6 artiges. ReFS sollte sich vermutlich im Paritymodus - sofern Prüfsummen auf Daten aktiviert ist wie ZFS verhalten. ZFS ist ja das Vorbild von ReFS (Grausam, wie man was Einfaches wie ZFS verkomplizieren kann)
 
Zuletzt bearbeitet:
Deine wirklich ganz persönliche Meinung dass moderne CopyOnWrite Dateisysteme mit Prüfsummen über Treiber, Controller, Kabel, Backplane und Platte ganz allgemein weniger robust gegen Probleme , egal ob Ramprobleme oder andere sein sollen
Wo habe ich behauptet die wäre weniger robust gegen egal welche Probleme? Trolle unterstellen anderen unsinnige Behauptungen um diesen dann zu widersprechen, bist Du ein Troll? Dann kommst Du auf meine Ignoreliste. Wenn Du kein Troll sondern wirklich ein Profi sein willst, lies meine Aussage noch einmal gründlich.
 
Das mit dem Profi ist immer so eine Sache und Bedarf der dauernden Kritik und Reflektion.
Zuerst weiß man wenig, dann ist man König. Wenn man weiter lernt erkennt man dann aber wie wenig man doch weiß. Nicht umsonst fängt man beim Kampfsport mit weiß an und endet als aboluter Meister wieder als Weißgurt.

Ich bin jetzt 28 Jahre RZ Leiter einer Hochschule, beschäftige mich seit bald 10 Jahren intensiv mit (OpenSource) Storage und ZFS und habe auch seither meine eigene ZFS Storage Appliance. Ich bin seither intensiv im Kontakt mit ZFS Benutzern aus aller Welt. Ja ich denke ich weiß viel über ZFS und sehe das auch als DIE Storage-Innovation der letzten 10 Jahre. Unvoreingenommen bin ich da nicht. Ob mich das als Profi qualifiziert - muss nicht mein Problem sein.

Du kannst mich gerne ignorieren, ich werde deiner Meinung dennoch meine gegenüberstellen wenn ich anderer Ansicht bin.
 
Dann bemühe Dich aber künftig auch mal darum meine Meinung wirklich korrekt zu verstehen und unterstelle mir nicht Dinge die ich nie behauptet habe. Sowas kann ich nicht ab, für mich machen nur Trolle sowas.
 
Ich schätze deine Beiträge und verstehe sie durchaus bin aber teils anderer Meinung wenn es um ZFS geht.
Ich versuche meine Meinung dann aber ohne persönliche Angriffe darzustellen und zu untermauern.
 
Wieso unterstellst Du mir dann so einen Blödsinn wie zu glauben "moderne CopyOnWrite Dateisysteme mit Prüfsummen" wären "ganz allgemein weniger robust gegen Probleme"? Sie sind anfälliger gegen RAM Fehler, auch weil sie ohne ECC RAM sowieso keinen Sinn machen, es wäre die die Fenster zu vergittern aber die Türen nicht abzuschließen.
 
Wieso unterstellst Du mir dann so einen Blödsinn wie zu glauben "moderne CopyOnWrite Dateisysteme mit Prüfsummen" wären "ganz allgemein weniger robust gegen Probleme"?

Einfach weil du Thesen aufstellst hinsichtlich ZFS die ich nicht teile

Sie sind anfälliger gegen RAM Fehler

nicht belegt, selbst der Entwickler von ZFS verneint das explizit.
Auch wenn es andere z.B. im FreeNAS Forum gibt die das auch so sehen.

Richtig ist, dass RAM Fehler zu unerkannter Datenkorruption führen können-
bei ZFS wie bei jedem anderen FS auch.

auch weil sie ohne ECC RAM sowieso keinen Sinn machen,

Persönliche Meinung. Ich seh das ganz anders.
Die Wahrscheinlichkeit korrupter Daten ist mit ZFS viel geringer als mit Nicht CoW Dateisystemen - egal ob mit oder ohne ECC.
ECC verringert in beiden Fällen allerdings die Wahrscheinlichkeit von Probleme. Bei ZFS sind unentdeckte Ramfehler so ziemlich das einzige Problem gegen dass ZFS selber nichts unternehmen kann.

Will ZFS and non-ECC RAM kill your data? | JRS Systems: the blog

es wäre die die Fenster zu vergittern aber die Türen nicht abzuschließen.

Sehe ich wie beim Autofahren.
Jede Sicherheitsmassnahme verbessert die Sicherheit. Es macht keinen Sinn Sicherheitsgurt gegen ABS auszuspielen. Was, kein ABS - dann brauchts den Gurt auch nicht.

Ich würde mir heute kein Auto mehr ohne modernes ESP kaufen. Niemand würde ein professionelles System ohne ECC RAM nehmen. Insofern ist das Thema allenfalls bei LowCost @home relevant.


- Allerdings ist die Argumentationslinie oft so, kein ECC, dann ist ext4 viel besser und sicherer als ZFS.
Das sehe ich so nicht, ganz und garnicht.

-Auch sei ntfs oder ext4 + Raid-5/6/SHR viel einfacher um einzelne Platten zu erweitern und deshalb die beste Lösung. Mag für einen Home-Mediaserver korrekt sein, bei wichtigen Daten ist das absolut unterlegen.


- auch gäbe es bei ZFS kein Prüftool wie chkdsk das bei Fehlern hilft
ZFS und Copy on Write wurde deswegen entwickelt um Dateisysteme immer valide zu halten und eventuelle Fehler on the Fly zu reparieren, Deswegen auch Self-Healing, Checksums und doppelte Matadaten. Dazu Prüfsummen um alle Daten generell zu verifizieren. Daten prüfen ist quasi permanent, bei jedem Zugriff aktiv.

Was richtig ist, es gibt kein gängiges Tool um aus einem defekten ZFS Pool teilweise Dateien zu retten was bei ntfs oder ext möglich ist. Ein ZFS Pool ist viel robuster wenn er aber mal crashen sollte dann richtig. Ist mir persönlich noch nie passiert. NTFS Arrays habe ich aber schon mehrfach verloren. Chksdk mit tausenden Fragmenten waren dann aber auch nicht hilfreich.


-Raid ist eh sehr unzuverlässig, Backup und Restore daher das Mittel der Wahl um üblicherweise Probleme zu beheben.

Sehe ich ganz anders. Backup ist der Reservefallschirm. Ziel ist nicht den bei Problemen zu nutzen sondern das mit allen Mitteln zu vermeiden. Viel wichtiger ist es dass das Flugzeug nicht abstürzt. Besonders sichere Dateisysteme wie ZFS im Zweifel mit Hunderten von Snapshots auf einem sicheren Raid Z2/3 Pool ist nahezu unkaputtbar. Gegen versehentliches Löschen, User-Sabotage, Viren, Randsomware etc schützt man sich durch die Readonly CoW Snapshots. Der nötige Schutz gegen die alltäglichen Probleme.

Das Backup schützt gegen üble Bugs, massive Harwareprobleme, Feuer, Überspannung, Diebstahl oder Admin-Sabotage. Der absolute Disaster Fall eben.
 
Zuletzt bearbeitet:
Einfach weil du Thesen aufstellst hinsichtlich ZFS die ich nicht teile
Das ist in Ordnung, aber für jemanden der sich 10 Jahre damit befasst hat, solltest Du es eigentlich besser kennen.

nicht belegt, selbst der Entwickler von ZFS verneint das explizit.
Tut er das? Und wer ist der Entwickler? Ich diese Aussagen von Matt Ahren, der ist einer der Mitentwickler des ZFS-Dateisystems:
Man beachte die Reihenfolge, zuerst empfiehlt er ECC RAM, wenn man seine Daten liebt und der Rest sagt nicht mehr als, ECC RAM ist eben keine Voraussetzung um ZFS betreiben zu können.
Richtig ist, dass RAM Fehler zu unerkannter Datenkorruption führen können-
bei ZFS wie bei jedem anderen FS auch.
Korrekt, aber wenn Du die Funktionsweise der Fehlerkorrektur in ZFS kennen würdest, dann könntest Du auch nachvollziehen, wieso die Aussagen von Matt Ahren "There's nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem" nicht quantitativ zu sehen ist, sondern eben genau unter dem Aspekt, dass es eben egal ist welches FS man nutzt, wenn man kein ECC RAM hat, weil dort das größere Risiko steckt: "If you use UFS, EXT, NTFS, btrfs, etc without ECC RAM, you are just as much at risk as if you used ZFS without ECC RAM." Danach dann eben kommt dann auch der Hinweis zuerst ECC RAM zu nutzen.

Bei ZFS sind unentdeckte Ramfehler so ziemlich das einzige Problem gegen dass ZFS selber nichts unternehmen kann.
Selbst das stimmt ja nicht, denn ZFS kann etwas machen um das Risiko zu reduzieren: "ZFS can mitigate this risk to some degree if you enable the unsupported ZFS_DEBUG_MODIFY flag (zfs_flags=0x10). This will checksum the data while at rest in memory, and verify it before writing to disk, thus reducing the window of vulnerability from a memory error."

Niemand würde ein professionelles System ohne ECC RAM nehmen. Insofern ist das Thema allenfalls bei LowCost @home relevant.
Eben und für LowCost @home ist so ein Filesystem nicht gedacht, aber wird oft auch genau dort eingesetzt und dann muss die Frage erlaubt sein, ob es dort Sinn macht und man muss auch die Nachteile sehen, wie z.B. die fehlende Möglichkeit weitere HDDs in den Pool so einzufügen, dass sie vollständig integriert sind.

- Allerdings ist die Argumentationslinie oft so, kein ECC, dann ist ext4 viel besser und sicherer als ZFS.
Das sehe ich so nicht, ganz und garnicht.
Das ist Deine Sache, befasse Dich mit dem Mechanismus der Fehlerkorrektur und wie RAM Fehler sich diesen dann auf die Daten auf den Platten auswirken. Vergleiche das mit dem was RAM Fehler bei einem SW-RAID mit ext Filesystem machen würden. Dann müsstest Du allerdings Deine Meinung revidieren, nur fürchte ich wirst Du dazu nicht gewillt oder in der Lage sein.

-Auch sei ntfs oder ext4 + Raid-5/6/SHR viel einfacher um einzelne Platten zu erweitern und deshalb die beste Lösung. Mag für einen Home-Mediaserver korrekt sein, bei wichtigen Daten ist das absolut unterlegen.
Ja wie jetzt? Hängt es von der Wichtigkeit der Daten ab ob man einen ZFS Pool um zusätzliche Platten erweitern kann? Das wäre mir aber neu, dass ein Filesystem abhängig von der Wichtigkeit der Daten funktikoniert :fresse2:

- auch gäbe es bei ZFS kein Prüftool wie chkdsk das bei Fehlern hilft
ZFS und Copy on Write wurde deswegen entwickelt um Dateisysteme immer valide zu halten und eventuelle Fehler on the Fly zu reparieren, Deswegen auch Self-Healing, Checksums und doppelte Matadaten. Dazu Prüfsummen um alle Daten generell zu verifizieren. Daten prüfen ist quasi permanent, bei jedem Zugriff aktiv.
Klar, nur leider haben auch schon Leute ihre Pools verloren, wie konnte das nur passieren, bei dem auch so selbstheilenden Filesystem das immer valid ist und nicht mal ECC RAM braucht?

NTFS Arrays habe ich aber schon mehrfach verloren. Chksdk mit tausenden Fragmenten waren dann aber auch nicht hilfreich.
CHKDSK ist kein Datenrettungstool und was meinst Du mit einem NTFS Array? NTFS ist kein Filesystem mit integrierter RAID Funktion wie ZFS, Du wirst hier alles durcheinander wie es Dir gefällt, von viel Ahnung zeugt das nicht. Das Thema ist hier für mich daher zuende.
 
Hallo und danke für eure Antworten, auch wenn es ein wenig in Richtung OT ging...

Leider ist meine Frage aber noch nicht ganz beantwortet:

Wann besteht denn die "große" Gefahr des Raid5 von der alle reden in Verbindung mit URE nun genau? Des heißt wann könnte es mir durch URE´s das RAID 5 Array komplett zerstören (mal unabhängig vom Filesystem, das haben wir ja nun beschrieben):

A: plötzlich wärend des laufenden Raid 5
B: während eines herabgestuften Raid 5
C: oder erst, wenn nach herabstufen ein Rebuild gestartet wird

-> in Detail habe ich die Frage ja schon auf Seite 3 gestellt ;)

Danke für Aufklärung :drool:
 
A.) Plötzlich während des Betriebs ist bei einem echten RAID (also einen RAID mit Redundanz wofür das R in RAID steht, wie z.B. einem RAID 5), passiert bei einem Lesefehler folgendes: Der RAID Controller (ggf. eine SW beim einem SW-RAID) wird bei einem Lesefehler (die UBER die Wahrscheinlichkeit an mit der man damit rechnen muss) bekommt statt der Daten einen Lesefehler von der HDD gemeldet. Daraufhin wird er die Daten in dem Bereich aufgrund der Parity rekonstruieren und den betroffenen Sektor auf der Platte überschreiben, diese prüft dann (und nur dann) die Daten nach dem Schreiben und ersetzt den schwebenden Sektor ggf. durch einen Reservesektor). Wenn bei einem RAID mit einfacher Redundanz wie einem RAID 5 nun ein zweiter Fehler passiert, dann hat man ein Problem, nur ist es eben extrem unwahrscheinlich, dass dies passiert. Daher passiert dann außer einer gewissen Verzögerung gar nichts weiter und das RAID hat gegenüber einer einzelnen HDD hier einen klaren Vorteil.

B.) Hier hat man den Effekt wie bei einer einzelnen HDD, wenn ein Fehler auftritt, kann man die betroffenen Daten nicht mehr lesen. Wenn man richtig Pech hat, dann sagt der RAID Controller danach auch noch, dass nun ein RAID 5 welches nun keine Redundanz mehr hat, nicht mehr nur degradiert ist, sondern komplett unbrauchbar, denn ein Rebuild kann ja nun nicht mehr gelingen. Zumindest die Datei die dort stand und wenn man Pech hat und es Metadaten des Filesystems waren, dann auch mehrere oder das ganze Filesystem, darf man dann aus dem Backup rekonstruieren.

C.) Hier ist das größte Problem, denn ein normaler RAID 5 (oder RAID 1) wird dann abbrechen, eben weil es die Daten des RAIDs nicht mehr konsitent sind. Wenn man kein RAID mit mehrfacher Redundanz (RAID 6) hat, dann kann man die ursprünglichen Daten eben nicht mehr wiederherstellen. In aller Regel darf man nun sein Backup wieder einspielen.
 
1.
Unrecoverable read errors kommen bei non-raid edition Festplatten so gut wie nie vor. [kein TLER]
Die kommen erst wenn die Festplatte kurz vor dem endgültigen Versagen steht.
Was bei funktionierenden Festplatten gelegentlich vorkommt das ein Recoverable Lesefehler auftritt.
Die Platte wird den Sektor durch mehrfaches lesen retten und nimmt aber in der Zeit aber keine Befehle entgegen.
Und das ist das Problem #1 mit RAID Controllern weil er dann in selbstzestörerischer weise die Platte aus dem RAID wirft wenn sie zu lange für eine Antwort braucht.

2.
RAID und RAID Controller sind für größere Datenlager TOT.

die Fehlerrate von 10^14 bedeutet einen undetektierten Lesefehler alle 12Tb gelesene Daten.
Das sind fehlerhaft gelesene Sektoren ohne das die Festplatte einen Fehler meldet.
Man bekommt Datenmüll von der Platte, aber merkt es nicht!
Und Ja das ist nicht nur eine Zahl ohne praktische bedeutung: das kommt auch in der Praxis so vor.
Meine 4TB festplatten liefern etwa alle 12TB einen Checksum fehler, wie ein Uhrwerk. [alle 3-4 scrubs]
Ja enterprise Platten sind da besser aber wir reden hier ja über billigst Home Storage.

3.
Der einzige Weg zuverlässige Datenspeicher mit den aktuellen hochkapazitäts Festplatten zu bauen ist ZFS/BTRFS/SnapRAID mit checksums und ausreichend Redundanz.
Alle systeme mit nur einfacher Redundanz (Raid 1&5) sind nicht mehr zeitgemäß.

4.
Deine Daten wandern immer durch den RAM, mit oder ohne ZFS.
 
1.
Unrecoverable read errors kommen bei non-raid edition Festplatten so gut wie nie vor. [kein TLER]
So wie alle alle anderen Punkte ist auch das totaler Blödsinn. TLER bedeutet nur, dass man einstellen kann wie lange eine HDD versucht einen Sektor doch noch erfolgreich zu lesen und das in aller Regel dieser Timeout an Wert kürzer eingestellt ist als bei HDDs ohne TLER/ERC. Bei der WD Red (mit TLER) sind es 7s, bei der Green 14s. Bei 5400 rpm sind das also pro Sekunde rund 90 Versuche weil der Sektor 90mal unter dem Kopf durchkommt und damit für die Red etwa 630 Versuche einen Sektor doch noch erfolgreich zu lesen (sofern man die Zeit nicht verändert hat, was nur bei HDDs mit TLER / ERC geht). Wie gut mag die Chance bei weiteren 630 Versuchen wohl sein, wenn es bei den ersten 630 nicht geklappt hat? Ich weiß es nicht, aber offenbar nicht so gut, als dass die Hersteller denen eine bessere UBER in die Datenblätter schreiben würden und die Platten mit TLER/ERC haben eine bessere UBER von 1:10^15.

Die kommen erst wenn die Festplatte kurz vor dem endgültigen Versagen steht.
Du hast offenbar noch nie bei einer HDD die einzeln läuft schwebende Sektoren gesehen oder jede sofort ausgetauscht nur weil es mal einen gab und Du Angst vor einem baldigen Totalausfall hattest. Dabei verläuft die Rate der unkorrigierbaren Bitfehler bei HDDs relativ konstant während der vom Hersteller geplanten Nutzungsdauer (von üblicherweise 5 Jahren), solange man die HDDs innerhalb der Spezifikationen betreibt und eben nicht misshandelt. So sieht das aus, hier im Vergleich zu SSDs:

attachment.php


Was bei funktionierenden Festplatten gelegentlich vorkommt das ein Recoverable Lesefehler auftritt.
Das ist alltäglich, dafür gibt es die ECC hinter jedem Sektor und diese Fehler berichten HDDs nicht einmal in den S.M.A.R.T. Werten.

Die Platte wird den Sektor durch mehrfaches lesen retten und nimmt aber in der Zeit aber keine Befehle entgegen.
Und das ist das Problem #1 mit RAID Controllern weil er dann in selbstzestörerischer weise die Platte aus dem RAID wirft wenn sie zu lange für eine Antwort braucht.
Das können aber alle HDDs und machen es auch, außer man sagt ihnen etwas anderes, dafür gibt es extra gesonderte Befehle. Diese verwenden aber nur SAS/FC RAID Controller und auch nur, wenn sie dafür die Platten mit 520/528 Byte pro Sektor formatiert haben, was bei SATA Platten schon gar nicht geht. In in diese 8 oder 16 extra Bytes schreibt der Controller selbst eine Prüfsumme und kann so Lesefehler sofort erkennen und dann anhand der Daten der anderen Platten, also auch der Parity dann die fehlenden Daten rekonstruieren und den defekten Sektor wieder überschreiben. Dies geht schneller als eben auf die Wiederholungen zu warten und blockiert das Storage nicht. Bei SATA Platten muss man eben die Krüppellösung mit dem TLER/ERC machen.

2.
RAID und RAID Controller sind für größere Datenlager TOT.
Wieso? Und was nimmt man an deren Stelle? HW RAID Controller zwar in der Tat auf einem absteigenden Ast, da SW RAIDs heute viel mehr können als früher und bei Enterprise Storage sind SSD und gerade auch NVMe SSDs auf dem Vormarsch für die nur SW RAID in Frage kommen, aber RAIDs sind nach wie vor Pflicht für große Datenlager. Egal wie man diese realisiert und nennt.

die Fehlerrate von 10^14 bedeutet einen undetektierten Lesefehler alle 12Tb gelesene Daten.
Jein, es kann, muss aber nicht zwangsläufig pro 12TB gelesener Daten zu einem Lesefehler kommen.
Das sind fehlerhaft gelesene Sektoren ohne das die Festplatte einen Fehler meldet.
Nein, die HDDs geben dann eine Lesefehler aus, der Controller bekommt also keine falschen Daten, ausgenommen bei besonderen Befehlen wie den ATA Streaming Befehlen für Echtzeitvideoaufzeichnung wo man dies bewusst akzeptiert!
Man bekommt Datenmüll von der Platte, aber merkt es nicht!
Genau das ist ein Märchen welches nicht auszurotten ist. Wenn das passiert, dann hat die SW die den Lesebefehl gegeben hat diesen ignoriert und trotzdem so getan als wäre die Datei korrekt und vollständig geladen worden oder der Treiber hat den Lesefehler verschluckt. Viel wahrscheinlicher ist aber bei Heimanwendern ein RAM-Fehler, denn alle Daten gehen über das RAM und kaum ein Heimanwender hat ECC RAM und ein System welches dies auch unterstützt. Eine andere Möglichkeit wären ein Fehler auf den internen Datenpfade der Platte, hier vor allem im Cache RAM, denn dagegen haben meist nur die besseren Enterpriseplatten einen Schutz und nicht einmal alle HDDs haben eine Erkennung solcher Fehler, die als Ende-zu-Ende Fehler in den S.M.A.R.T. Werten zu finden sind. Gibt es das Attribut nicht, meist ist es 0xB8 = 184, so hat die Platte auch keinen Schutz. Die Übertragung über SATA ist mit einer CRC32 pro FIS (maximal 8128 Byte Nutzdaten) geschützt, diese macht unerkannte Bitfehler bei der Übertragung praktisch unmöglich. Google mal selbst, aber einer CRC32 entkommt über 8192 Byte nur einmal so alle ich meine 10^46 mal ein Fehler, was mal 8k dann einem Datenvolumen entspricht welches weit jenseits dessen ist, was jemals an HDDs gefertigt wurde. Die ECC hinter einem physikalischem Sektor von 4k ist so um die 50 bis 100Byte lange, der entkommt auch praktisch kein Fehler unerkannt, an den beiden Stellen passieren also wirklich keine Fehler. Dann schon eher im Puffer des Host Controllers oder bei dessen FW bzw. der FW der Platte (gab es bei der HD204 im Zusammenhang mit dem Identify Device Befehl und NCQ). Dann könnte es noch bei der Übertragung zwischen dem Host Controller und der CPU/dem RAM Controller passieren, aber PCIe ist auch mehr oder wenig abgesichert, bei Enterprise-HW mehr, bei Consumer HW weniger.

Das HDDs selbst falsche Daten liefern ist bei Enterprise HDDs so gut wie ausgeschlossen, außer ein FW Bug ist im Spiel und auch bei Consumer HDDs dürfte es sehr selten sein. Ich sehen die S.M.A.R.T. Werte vieler HDDs, nicht wenige Consumer HDDs von Seagate haben das Ende-zu-Ende Fehlerattribut aber nur bei ganz, ganz wenigen tratt da wirklich mal so ein Fehler auf.
Meine 4TB festplatten liefern etwa alle 12TB einen Checksum fehler, wie ein Uhrwerk. [alle 3-4 scrubs]
Was dem widerspricht was Du unter 1 behauptet hast, wonach es nur am Lebensende passieren dürfte. Schwebende Sektoren wird sie aber trotzdem nicht bekommen, da ja ein RAID die Daten sofort überschreibt und dann prüft der Controller der Platte ob die neuen Daten nun korrekt gelesen werden können, damit verschwindet der schwebende Sektor sofort wieder und es wird ggf. ein Reservesektor aktiviert, wenn die Date nun nicht mehr korrekt gelesen werden können, was aber längst nicht immer der Fall ist.
Ja enterprise Platten sind da besser aber wir reden hier ja über billigst Home Storage.
Was außer RAIDs sollte man dort dann nehme, wenn Du RAIDs für TOT erklärt hast?
3.
Der einzige Weg zuverlässige Datenspeicher mit den aktuellen hochkapazitäts Festplatten zu bauen ist ZFS/BTRFS/SnapRAID mit checksums und ausreichend Redundanz.
So ein Blödsinn. Es gibt auch Consumer HDDs mit hoher Kapazität und einer UBER von 1:10^15 wie z.B. die Seagate NAS/Ironwolf Reihe die ab der 6TB so eine UBER von 1:10^15 hat. Die Checksums sind schön und gut, aber ohne ECC RAM und passendes System würde ich die Finger davon lassen, zumindest wenn man auch noch die automatische Fehlerkorrektur aktiviert hat. Außerdem lässt sich zumindest bei ZFS keine weitere Platte ins RAID integrieren, die werden nur wie bei JBOD/BIG angehängt und genießen dann aber nicht den gleichen Schutz wie die Platten im RAID.

Wichtiger als die SW mit der man das RAID baut ist an das Backup zu denken!
Alle systeme mit nur einfacher Redundanz (Raid 1&5) sind nicht mehr zeitgemäß.
Wieso? Bei einer UBER von 1:10^15 sollte es nur maximal alle gelesenen 120TB zu einem Lesefehler kommen und damit hat man bei einem RAID 5 mit 5 10TB HDDs dann immer noch eine theoretische Chance von über 70% auf ein erfolgreiches Rebuild und selbst bei einem RAID 8 mit 8 davon ist die Chance noch bei über 54%.

4.
Deine Daten wandern immer durch den RAM, mit oder ohne ZFS.
Daher sollte ECC RAM immer Pflicht sein, wenn man ein größeres Storage baut und mehr Wert auf Sicherheit vor Datenkorruption legt als die billige Desktop-HW bietet und die bietet nur so viel, dass es meistens bei den meisten Leuten keine größeren Probleme gibt. Also nur das Mindestmaß damit die Leute das Zeug noch kaufen und es trotzdem so billig wie möglich hergestellt werden kann. "I would simply say: if you love your data, use ECC RAM."

UBER_HDD-SSD.png
 
Zuletzt bearbeitet:
Hi,

kann man eigentlich davon ausgehen, dass die meisten prof. Raid-Controller ECC-Ram (Cache ...) haben? LSI, 3Ware usw. Ich finde da nichts zu.

Grüße

*zum Thema große Festplatten und alle 11TB ein Lesefehler oder so: Ich habe ein 48TB-Raid 6 System, das ich bisher 3x komplett auf ein anderes System gesichert habe. Es trat nie ein Fehler auf und alles wurde danach mit Multipar getestet. ECC-Ram habe ich auch nicht. Ich denke also, dass es genug interne Kontrollen gibt, die Fehler autom. reparieren können. Ein komplettes System mit ECC-RAM ist sicher die 1. Wahl, aber es werden hier auch extrem Ängste geschürt.
 
Zuletzt bearbeitet:
Bei einem RAID5 und erst recht einem RAID6 welche intakt ist, spielt die UBER keine Rolle, da bei einem Lesefehler einer Platte ja die Parität da ist und die Daten mit deren Hilfe und denen von den anderen Platten rekonstruiert werden können. Es müsste bei einem RAID einen Lesefehler auf dem gleichen Sektor bei zwei Platten auftreten, was extrem unwahrscheinlich ist und bei einem RAID 6 sogar auf 3 Platten, außer wenn die am verrecken sind, passiert das nun wirklich nie.

Daher ist ein RAID 6 ja auch viel sicherer als ein RAID 5, denn bei einem Rebuild ist ja eine HDD ausgefallen und damit fällt RAID 5 auf das Sicherheitsnivea eines RAID 0 zurück, also 0 Sicherheit und ein RAID 6 eben auf das eines RAID 5, man hat also nur bei einen Lesefehler auf 2 Platten auf dem gleichen Sektor hat man ein Problem, s.o.!
 
...
Tut er das? Und wer ist der Entwickler? Ich diese Aussagen von Matt Ahren, der ist einer der Mitentwickler des ZFS-Dateisystems:
"I would simply say: if you love your data, use ECC RAM. Additionally, use a filesystem that checksums your data, such as ZFS. "
Man beachte die Reihenfolge, zuerst empfiehlt er ECC RAM, wenn man seine Daten liebt und der Rest sagt nicht mehr als, ECC RAM ist eben keine Voraussetzung um ZFS betreiben zu können. ...

Wenn du schon Matt Ahrens zitierst, dann bitte komplett:

Ars walkthrough: Using the ZFS next-gen filesystem on Linux - Ars Technica OpenForum

cu
 
Außerdem lässt sich zumindest bei ZFS keine weitere Platte ins RAID integrieren, die werden nur wie bei JBOD/BIG angehängt und genießen dann aber nicht den gleichen Schutz wie die Platten im RAID.

..

So funktioniert ZFS nicht bzw. das wäre definitiv ein Fehler wenn man das so machen würde.

Ein ZFS Pool beginnt man mit einem vdev, z.B. ein Mirror oder Raid-Z2.
Von der Redundanz entspricht das einem Raid-6 mit den iops einer Platte

Erweitert wird das nicht um einzelne Platten sondern um weitere vdevs/Raid Arrays.
Es kommt also ein weiteres Z2 vdev dazu. Von der Redundanz entspricht das dann Raid 60 mit den iops wie die Summer zweier Platten.

Weitere vdevs erweitern den Pool. Man könnte das dann mit Raid-600, Raid-6000 usw vergleichen,
wenn es das da gäbe. Jedes vdev vergrößert die Kapazität und die iops entsprechend

Insgesamt erhält man für den Pool
Kapazität = n x Datenplatten
iops = n x vdev (Jedes Raid 5/6/Z hat nur die iops einer Platte)
 
Zuletzt bearbeitet:
Also kann man eben keine weiteren Platten so integrieren als wäre der Pool direkt mit der / den neuen Platten erstellt werden, was bei anderen RAID Lösungen ja normalerweise geht. Genau das habe ich gesagt und genau das hast Du bestätigt.
 
Ich denke die Frage muss man allgemein etwas differenzierter beantworten.

Das Hauptproblem ist doch dass man mit einem degraded Raid 5 nicht mehr sicher sein kann, dass alle Daten aus der Parität wieder vollständig hergestellt werden können.
Das liegt daran, dass es sein kann dass ein Lesefehler auftritt.


Wenn das der Fall dann ist denke ich die Frage von redmancall und auch meine:

Was passiert dann?

Array komplett futsch?
Nur die Datei(en) defekt die gerade in dem Bereich lagen?
oder was anderes?


Was mir da so spontan einfällt was Raid 5 mehr oder weniger implementiert:
- mdadm
- ZFS
- Storage Spaces
- Hardware Raid Controller
- Flexraid
- Dieses Synology Hybrid Raid
- snapraid


Die Frage ist was passiert in so einem Fall bei den jeweiligen Implementierungen und um dann auch wieder zurück auf die Ursprungsfrage zu kommen:

War das denn dann nicht schon immer ein Problem?
Wenn das Array kleiner ist bei Konstanter Festplatten Fehlerrate dann sinkt doch nur die Wahrscheinlichkeit dass beim Rebuild ein Fehler auftritt.
Array 10 mal kleiner ist "nur" eine 10 mal kleinere Chance für Fehler beim Rebuild?

Das bedeutet man hat schon vor 10-15 jahren mit Raid5 Lotto mit extrem guten Chancen auf einen Fehler beim Rebuild gespielt oder nicht?
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh