Bitrot: Hohe Datenintegrität+Verschlüsselung unter Windows? (ZFS, BTRFS, RAID, Scrubbing, Veracrypt, NAS, NFS)

[Banned]

Ich sehe das Problem ist komplex da man nicht weis wo Bitfehler passieren. Datenkabel, RAM, etc...

Ja, es ist in der Tat komplex, wobei das Datenkabel nicht dazu führen sollte, da Laufwerke den Transfer eigentlich über CRC absichern und bei nicht erfolgreichem Transfer erneut probiert wird. Die Laufwerke sollten dann idR bei den Smart-Werten beim Attribut "UltraDMA CRC" einen hohen Rohrwert aufweisen, wenn es Probleme mit dem Kabel gibt. Ist das nicht der Fall, ist das eher nicht die Ursache. Hier allerdings der Hinweis, da es sich um USB-Platten handelt: Ich weiß nicht, wie es zwischen USB Controller und SATA aussieht. Hier kann man keinen Log einsehen vom Controller, weshalb es theoretisch möglich wäre, schätze ich.

Hier mein Ratschlag: Verwende eine Software (z.B. ein Backup-Programm), die den Transfer überprüft, also einen Abgleich zwischen Ziel und Quelle vornimmt.

- Zum RAM:
Hier sollte auf jeden Fall (z.B. mit Memtest) der RAM auf Defekt geprüft werden. Nichts ist so übel wie ein defekter RAM, der nach und nach lange Zeit unbemerkt Daten korrumpiert.
Wenn man bei RAM von Bitflips spricht, dann meint man damit Bits, die im RAM oder zwischen RAM und CPU kippen. ECC sichert sowohl im RAM als auch auf dem Weg von und zu diesem gegen 1-Bit-Fehler ab und kann Multi-Bit-Fehler bis zu einer gewissen Anzahl erkennen (on-die-ECC wie bei Standard DDR5 nur im RAM selbst).
Das Problem hier ist generell, dass Fehler, die nicht korrigiert werden konnten, eben als fehlerhafte Daten auf dem Datenträger landen und dann helfen da die Prüfmechanismen für den Datenträger logischerweise auch nicht mehr. Allerdings sind 1-Bit-Fehler schon sehr selten und Multi-Bit-Fehler extrem selten. Ein 1-Bit-Fehler wird dir z.B. normalerweise keine Videodatei oder MP3 verhunzen; bei einer Bilddatei ist es schon deutlich wahrscheinlicher, aber immer noch kein riesiges Risiko (es ist eben deutlich wahrscheinlicher, dass einfach ein Pixel nicht mehr stimmt, als dass an der ganzen Struktur was beschädigt wird). Trotzdem will man sowas natürlich vermeiden.

Die Speicherfähigkeit/Magnetisierung meiner HDDs prüfe ich regelmäßig mit CHKDSK/R
Und CHKDSK/F was das Dateisystem NTFS auf Fehler überprüft.

Das ist doch eigentlich schon mal ein guter Ansatz.

Was heißt in gewissem Maß ?
Wenn eine HDD Daten wiederherstellen kann bräuchte ich mir keine Sorgen zu machen über externe Einflüsse auf bereits geschriebene Daten ! Dan wäre dieses Thema ja bereits auf unterster Ebene gelöst.

Du kannst gerne nachschauen, bis zu wie vielen fehlerhaften Bits der ECC korrigieren kann (ich weiß es gerade nicht aus dem Kopf ). Er hat eben wie jeder ECC bzw. jeder Fehlerkorrekturmechanismus seine Grenzen. Im schlimmsten Fall ist es sogar möglich, dass so viele Bits kippen, dass es nicht mal mehr vom Prüfverfahren erkannt wird (das ist z.B. bei CRC32 natürlich wahrscheinlicher als bei SHA256 - sollte einleuchten).

Je länger ein Datenträger nicht geprüft wird, desto wahrscheinlicher ist es, dass sich Bitfehler mit der Zeit kumulieren und dann eben zu Fehlerbildern führen, die nicht mehr korrigiert und im schlimmsten Fall nicht mal mehr erkannt werden können (die Prüfsumme kann natürlich ebenfalls korrumpiert werden und damit auch zu einem zu unrecht als fehlerhaft erkannten Block führen).

Ergänzung (24. November 2024)

Wie ich mir dachte, externe Platten. Ich wette, es sind die Kabel.

Müsste dann wahrscheinlich ein Problem mit dem Controller des Gehäuses sein, denn ansonsten wird ja über SATA eigentlich geprüft (UltraDMA CRC). Ich würde auch eher davon ausgehen, dass es bei ihm nicht an Bitrot liegt, denn wenn er die Daten regelmäßig mit chkdsk /r prüft, da müsste er schon sehr Pech haben, dass mehrere Dateien korrumpiert sind, sofern das Laufwerk keinen Defekt aufweist.

 

[mchawk777]

