ZFS und silent data corruption

  • Ersteller Ersteller Gelöschtes Mitglied 73801
  • Erstellt am Erstellt am
G

Gelöschtes Mitglied 73801

Guest
Man sagt ja, bei ca. 10 hoch 16 Bits kann es dazu kommen. Wie genau kann ich dass verstehen?

Bei sehr großen Dateien wie z.B. HD-Filmen oder .iso Images?
Oder ist damit ein Kopieren grosser Datenmengen gemeint (z.B von einer Festplatte auf die andere in einem Rutsch)
Heisst das, wenn ich z.B. eine ISO brenne, dann sind möglicherweise im Falke des Falles irgendwelche Daten darauf defekt und ich merke es nicht? Keine Fehlermeldung? Sind dann z.B. in einem Spiel Fehler (Grafik/Ton/Steuerung etc.) ohne dass die Installation oder das Starten des Spiels mit einem Error gezeichnet werden?

Einzig ZFS und Btrfs helfen dagegen.

Sehe ich das jetzt richtig, dass ich meine ganzen Daten (z.B. iso Images, Urlaubsbilder/-Videos etc.) auf einem ZFS-Datenträger ablegen sollte, damit sie sicher sind? (es sei denn natürlich die Hardware ist am Ende)

VG
Lance
 
Daten auf Datenträgern können auch ohne dein Zutun kaputt gehen, ja. Das ist sogar sehr vielseitig. Beim schreiben kann es sein, dass die Festplatte was andere schreibt, als das OS das wollte... beim lesen kann es sein, dass die Festplatte was anderes liest was drauf ist, oder Umgebungsstrahlung, Felder oder sonstiges führt dazu, dass die Daten ohne Zutun von irgendwas sich ändern.

Die Auswirkungen sind verschieden. Bilder gehen kaputt, können nicht mehr geladen werden oder haben Bildfehler, Ton kratzt oder geht aus, Video kriegt kaputte Frames.

http://blog.barthe.ph/2014/06/10/hfs-plus-bit-rot/ Hier einer, dem das passiert ist.

Durch ZFS löst man dieses Problem, aber nur, wenn man die Daten redundant ablegt. Also irgend eine Form von RAID. ZFS auf einem Datenträger kann dir dann zwar sagen, dass die Datei kaputt ist, kann das Problem aber nicht beheben.

btrfs ist übrigens leider noch dafür bekannt Daten von sich aus zu schreddern. Sogar die Ultra-Pro-Linux Seite Phoronix hat in Tests mit btrfs festgestellt, dass man das noch nicht in Produktion einsetzen sollte.
 
Finde ich dann ja etwas fahrlässig dass SLES und andere Linuxe das verwenden.

Ich dachte der ZFS-Befehl "scrub" kann diese Fehler beheben, kann er nicht?

Wollte evtl auch RedHat mit XFS (gilt als ausgereiftestes Dateisystem) nehmen, aber du meinst also solange ich kein RAID habe, ist es quasi fast egal welches Dateisystem auf der Platte ist?*


Hintergrund:
Wir haben unsere Daten auf zwei USB-Platten (1 und 2 TB) gesichert und ich als Solaris-Nutzer überlege, zumindest eine davon mit ZFS zu formatieren weil ich mir so grösste Sicherheit verspreche.
Problem nur, kein anderes OS kann die Daten dann lesen, ich weiss nicht ob es prop. Lösungen gibt für Windows, Mac und Linux die mit dem Solaris ZFS (glaube v30 oder höher) umgehen können.

VG
Lance

*also erkennt ZFS die Fehler und kann sie im RAID beheben, andere Dateisysteme erkennen die Fehler dann nicht?
 
Ja ohne RAID ist es quasi egal welches Dateisystem. XFS hat auch nur Checksummen auf Meta-Daten, aber nicht auf die Daten selbst. D.h. es wird nur sichergestellt, dass die Position, Größe usw. der Daten im Dateisystem heil bleiben. Aber nicht die Daten selbst.

Das mit der Checksumme ist leicht erklärt. Nehmen wir einfach mal eine Datei im Dateisystem. Nennen wir sie Test.txt und füllen sie mit etwas:

$ echo "Das ist ein Test" > Test.txt

ZFS berechnet jetzt die Checksumme der Datei transparent mit und speichert diese. Das sieht dann ungefähr so aus:

