Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
ich möchte demnächst mir ein neues NAS anschaffen und dabei aber die Data Degradation im Auge behalten. Ich archiviere viele alte Familienfotos und Videos. Welches NAS hat eingebaute Funktionen um Data Degradation zu verhindern und wie funktioniert das genau? Wie kann ich bitflips bei der Übertragung auf das neue NAS vermeiden oder ist das ohnehin Standard?
Je nachdem, wie wichtig die Daten sind, sollte man meiner Meinung nach bei so Projekten allerdings grundsätzlich auf ECC-Speicher setzen., also auch bei Btrfs Technisch geht es auch ohne (sogar bei ZFS), zu empfehlen wäre es aber eher nicht.
Stormregion0 schrieb:
[...] die Data Degregation im Auge behalten. [...] um Data Degregation zu verhindern [...]
Nur mit ECC RAM und natürlich muss der Rest der HW, also Board und CPU dies auch unterstützen, sonst hängen die zusätzlichen Bits der Riegel ja nur in der Luft. Ohne ECC RAM kann man gekippte Bits niemals verhindert, da die Daten ja immer übers RAM laufen, noch bevor das Filesystem sie zu sehen bekommt, eine Fehlerkorrektur im Filesystem kann diese Fehler daher weder erkennen noch verhindern. Außerdem ist eine automatische Fehlerkorrektur zumindest bei ZFS ohne ECC RAM sogar gefährlich und kann den ganzen Pool vernichten, denn ZFS unterstellt immer das die Daten im RAM korrekt sind und Fehler immer von den Platten kommen, korrigiert dann bei RAM Fehler ggf. die eigentlich korrekten Daten kaputt.
Dabei ist es extrem unwahrscheinlich das HDDs fehlerhafte Daten liefern, die haben eine ECC hinter jedem Sektor und liefern dann einen Lesefehler, wenn sie die Daten nicht korrekt lesen und anhand der ECC auch nicht korrigieren können. Auch die Übertragung über SATA mit einer CRC32 pro FIS (welches maximal 8192 Byte an Nutzdaten enthalten kann) abgesichert und die Übertagung wird im Zweifel wiederholt, wenn es dabei zu einem Fehler gekommen ist. Die Wahrscheinlichkeit das eine CRC32 über 8192 Byte Fehler nicht erkennt ist so gering, da müsste man sämtliche jemals gefertigten HDDs zigfach lesen bis dies einmal passiert, da kann also auch nicht passieren. Was bleibt sind Fehler in der FW oder auf den internen Datenpfaden der Platte oder des Host Controllers, solche FW Fehler gab es immer wieder mal, der letzte mir bekannte Fall bei HDD fiel 2011 auf und bei guten Platten und Controllern haben die Puffer auch eine ECC und internen Datenpfade einen Schutz vor Bitfehlern, erkennbar am Attribut für Ende-zu-Ende Fehler.
Fast noch wichtiger als die Sorgen die Daten auf dem NAS vor Korruption zu schützen ist sie erstmal vor dem Totalverlust zu schützen, also ordentliche Backups davon anzulegen, z.B. auf USB Platten, in der Cloud oder auf einem zweiten NAS. Die Wahrscheinlichkeit sie komplett zu verlieren, würde ich als höher einstufen als die Wahrscheinlichkeit das sie durch Datenkorruption unbrauchbar werden.
Aber es sollte klar sein, dass man keine absolute Sicherheit bekommt, sondern nur mehr oder weniger große Wahrscheinlichkeiten und wer eben eine besseren Schutz möchte, dem kann nur nur empfehlen zu lesen was Matt Ahren, Mitentwickler des ZFS-Dateisystems, schreibt:
Man beachte die Reihenfolge, zuerst empfiehlt er ECC RAM und dann erst oben drauf ein Filesystem mit Prüfsummen wie ZFS zu verwenden, wenn man seine Daten liebt und vor Korruption schützen möchte!
Dabei ist es extrem unwahrscheinlich das HDDs fehlerhafte Daten liefern, die haben eine ECC hinter jedem Sektor und liefern dann einen Lesefehler, wenn sie die Daten nicht korrekt lesen und anhand der ECC auch nicht korrigieren können.
Wie kann man dafür sorgen, dass die Daten mit sehr hoher Wahrscheinlichkeit korrigiert werden können?
Holt schrieb:
Fast noch wichtiger als die Sorgen die Daten auf dem NAS vor Korruption zu schützen ist sie erstmal vor dem Totalverlust zu schützen, also ordentliche Backups davon anzulegen, z.B. auf USB Platten, in der Cloud oder auf einem zweiten NAS. Die Wahrscheinlichkeit sie komplett zu verlieren, würde ich als höher einstufen als die Wahrscheinlichkeit das sie durch Datenkorruption unbrauchbar werden.
Da stimme ich dir zu, mache ich auch. Da ich aber im Kopfe habe, alte Bilder und Daten evtl. sogar irgendwann meinen Enkeln weiterzugeben, halte ich bei der Menge an Daten (die sich auch noch ansammeln wird) Datenkorruption für real gefährlich (vorallem da ich immer wieder im laufe der Zeit die Daten auf neue Medien kopieren muss weil die alten HDDs natürlich auch nicht ewig leben).
Wobei es jetzt auch nicht so ist ,das das ständig duzende Bits umkippen.
Wichtige Daten hat man eh mindestens drei mal. Wenn auf A ein Bit kippt und B kaputt ist, hat man immer noch C.
Wobei es jetzt auch nicht so ist ,das das ständig duzende Bits umkippen.
Wichtige Daten hat man eh mindestens drei mal. Wenn auf A ein Bit kippt und B kaputt ist, hat man immer noch C.
Prinzipiell ja, aber sagen wir ich merke nicht das Datei A kaputt ist und kopiere sie auf B und C? Logistisch und kostentechnisch habe ich keinen vollautomatischen Backups sondern mache dies immer gelegentlich.
Da kannst Du nichts machen, die ECC auf der Platte wird vom HDD Hersteller bestimmt und ist von außen nicht zu beeinflussen. Du kannst da allenfalls durch die Auswahl der Platten Einfluss nehmen indem Du Modelle mit einer besseren Uncorrectable Bit Error Rate (UBER) kauft. 3.5" gibt es mit 1:10^14 (was z.B. von WD bei der Red Pro leider auch gerne als 10:10^15 angegeben wird, aber auch nur 1:10^14 ist) und 1:10^15. Letzteres haben oft nur Enterprise HDDs, bei Seagate aber auch die IronWolf ab der 6TB und alle IronWolf Pro, weshalb diese auch meine Favoriten sind.
Stormregion0 schrieb:
halte ich bei der Menge an Daten (die sich auch noch ansammeln wird) Datenkorruption für real gefährlich
Dann sorge dafür das alle Rechner und auch das NAS über die die Daten gehen, mit ECC RAM (und entsprechender Unterstützung dafür) ausgestattet sind, denn beim Kopieren gehen die Daten immer übers RAM, Windows und eigentlich jedes moderne OS nutzen das sonst unbelegte RAM auch als Diskcache, die Daten können dort also u.U. länger stehen als so mancher vermutet und beim Kopieren puffern die meisten Programme, auch der Explorer von Windows, die Daten ebenfalls großzügig im Cache, wenn die Quelle sie schneller liefern kann als das Ziel sie wegschreibt, aber auch sonst geht immer alles übers RAM. Die Fehlerkorrektur per Filesystem (wie bei ZFS und btrfs) ist dann das i Tüpfelchen oben drauf, wie Matt Ahren ja auch ganz deutlich sagt und ZFS wurde klar für Enterpriseumgebungen entwickelt wo ECC RAM einfach Standard und nicht wegzudenken ist, da werden mit Advanced ECC Technologien dann sogar Multibit RAM Fehler noch korrigiert.
Ohne ECC RAM sind solche Filesystem aber sogar gefährlich, weil sie eben auf die Korrektheit der Daten im RAM vertrauen und bei RAM Fehlern Daten die korrekt auf der Platte stehen kaputtkorrigieren können und obendrein des User in eine falsche Sicherheit wiegen, denn wenn die Daten vor dem Schreiben wegen eines RAM Fehlers korrupt geworden sind, so kann man dies nicht mit dem Filesystem erkennen oder gar verhindern, denkt aber meist auch gar nicht an diese Gefahr oder zieht es gar nicht in Betracht, da die Überprüfung ja regelmäßig ausgibt alle Dateien wären korrekt. Das sind sie auf der Platte auch, müssen dann aber noch längst nicht der Datei entsprechen die man dorthin kopiert hat.
Dann sollte man bei den Programmen aufpassen, die gehen auch unterschiedlich damit um wenn sie auf Fehler treffen. Bei WinRAR wird z.B. per Default beim Entpacken von Archiven die Datei gelöscht, bei der ein Fehler aufgetreten ist, während 7z sie stehen lässt, obwohl sie korrupt ist und nicht mit der Datei entspricht, die einst in das Archiv gepackt wurde. Das hat den Vorteil das man mit dem Rest vielleicht noch was anfangen kann, aber wenn man die Fehlermeldung ignoriert oder gar nicht sieht, dann fällt einem wahrscheinlich gar nicht auf das die entpackte Datei korrupt ist und nicht wenige Anwender werden die Ursache dann leider an der falschen Stelle vermuten. Es ist eben nicht so das HDD ständig korrupte Daten liefern würden, dies ist wie schon geschrieben nur bei Fehlern in der FW oder auf den internen Datenpfaden (sofern die HDD und der Host Controller dafür keinen Schutz haben) der Fall, aber beides sind wirklich seltene Ausnahmen.
Ergänzung ()
Stormregion0 schrieb:
aber sagen wir ich merke nicht das Datei A kaputt ist und kopiere sie auf B und C?
Das bist Du genau bei den Problemen die ich eben beschrieben habe. Wenn Dein Rechner oder Dein NAS kein ECC RAM haben, kann dies jederzeit passieren und kein Filesystem kann Dich davor schützen. Erstelle besser selbst eine Datei mit einer Prüfsumme wie z.B. MD5 oder SHA1 und kopiere diese immer zusammen mit der Originaldatei, dann kannst Du nach jedem Kopiervorgang wirklich prüfen ob die Datei noch dem Zustand entspricht als diese Prüfsumme angelegt wurde, so mache ich es z.B. immer. Wenn dann ein RAM Fehler beim Erstellen oder Prüfen der Prüfsumme auftritt, so stimmt die Prüfsumme hinterher nicht, es kann aber praktisch nie passieren, dass die Datei korrupt ist, die Prüfsumme trotzdem aber stimmt, außer man kopiert z.B. vom PC auf das NAS, im NAS wird sie durch einen RAM Fehler korrupt, aber beim Prüfen kommen die Daten in Wahrheit nicht vom NAS sondern aus dem RAM des PC weil sie noch in dem RAM steht welches das OS als Diskcache nutzt. Da muss man also auch aufpassen, aber wen man sehr viele Daten hat, dann werden die kaum im RAM stehen können und sonst macht man die Überprüfung entweder auf dem NAS (über eine shell dort) oder einen Reboot des Rechners. Besser ist es solche Fehlerquellen eben durch die durchgehende Verwendung von ECC RAM gleich zu vermeiden, allerdings sind Fertig-NAS mit ECC RAM sehr teuer, weshalb ich auch einen Heimserver mit einem Xeon-D als NAS verwende.
Wie Du siehst gibt es viele Fallstricke und einfach nur ein Filesystem mit Fehlererkennung/-korrektur zu verwenden, ist bei weitem nicht ausreichend um diese alle einigermaßen sicher zu umgehen, denn absolute Sicherheit gibt es eben nicht, nur unterschiedliche hohe Sicherheitsstufen und die letzten Prozente an Sicherheit kosten wie immer am Meisten. Was meist Du wohl raum Banken und Versicherungen immer noch Mainframes verwenden, obwohl dies sauteuer sind und es sehr schwer und teuer ist Personal dafür zu finden? Eben weil diese extrem überwacht sind und immer noch die größtmögliche Sicherheit vor Datenfehlern liefern, da wird jedes Bit wirklich scharf überwacht damit es nicht unbemerkt kippen kann, denn bei den Finanztransaktionen die diese ausführen, kann es sonst sehr teuer bis ruinös enden. Das ist nicht wie bei der KfZ Werkstatt wo der Kunden dann für einen Ölwechsel eine Rechnung über viele Millionen bekommt, weil ausgerechnet in der Speicherzelle wo die Endsumme steht ein Bit gekippt ist, man sich entschuldigt und noch einmal die korrekte Rechnung zusendet.