Nur um mal die Gegenposition darzustellen: Deconstructing SpinRite
Das Programm stammt aus einer Zeit als es noch MFM/RLL-Platten mit direkt ansteuerbaren Controller gab (80er bis frühe 90er). Damals mag es seinen Sinn gehabt haben, heute nicht mehr. Ich bekomme bei dem Programm jedenfalls heftige SoftRAM 95 Vibes.

Danke für den Link - werde ich demnächst mal durchlesen.
Selbst Dave relativiert gerade bei SSDs den Nutzen solcher Tools.

Den Vergleich mit SoftRAM95 ist aber deutlich übertrieben.
Streng genommen spricht bei lange lagernden HDDs nichts dagegen nach ein paar Jahren mal den Magnetismus aufzufrischen. Z. B. mit DiskFresh.

Ich persönlich halte allerdings regelmäßige SMART-S2-Tests für praktikabler.
Zumal ich während des Tests die HDD weiter nutzen kann.
"Richtig" defekte Sektoren sind m. E. ein häufigeres auftretendes Problem denn schwächelnder Magnetismus.

 

[Evil E-Lex]

Streng genommen spricht bei lange lagernden HDDs nichts dagegen nach ein paar Jahren mal den Magnetismus aufzufrischen. Z. B. mit DiskFresh.

Strenggenommen sind HDDs nicht dazu gedacht, Daten lange zu lagern. Wenn man Daten archivieren möchte, nimmt man Bänder.

Ergänzung (25. November 2024)

Den Vergleich mit SoftRAM95 ist aber deutlich übertrieben.

Findest du? Gibson macht auf seiner Website derartig abwegige Aussagen, dass man ihn schlicht nicht ernst nehmen kann. Allein was er zu SSDs schreibt ist derart grotesker Unsinn, dass es schon an Realsatire grenzt.

Mich irritiert viel mehr, dass Plummer auf diesen Unsinn reinfällt und ihn weiterverbreitet.

 

[Hardkorn]

Um meine wichtigen Dateien (eigentlich nur Dokumente und ein paar Bilder) zu schützen, nutze ich neben der 3-2-1-Backup-Strategie noch MultiPar (nur für Windows) um Bitrot und mehr zu erkennen und korrigieren. Ist aber auch umständlich wenn man kein Script zum automatisieren oder dergleichen schreibt.

https://en.wikipedia.org/wiki/Parchive

 

[gea]

Nunja, ich nutze seit vielen Jahren ZFS unter diversen Platformen und habe mit napp-it meine eigene Web-GUI für BSD, Illumos, Linux oder Windows (da mit Storage Spaces und ZFS) dafür entwickelt und kann sagen, dass es die ultimative Lösung ist, wenn es um Bitrot und Datenintegrität geht. Sun hat damit ein Dateisystem geschaffen das dem Anspruch gerecht wird, Datenverluste außer bei defekter Hardware, Softwarebugs oder human errors zu vermeiden. Durch die Echtzeit Prüfsummen auf Daten und Metadaten (doppelt vorhanden) und Copy on Write ist es nahezu unkaputtbar. Ein Crash beim Schreiben das jede ältere Dateisystem schrotten kann ist unkritisch.

Verschlüssellung
Auch native ZFS Verschlüssellung sehe ich nicht als problematisch da die eigentlichen Daten verschlüsselt sinnd. Die Struktur wird nicht verschlüsselt, damit kann ZFS auch verschlüsselte Dateisysteme prüfen und reparieren. Allein das macht den Unterschied zu anderen Lösungen bei denen immer die Gefahr besteht, dass das verschlüsselte Volume bei einem Datenfehler verloren ist. Auch bietet ZFS Verschlüssellung raw send. Man kann also ein Backup erstellen ohne das Dateisystem vorher zu entschlüsseln. Auch kann jedes ZFS Dateisystem seinen eigenen Schlüssel haben.

ZFS will not encrypt metadata related to the pool structure, including dataset and snapshot names, dataset hierarchy, properties, file size, file holes, and deduplication tables (though the deduplicated data itself is encrypted).

https://arstechnica.com/gadgets/2021/06/a-quick-start-guide-to-openzfs-native-encryption/

Ich halte ZFS Verschlüssellung unter Linux für stabil und problemloser als andere Lösungen, auch wenn ich native ZFS unter Solaris oder OpenZFS unter dem Solaris Fork Illumos als stabiler erachte als ZFS unter einem der vielen Linuxe, jede mit einem anderen ZFS Release

Unter Windows wird OpenZFS langsam eine richtig gute Option die ntfs/ReFS weit hinter sich läßt was Features angeht. Der aktuelle openzfs.sys Treiber für OpenZFS 2.2.6 rc10 ist noch beta aber durchaus einsetzbar. Ein Backup wichtiger Daten sollte man eh immer haben, da bietet sich ein Backup auf ntfs an. Ein ZFS Bug kann dann das Backup nicht beeinflussen. Diese Empfehlung gebe ich auch bei Linux z.B. Backuppool ohne aktivierte Features
https://github.com/openzfsonwindows/openzfs/releases