$ openssl sha256 Test.txt
SHA256(Test.txt)= de7175738394fb8c2a8fe3317853d66e3b6739b35fceb04eea8597e4fcebaf35

Wenn sich jetzt die Daten ändern, ohne das ZFS davon weiß, dann ändert sich diese Checksumme. *man stelle sich jetzt eine unbemerkte Änderung vor*

openssl sha256 Test.txt
SHA256(Test.txt)= 806041a1c664002cbecb5aae3e83e8533636e785e5cfc5e695c4845cc680f949

Jetzt sieht ZFS: Uuups, da ging jetzt aber was schief.

Aber alleine aus der Information "vorher war die Checksumme de71... und jetzt ist sie 806... kann ZFS die Daten nicht wiederherstellen. Es _muss_ also noch einen Datenträger geben wo die Daten korrekt auslesbar sind. Darum RAID. Die Wahrscheinlichkeit, dass eine unbemerkte Änderungen an der gleichen Stelle an 2 Platten auftreten ist recht gering. Sie sinkt mit jeder weiteren Platte.

ZFS scrub macht nichts anderes als alle Daten ein mal zu lesen. Sollte ein Fehler beim Lesen geschehen greift das Auto-Healing. Der scrub Befehl an sich repariert keine Daten.

Für ZFS auf Linux und OS X gibt es entsprechende Projekte:

http://zfsonlinux.org/
https://openzfsonosx.org/

Ich kann über deren Qualität aber nichts sagen.
 
Wobei 10^16 Bits schon eine sehr hohe Angabe ist. Die meisten Festplatten haben lediglich eine Herstellerangabe von 10^14 und sie ist nur das letzte Glied in der Kette. Einmal davon abgesehen, dass man oft mehr als nur eine Festplatte hat. Davor sind die in meinen Augen etwas fehlkonstruierten S-ATA-Stecker mit der Backplane und / oder den Kabel, der Controller, das Mainboard, RAM und CPU... Die Frage ist nicht, ob Bits kippen werden. Sondern nur, was kaputt geht und was die daraus resultierenden Folgen sind. Daher ist es wichtig, Daten mehrfach zu sichern und einen Prozess zu implementieren, der verhindert, dass gekippte Bits aus dem Master in die Kopien sickern. ZFS ist da eine große Hilfe.
 
Ja und es ist dann auch wieder das typische Spiel mit Wahrscheinlichkeiten. Zum Beispiel gegen kaputten RAM kann dann auch ZFS nichts machen. Es gibt auch so viele Seiten im Netz, die die Sinnlosigkeit von ECC-RAM nachweisen wollen... muss jeder für sich selbst entscheiden.
 
Ok, aber ist dann quasi RAID unter NTFS sinnlos?

Kann ich auch mit meiner 1 TB Platte n (Software-) RAID mit 2x 500 GB machen mit ZFS?

Oder mit meinen beiden Platten? Also 2TB + 1 TB = 3 TB und diese dann in einen 1 TB RAID aufteilen. Aber dann muss ich beide Platten immer anschliessen, da ist dann so ne RAID Kiste für 150€ wohl besser. (Hab ich bei Saturn bzw MM gesehen)
 
Naja, RAID ist nie sinnlos. RAID soll ja in erster Linie dazu helfen, dass die Daten verfügbar sind auch wenn eine Platte aussteigt, ersetzt aber kein Backup. Und bei einem RAID müssen immer alle Platten des RAID im System sein. Bei 2 Platten bleibt dir nur ein Mirror, was bedeutet:

2TB+1TB = 1TB.

edit:
Und ach ja, du kannst auch RAIDs über Partitionen machen.
 
Es ist nicht unbedingt notwendig dass du nun anfängst Dateisysteme zu migrieren. Fakt ist dass du mehrere Kopien deiner wichtigen Daten besitzen solltest. Damit hast du die Möglichkeit zu vergleichen und im Bedarfsfall die originalen Daten aus der Kopie zurück zu holen.
Die Integrität der Daten kannst du nachrpüfen, indem du Werkzeuge wie aide,tripwire,sha256sum oder ähnliches benutzt

Wirf auch einen Blick auf das Feature 'Copies' https://www.freebsd.org/doc/handbook/zfs-term.html

When set to a value greater than 1, the copies property instructs ZFS to maintain multiple copies of each block in the File System or Volume. Setting this property on important datasets provides additional redundancy from which to recover a block that does not match its checksum. In pools without redundancy, the copies feature is the only form of redundancy. The copies feature can recover from a single bad sector or other forms of minor corruption, but it does not protect the pool from the loss of an entire disk.
Zum Vergrößern anklicken....
 
