MoonTower schrieb:
Also falls hier jemand einen guten aktuellen Link zu diesem Thema hat, bitte her mit .) Müsste doch verschiedene Informatik-Abschluss-Arbeiten zu sowas geben.
Naja, da gibt es viele Philosophieansätze, sprich nur weil das irgendwo irgendjemand schreibt, wird das ja lange nicht richtig.
Das Thema dabei ist einfach, dass der UBER Wert letztlich nur ein statistisches Mittel ist. Und nicht wirklich klar definiert ist, zu was dieser Wert jetzt genau zählt und unter welchen Bedingungen.
Wie oben erwähnt, nehme ich eine Disk mit einer 2TB Platter und aus der selben Serie eine Disk mit 10x2TB Plattern, dann haben beide Vergleichspartner aus der gleichen Serie den gleichen UBER Wert im Datenblatt. Mathematisch gesehen kann ich logischerweise die Single Platter 2TB Disk 10x so oft vollständig lesen um auf den selben Read Count zu kommen wie die 20TB 10x2TB Platter Disk. Nur welchen Sinn hat diese Rechnung wirklich? Der Platter hält deswegen ja nicht 10x so lange. Und die Blöcke sind auch nicht 10x so robust gegen Lesefehler oder Degeneration oder sonstwas.
phanter schrieb:
Da erzählst du auch nichts neues. Wiegesagt ein robustes System ist eh dagegen abgesichert das eine Platte Blödsinn macht. Da ist es auch egal ob der UBER bei 10^15; 10^16 oder 10^18 liegt
Wobei das aber auch bisschen Einfach gesagt ist. Denn wenn alles was robust ist, gegen Fehler abgesichert ist, dürfte es ja keine Fehler mehr geben... Jeder definiert ja robust irgendwo anders. Auch ein ZFS Volume kann auseinander fliegen, als Beispiel.
Letztlich geht es doch um ein gewisses brauchbares Verhältnis zwischen Aufwand und Nutzen. Du kannst natürlich die Anzahl der Paritäten in einem Volume stark erhöhen um so die Wahrscheinlichkeiten eines Fehlers in der Form zu minimieren. Aber der Aufwand und die Kosten sind vor allem privat relativ hoch. Hier muss man dann eben abwägen zwischen Disk Anzah, Kosten, Verbrauch usw. Und nicht nur in Relation, sondern auch absolut, gerade bei den Preisen.
Eine Datendisk mit zwei Parity Drives zu paaren erzeugt Faktor 3 bei den Kosten. Hab ich 6 Daten Disks und paare das mit zwei Parity Disks, kommen lediglich 1/3 Mehrkosten drauf. Absolut bewegt man sich aber auf viel höherem Preisniveau. Je nach Diskgröße.
Yosup schrieb:
Durch Scruben mache ich einen ersten noch unentdeckten Fehler sicht- und behebbar und verringere so die Wahrscheinlichkeit massiv, dass er sich zeitlich mit einem zweiten (dann unbehebbaren) Fehler überlappt. Aber ausschliessen kann man das natürlich nach wie vor nicht.
Das setzt aber vorraus, dass der zweite Fehler nicht auch schon vorhanden ist. Denn das ganze steht und fällt mit der Anzahl der verfügbaren Infos. Im Falle eines Single Parity Verbunds bedeutet das, dass der Rest im Scrub-Fall trotzdem 100% funktionieren muss. Sonst kommst du nicht an die notwendigen Infos ran.
Meiner Ansicht nach spielt es nur bedingt eine Rolle ob ich jetzt geplant alle x-Tage so einen Job über das Volume drüber jage und mich dann drauf verlasse, dass die Parity Infos den Fehler fixen können, den der Job findet. Oder ob ich es drauf an kommen lasse bis eine Disk wegstirbt oder aus dem Verbund raus fliegt und ich dann ebenso alle Infos aus der gleichen Datenbasis zurück holen muss.
-> in beiden Fällen MUSS die Basis zu 100% funktionieren. Will man sich nicht drauf verlassen, braucht es A) ein Backup, also min. eine weitere Kopie und/oder B) eben eine weitere Partity Info im laufenden Verbund.
Mountainking02 schrieb:
Wem Datensicherheit wichtig ist sollte daher immer Raids verwenden mit mindestens drei Kopien verteilt auf ebensovielen Laufwerken. Z.B. Raid1 mit drei Laufwerken oder Raid10 entsprechend mit 6 Laufwerken. Ein Backup sollte aber zusätzlich existieren. Dann lässt man sich ausgeben welche Datei defekt ist und stellt sie wieder her.
Nicht unbedingt. Das Problem bei simplem Raid 1 oder 10 ist, dass du nicht weißt welcher der Blöcke im Fall von einem Bitflip der korrekte ist. Es benötigt daher viel eher ein System mit eben einer besseren Methode. Bspw. ein Raid Level mit Double Parity Infos. Und/oder ein Filesystem mit Checksummen und entsprechenden Parity Infos in doppelter Form.
Raid 1 ist egal wie viele Kopien man davon hat trotzdem relativ stark anfällig auf Fehler, weil es erstmal in der Basis keine Prüfung auf Korrektheit gibt. Selbst wenn du 10x das Bit kopierst auf verschiedene Platten. Ob die Kopie korrekt ist und welche der Blöcke die eigentlich richtigen Daten haben, ist schlicht nicht Thema des Raid 1.
Und ja, Backup ist immer gut... Aber auch da muss man sich eben Gedanken machen. Denn ob die Daten, die bei ner simplen 1:1 Kopie auf irgend einen anderen Datenträger korrekt sind, ist auch wieder eine Frage von einem ganz anderen Blatt.
ICH für meinen Teil bspw. nutze für simple File based Backups auf externe USB Drives ein kleinen Script, was zyklisch die Checksummen der Files errechnet. So lasse ich hin und wieder auf dem Quellsystem die Prüfung laufen, dass ich geplant zwei drei Werte pro Jahr pro File habe vom Live System und auf den beiden Backup Drives kann ich dann mit Gegenprüfung der dort liegenden Daten schaunen, ob die Kopie 100% korrekt ist. Denn was nutzt es mir zwar ne Kopie einer Datei zu haben, wenn ich nicht weis ob diese Kopie vollständig ist? Der PC, der die Kopie erstellt hat, könnte theoretisch nen Memory Fehler während des Kopie Jobs gehabt haben und einfach ein paar Bits kippen lassen haben...
