Dateikorruption "bitrot"

[Trombonist]

Hallo.

In einem anderen Thread über RAID1 etc. ist die Rede von "schleichender Dateikorruption".

Wie häufig kommt sowas vor?

Wie kann man dem zuvorkommen oder es erkennen?

Schützt zB BTRFS grundsätzlich davor? Ist ext4 dafür anfälliger? Auch im Vergleich zu NTFS oder FAT?

Kann man sowas bei manuellem Synchronisieren schon feststellen, wenn die Software (zB AllwaySync) auch die Dateigröße mit vergleicht?

Meine DS220+ hatte ich extra nicht btrfs verwenden lassen, sondern ext4. Wäre es evtl sinnvoll, doch auf btrfs zu wechseln?

 

[tollertyp]

Software kann so etwas nur erkennen, wenn sie Hashwerte der Dat(ei)en ermittelt und vergleicht. Die Dateigröße ist da kein Indikator.

Dateisysteme (bzw. die Dateisystemtreiber) wie Btrfs oder auch ReFS unter Windows machen diese Hash-Berechnung eben automatisch.

 

[blackshuck]

Meine DS220+ hatte ich extra nicht btrfs verwenden lassen, sondern ext4.

Warum??

 

[0x8100]

alle dateisysteme ohne checksummen sind anfällig für bitrot. zfs und btrfs liefern einen fehler, wenn die checksumme nicht stimmt. haben die beiden zusätzliche daten im sinne einer parität (z.b. raidz) oder zusätzlichen kopien (z.b. raid1), dann können die daten automatisch repariert werden. das gilt nicht wenn das raid mit mdadm gemacht wird, es muss schon die im dateisystem integrierte funktionalität sein. k.a. was deine ds220+ da benutzt.

 

[Nilson]

Schützt zB BTRFS grundsätzlich davor? Ist ext4 dafür anfälliger? Auch im Vergleich zu NTFS oder FAT?

Generell ist jedes Bit dafür "anfällig" und daher vom Dateisystem unabhäning. Es gibt aber Dateisysteme wie btrf oder ZFS die Mechanismen haben das zu erkennen und, je nach Konfiguration, auch beheben können.

Kann man sowas bei manuellem Synchronisieren schon feststellen, wenn die Software (zB AllwaySync) auch die Dateigröße mit vergleicht?

Da solche Störungen einzelne Bits betreffen, ändert sich die Dateigröße nicht. Abweichungen erkennt man, in dem man die Datei Bitweise miteinander vergleicht (z.B. über Prüfsummen). Gute Backupprogramme und einige Synchonisier programme können das.

 

[Donald24]

Dieses Verhalten kann auf allen Festplatten passieren, die ihre Daten magnetisch auf rotierende Medien schreiben. Die physikalischen Gründe dafür sind vielfältig. Aber eben kann ein Dateisystem davor eben nicht schützen und auch kein Raid1-5, bei Raid6 besteht im Falle dessen noch eine mathematische Wahrscheinlichkeit, dass wegen doppelter Redundanz, die Daten korrigiert werden können.
Was aber immer ein guter Tipp ist, ist alle Sektoren gelegentlich mit einem Volumecheck abzufahren. Denn allein bei Lesevorgang werden dabei jegliche Daten 'frisch' magnetisiert, denn eben lange unmagnetisierte Bereiche sind die Ursache.

 

[Trombonist]

Warum??

Ich hatte vor der Einrichtung einen Linux-Entwickler gefragt, was er empfiehlt. Er meinte, btrfs würde sich im Laufe der Zeit "zumüllen", ext4 sei das bessere Dateisystem...

 

[0x8100]

Aber eben kann ein Dateisystem davor eben nicht schützen

natürlich, dafür gibt es die checksummen in btrfs und zfs.

 

[tollertyp]

Besser für was? Was bedeutet zumüllen? Was ist ein Linux-Entwickler und was macht ihn für Dateisystemfragen kompetent? :-)

Das ist in etwa wie "Er ist Arzt, also kennt er sich in medizinischen Fragen aus". Dass es da unterschiedliche Fachgebiete gibt, who cares...

 

[Garmor]

Er meinte, btrfs würde sich im Laufe der Zeit "zumüllen", ext4 sei das bessere Dateisystem...

Und da hatten wir dir doch gesagt, dass das Quark ist. Btrfs müllt sich nicht zu, außer man versteht das Konzept von Copy on Write nicht.

 

[tollertyp]

natürlich, dafür gibt es die checksummen in btrfs und zfs.

Nicht alle Checksummen erlauben eine Rekonstruktion. Ist das bei Btrfs und ZFS gegeben? Oder verlangt ZFS dafür vielleicht nicht noch zusätzliche Datenträger, um eine Rekonstruktion durchzuführen?