Ein weiterer wichtiger Unterschied zwischen ZFS und anderen Speicherlösungen mit Prüfsummen ist welche Prüfsummen verwendet werden und wie die Prüfsummen verwendet werden. Oft werden bloß sehr kurze CRCs mit 16 Bit oder bestenfalls 32 Bit verwendet. Diese Prüfsummen sind nicht geeignet die Integrität der Daten mit angemessener Wahrscheinlichkeit prüfen. Das schwerwiegendere Designproblem ist wie die Prüfsummen verwendet werden. Die meisten Systeme schreiben die Prüfsumme zusammen mit den Daten z.B. ein Block im Dateisystem enthält seine eigene Prüfsumme. Wird solch ein Block nun von der Festplatte an die falsche Stelle geschrieben steht dort ein gültiger Block. Die Prüfsumme schützt also nur einzelne Knoten, aber nicht die Kanten zwischen den Knoten. In ZFS enthalten die Elternknoten die Prüfsummen aller (bis zu drei) Kopien ihrer Kinder. Dadurch kann ZFS sich beim Scrubben von Schreibfehlern erholen, wenn genug Redundanz vorhanden ist um die Daten zu rekonstruieren.
 
USB3 dürfte inzwischen sicher weit verbreitet sein und es ist sehr viel besser (lese ich), als die Vorgänger.
Trotzdem würde ich dieser Verbindung nicht trauen, um darauf ein RAID zu etablieren. Also ein RAID über mehrere unabhängige USB-Platten. Externe Platten sind für mich immer nur gut, einmalig etwas darauf zu speichern und es dann gut irgendwo zu verstauen. Ständig am PC möchte ich die nicht haben und mich dann auf die Verfügbarkeit auch jederzeit verlassen müssen.
 
-Nuke- schrieb:
btrfs ist übrigens leider noch dafür bekannt Daten von sich aus zu schreddern. Sogar die Ultra-Pro-Linux Seite Phoronix hat in Tests mit btrfs festgestellt, dass man das noch nicht in Produktion einsetzen sollte.
Zum Vergrößern anklicken....

Das halte ich für üble Nachrede. Ich nutze selber kein BTRFS weil ich es schlicht für noch nicht fertig halte. Das BTRFS im Betrieb Datenfrisst stimmt nicht. Es gibt Spezialfälle in denen BTRFS Daten unwiederbringlich zerstört. Die sind aber gut dokumentiert und treten im Regelbetrieb ohne explizites zu tun des Nutzers nicht auf!
 
kmh schrieb:
Das halte ich für üble Nachrede. Ich nutze selber kein BTRFS weil ich es schlicht für noch nicht fertig halte. Das BTRFS im Betrieb Datenfrisst stimmt nicht. Es gibt Spezialfälle in denen BTRFS Daten unwiederbringlich zerstört. Die sind aber gut dokumentiert und treten im Regelbetrieb ohne explizites zu tun des Nutzers nicht auf!
Zum Vergrößern anklicken....

Und meine eigene Erfahrung ist, dass btrfs auch gerne einfach so, in normaler Benutzung kaputt geht. Da machst du deinen Rechner an und der Pool ist kaputt. Nicht unwiederbringlich meist, aber irgendwas ist kaputt gegangen. Und da können mir Checksummen und Co. egal sein, wenn ich jedes mal Angst haben muss, dass ich meinen PC starte und der Pool ist hin. Ähnliches Problem hatte Phoronix auch. Nur dort war der Pool ganz hin.

Klar bessert sich das von Zeit zu Zeit, aber selbst die btrfs-Entwickler schreiben noch keine Empfehlung dafür aus.

Außerdem reagiert btrfs, nach meiner Erfahrung, ganz ganz übel auf kaputte Festplatten. Während ZFS mir sagte: "Du deine Platte ist hin, tausche mal", stand bei btrfs gerne mal das System wiederkehrend minutenlang still.
 
-Nuke- schrieb:
Und meine eigene Erfahrung ist, dass btrfs auch gerne einfach so, in normaler Benutzung kaputt geht. Da machst du deinen Rechner an und der Pool ist kaputt. Nicht unwiederbringlich meist, aber irgendwas ist kaputt gegangen. Und da können mir Checksummen und Co. egal sein, wenn ich jedes mal Angst haben muss, dass ich meinen PC starte und der Pool ist hin. Ähnliches Problem hatte Phoronix auch. Nur dort war der Pool ganz hin.