Man sollte immer einen Blick auf den jeweiligen Issue Tracker haben (auch bei Linux) z.B.
https://github.com/openzfsonwindows/openzfs/issues
https://github.com/openzfsonwindows/openzfs/discussions

Da sieht man schnell wo es noch hakt und was gut geht.

 

[recu]

Hallo gea,

wer den Einsatz von ZFS bedenkt, der stößt unweigerlich auf das Thema RAM:
ECC-RAM, ja oder nein?
Wieviel Speicher sollte es denn sein?

Auch wenn ZFS Deiner Ansicht nach unkaputtbar ist, interessiert mich immer, ob ein Dateisystem (ZFS ist natürlich viel mehr!) auch von Datenrettungsprogrammen unterstützt wird. Das trifft für das von mir genannte BCACHEFS nicht zu - zumindest kenne ich keine Datenrettungssoftware für diese Struktur.

 

[gea]

Der Grundansatz von ZFS geht dahin, Datei oder Dateisystemfehler bis zu dem Punkt "per design" zu vermeiden ab dem keine volle Reparatur mehr möglich ist z.B.

Wenn ntfs beim Schreiben abstürzt, so kann es atomare writes nicht garantieren. Das sind die kleinsten io die immer vollständig sein müssen, z.B. Datenblock schreiben und Metadaten aktualisieren (oder korruptes Dateisystem) oder ein Raid Stripe nacheinander auf alle Platten schreiben (oder korruptes Raid). Dateisysteme wie ntfs können viele Fehler nur offline reparieren (beim booten). Bei ZFS wird wegen CopyonWrite bei Datenänderungen kein Datenblock geändert sondern immer neu geschrieben. Das gibt nicht nur die Option den vorherigen Stand als Snap zu versionieren sondern erlaubt online check und repair (ZFS scrubbing). Dateisysteme wie ntfs können mangels Prüfsummen eh nur strukturelle Fehler erahnen und reparieren, keine echten Datenfehler wie bei ZFS wo jeder Datenblock eine Prüfsumme hat.

Raid-5 ist ein weiteres Problem. Fällt da eine Platte aus (Array degraded) so führt ein bad block auf dem Restarray meist zu einem Array Lost. Bei einem ähnlichen ZFS Z1 wird bei den gleichen Problem nur ein Datenblock auf einer Platte als defekt erkannt, mit dem Ergebnis dass das Z1 lesbar bleibt, nur die betroffene Datei ist defekt.

Bitrot ist ein statistisches Problem bei dem sich Daten auf Platte zufällig verändern. Nur ein Teil kann von platteninternen ECC korrigiert werden. Um die zu erkennen benötigt man Prüfsummen auf Daten und Metadaten wie bei btrfs, ReFS oder ZFS. Mit ZFS Redundanz werden diese Fehler beim Lesen on the Fly repariert ohne dass man ein fschk/chksdsk bräuchte.

ZFS im normalen Betrieb vermeidet soweit technisch möglich, die Probleme für die man chkdsk/fschk benötigt. Was bleibt ist allenfalls zu versuchen bei einem korrupten Pool noch einzelne Dateien zu retten, z.B.
https://www.klennet.com/zfs-recovery/default.aspx

wer den Einsatz von ZFS bedenkt, der stößt unweigerlich auf das Thema RAM:
ECC-RAM, ja oder nein?

ECC ist keine Vorraussetzung. Ohne ECC kann es aber passieren dass durch einen Ramfehler ein veränderter Datenblock mit korrekter Prüfsumme auf Platte landet (Datei korrupt), ist nicht anders als bei anderen Dateisystemen. Mit ECC ließe sich das vermeiden. Das Risiko besteht, ist aber klein. ZFS ist ohne ECC immer noch sicherer als z.B. ntfs mit ECC.

Wieviel Speicher sollte es denn sein?

ZFS läuft auf 64bit Betriebssystemen, da sollte man 2GB für rechnen. Für die ZFS interne RAM Verwaltung würde ich bei Solaris/Illumos (Solaris Fork) etwa 2 GB zugeben, bei OpenZFS unter BSD, Linux, OSX oder Windows eher 4GB. Für ein ZFS System sollte man daher 4-8 GB RAM haben. Mehr macht es schneller da der RAM als Schreib/Lesecache genutzt wird. Copy on Write und Prüfsummen erzeugen mehr io. Das macht ZFS auf mechanischen Platten langsamer, da hilft RAM als Cache. Eine feste Relation Poolgröße <-> RAM besteht nicht.

Weteren RAM Bedarf hat ZFS nur für eine Web-GUI (TrueNAS möchte gerne ab 16GB, mein napp-it cs hat nahezu keinen Extra RAM Bedarf) oder für Echtzeit Dedup (1-5GB/TB Dedup Daten). Mit dem neuen ZFS Fast Dedup verringert sich der Extra RAM Bedarf drastisch.