CDs bzw optische Speichermedien, wenn für Daten genutzt, haben z.B. einen Teil für die Fehlerkorrektur hinterlegt. Sind auch explizit CRCs.

 

[0x8100]

Was bedeutet zumüllen?

wahrscheinlich diese problematik -> https://superuser.com/questions/1290086/btrfs-no-diskspace-left

 

[Trombonist]

Und da hatten wir dir doch gesagt, dass das Quark ist. Btrfs müllt sich nicht zu, außer man versteht das Konzept von Copy on Write nicht.

Das weiß ich. Ich war auch skeptisch, weil Synology ja selbst sagt, dass sie eine Art "angepasstes" btrfs einsetzen. Und ext4 wäre ein "Standard"-Dateisystem.

Ergänzung (17. April 2023)

Meine Frage ist ja, wie häufig so ein bitrot auftritt.

Ich habe vor Kurzem meine allerersten PCs noch einmal angeschmissen, um sie zu verkaufen (teils 30 Jahre alt! Festplatten von 120 und 240 MB). Da waren alle Daten vorhanden. OK, ich habe nur einige wenige geöffnet, aber da habe ich keine Probleme festgestellt.

 

[Nilson]

OK, ich habe nur einige wenige geöffnet, aber da habe ich keine Probleme festgestellt.

Das ist halt das Problem. Wenn nur ein Bit wo kippt, betrifft das nur eine Datei (wenn überhaupt, kann ja auch eine leere Stelle auf der Platte sein). Und wenn die Datei eine Textdatei ist, ist ggf. nur ein Buchstabe anders.

 

[iWaver]

Bei RAID1 macht btrfs definitiv mehr Sinn als ext4.
2 Festplatten -> doppelt so hohe Chance für gekipptes Bit
Bei ext4 kannst du im Nachhinein nicht sagen, welches Bit nun richtig ist.
Bei btrfs dank zusätzlichem Hash mittels scrub aber schon.

 

[Trombonist]

Besser für was? Was bedeutet zumüllen? Was ist ein Linux-Entwickler und was macht ihn für Dateisystemfragen kompetent? :-)

Das ist in etwa wie "Er ist Arzt, also kennt er sich in medizinischen Fragen aus". Dass es da unterschiedliche Fachgebiete gibt, who cares...

Naja, er arbeitet in einem Hochschulrechenzentrum, bewegt also sehr viele Daten und entwickelt an einem Linux-Derivat mit. Unterstelle mal, dass er weiß, wovon er redet.

 

[0x8100]

Nicht alle Checksummen erlauben eine Rekonstruktion. Ist das bei Btrfs und ZFS gegeben?

soweit ich weiss braucht man zusätzliche daten aus dem raid. bei dateisystemen auf einzelnen datenträgern gibt es nur detektion, keine reparatur.

 

[tollertyp]

Okay, danke.
Ist nur wichtig, dass Leute auch verstehen, wann diese Prüfsummen auch einen Schutz bieten können.

 

[Trombonist]

Bei RAID1 macht btrfs definitiv mehr Sinn als ext4.
2 Festplatten -> doppelt so hohe Chance für gekipptes Bit
Bei ext4 kannst du im Nachhinein nicht sagen, welches Bit nun richtig ist.
Bei btrfs dank zusätzlichem Hash mittels scrub aber schon.

Also setzt diese Selbstheilungsmöglichkeit in btrfs voraus, dass ich RAID1 nutze, also die HDDs spiegele im selben NAS?

Und es dürfte doch sowieso sehr schwierig sein, wenn man keine garantiert bitrot-freie Kopie von Daten hat, sowas zu erkennen.

Habe mich bisher trotz regelmäßiger Backups nie darum gekümmert und setze mich jetzt erst mit dem Thema auseinander.

 

[tollertyp]

Naja, er arbeitet in einem Hochschulrechenzentrum, bewegt also sehr viele Daten und entwickelt an einem Linux-Derivat mit. Unterstelle mal, dass er weiß, wovon er redet.

Danke für die Aufklärung, das sagt einfach mehr aus als "Linux-Entwickler".
Und auf einem NAS "bewegst du auch viele Daten"? Oder sind bei dir vielleicht ganz andere Anforderungen gegeben?

Und naja, du kannst dich schon mit dem Thema beschäftigen, aber ehrlich gesagt würde mir das Thema keine schlaflosen Nächte bereiten. Also das Thema kann ja grundsätzlich immer auftreten, statistisch kommt das aber eigentlich nicht wirklich häufig vor. Selbst bei HDDs die ich über ein Jahr lang nicht in Betrieb hatte, scheinen ja noch überwiegend in Ordnung zu sein... ja, klar, es wird dann auch nicht immer festgestellt, dass so ein Fehler auftrat, aber oft genug sind die auch nicht "relevant".

Wirklich wichtige Daten müssen eh mehrfach gesichert sein usw...