Klar bessert sich das von Zeit zu Zeit, aber selbst die btrfs-Entwickler schreiben noch keine Empfehlung dafür aus.

Außerdem reagiert btrfs, nach meiner Erfahrung, ganz ganz übel auf kaputte Festplatten. Während ZFS mir sagte: "Du deine Platte ist hin, tausche mal", stand bei btrfs gerne mal das System wiederkehrend minutenlang still.
Zum Vergrößern anklicken....
Tja davon hat die ct in ihrem Artikel über Btrfs leider nichts geschrieben. :(

Schon mal Vielen Dank für die informativen Beiträge. Ich hatte zuvor einige Artikel über dieses Thema gelesen, wurde aber nicht 100%ig schlau was meine Fragen anging.
 
Illuminatus schrieb:
Es ist nicht unbedingt notwendig dass du nun anfängst Dateisysteme zu migrieren. Fakt ist dass du mehrere Kopien deiner wichtigen Daten besitzen solltest. Damit hast du die Möglichkeit zu vergleichen und im Bedarfsfall die originalen Daten aus der Kopie zurück zu holen.
Die Integrität der Daten kannst du nachrpüfen, indem du Werkzeuge wie aide,tripwire,sha256sum oder ähnliches benutzt
Zum Vergrößern anklicken....
Dann müsste ich aber die Bilder in iso Images packen, gleiches gilt für Videos. Da scheint mir ZFS doch einiges an Zusatzarbeit abzunehmen.
 
Darf ich dich darauf aufmerksam machen dass man den Inhalt von ISOs mounten kann? Szenario:
1.) Daten liegen auf der Festplatte, einfache Dateien in einfachen Verzeichnissen
2.) Daten werden als korrekt erachtet
3.) Prüfsummen über die Daten werden gebildet
4.) Liste der Prüfsummen wird sicher aufbewahrt
5.) Kopien der Daten kommen auf ISOs/Backup-Medien
6.) Bei Inventur können Inhalte der gemounteten ISOs/optische Datenträger gegen Prüfsummenliste verglichen werden
7.) Skripte nehmen dir Routineaufgaben ab...

Habe ich die Prüfsummen einer Datei, ist es vollkommen egal über welche Dateisysteme es diese Datei gibt. Ein Fehler ist auffindbar. Ob man den Fehler ausbessern kann hängt davon ab, ob man noch korrekte Kopien der Dateien hat.
Von mir aus kannst du auch ZFS-Snapshots auf DVD brennen. Aber wahrscheinlich habe ich dich einfach nur nicht richtig verstanden.
 
Ich möchte halt nicht alles als .iso Datei mit Prüfsumme.

Aber da ich gerade sehr angetan von FreeBSD bin, wird bald auch das letzte Linux-System dadurch ersetzt.
Bei ZFS gehe ich mal davon aus, dass ich zumindest gewarnt werde, wenn ein SDC vorliegt. Das würde mir ja schon reichen. Erstmal. Das ZFS-Raid kommt definitiv.
 
TCM schrieb:
Wo kommt denn der Unfug mit dem ISO her? Warum sollte man die Dateien in ein .iso stecken müssen?
Zum Vergrößern anklicken....
Weil ich das Netz nach Berichten zu dem Thema durchforstet hatte und immer nur von ZFS als sichere Lösung die Rede war. Ich stelle mir das auch ehrlich gesagt ziemlich langwierig und aufwädig vor, mit Tools etc. zu ALLEN Dateien auf meiner Festplatte Prüfsummen zu bilden. Da denke ich, dass ZFS da schon eine gute performante, zuverlässige Lösung ist.
 
http://www.tandbergdata.com/de/index.cfm/products/media/rdx-media/rdx-worm-media/
Der Begriff ISO wird jedenfalls nicht hilfreich sein eine Lösung für deine Anforderung zu finden. Natürlich kannst du ALLE deine Daten auf deinen Festplatten auf ZFS migrieren. In gewisser Weise können dir aber Dateiintegritäts- oder Backuptools auch Gewissheit verschaffen ob deine Daten unverändert sind. Es muss aber eine verlässliche Referenz her, welche dir sagen kann was die Korrektheit einer Datei ausmacht.

Nehmen wir an:
- Foto gemacht
- Foto-Datei auf PCs daheim kopiert (alle mit ZFS)
- Datei existiert nur noch auf zwei PCs, alle anderen Kopien unwiederbringlich weg
- an einem der PCs hat in deiner Abwesenheit jemand ein Pixel im Bild mit gimp verfärbt.... oder während der Übertragung damals gab es einen Bitflip...
- auch diese abweichende Kopie wird mit dem Schutz der ZFS Checksummen der Datenblöcke abgespeichert.
- Woran erkennst du jetzt welche der letzten beiden Kopien das unverfälschte Original ist?

Ich würde mir Gedanken über eine ordentliche Archivierung machen, wie ich die von mir als korrekt definierten Daten im Zugriff behalte. Nicht welches Dateisystem einzig und allein daheim verwendet werden darf.
Würdest du mit kritischen Daten hantieren (Finanzen, Gesundheit, Whatever), käme für dich wohl nur eine IBM z-Serie in Frage. Stell dir vor dass alle Komponenten redundant ausgelegt sind, auch RAM und CPU. Es müssten quasi zwei Bitflips im gleichen Moment an den richtigen Stellen aufschlagen damit der Fehler nicht bemerkt wird. Und das ist hochgradig unwahrscheinlich.

Die Benutzung von ZFS löst nicht automatisch Probleme. Quantenteleportation überträgt auch nur die Daten, welche du hineinkippst.
 
Illuminatus schrieb:
Würdest du mit kritischen Daten hantieren (Finanzen, Gesundheit, Whatever), käme für dich wohl nur eine IBM z-Serie in Frage.
Zum Vergrößern anklicken....

Selbst dort bist du nicht zu 100% vor Fehlern gefeit. Bei einem Kunden habe ich 6 Wochen lang täglich Datenkorruption in einer Vorproduktionsumgebung miterlebt, weil IBM einen Bug in der Firmware des Storage-Controllers hatte, der auf allen Strängen parallel die fehlerhaft geschriebenen Daten als korrekt geschrieben zurückgemeldet hat.

Die beiden (im wahrsten Sinne des Wortes) abgebrannten Mainframes (aufgrund eines Serienfehlers in einem Crypto-Addon-Board) waren auch nicht lustig.

Wenn man dann noch die monatlichen Wartungsgebühren sieht, die man aufgrund der Höhe leicht für den Anschaffungspreis der kompletten Maschine halten kann, überlegt man sich den Einsatz der zSeries abseits geschäftskritischer Legacy-Software zweimal.
 
Man kann immer Fälle bauen wo irgendwas auch mit ZFS zu Datenverlusten führt. Gerade manuelle Einwirkungen... wie soll ZFS da was erkennen? Und wenn etwas unveränderlich sein soll, dann kommt es an die entsprechende Stelle und kriegt die Schreibrechte entzogen ;) Die "Working-Copy" ist nicht nur bei Software-Entwicklung sinnvoll.

Archive und Datensicherungen über die Zeit anlegen wird mit steigender Datenmenge auch immer teurer... oder wie sichere ich günstig >11TB mit mehr als einer Version? Eben... da kann man froh sein, wenn man überhaupt 1 Backup hat.
 
Kommt auf deine Definition von günstig an. Da dieser Thread ZFS Bezug hat wären die passenden Möglichkeiten innerhalb eines Pools erstmal manuelle Snapshots und Clones als der eine Ansatz oder Onlinededup als einfachere Alternative. Letzteres würde zwar ca. 64GB (ECC) RAM brauchen, aber wen schockt das heute noch?
 
Naja, günstig wäre: Es übersteigt nicht die Anschaffungskosten des hauptsächlichen Datenspeichers. Also mal als Bespiel, diese Seagate Archive Platten mit 8 TB für 220 EUR. Da hat man dann ~8TB gesichert, für höheren Bitflip Schutz 2 davon für ein Mirror und dann ist man bei 440 EUR. Und nun müsste ich aber 11TB sichern... also theoretisch, denn das Problem bei den Archive Platten ist, dass sie im RAID nicht funktionieren xD

Auf einige Daten könnte ich auch verzichen bzw. sie wiederherstellen (BluRays neu auslesen, etc.), aber ich denke man versteht was ich meine. Snapshots sind zwar ein Backup der Daten vor Änderung, klar, aber halt kein Verlust-Backup. Falls das Teil mal abbrennt oder was weiß ich. :D

Ist schon eine effektive Möglichkeit Geld loszuwerden.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben