Dateikorruption "bitrot"

[Trombonist]

Bietet dann nicht jedes weitere Kopieren von Dateien von einem Datenträger zum anderen (jetzt zB auf eine externe Festplatte, dann Umstellung des NAS auf btrfs und Rücksicherung) erneute Risiken von "umgekippten Bits"?

Ergänzung (17. April 2023)

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?

Nein, eben nicht. Einmal sollte es alle Daten sicher beherbergen, aber 99% sind dann statisch da drauf abgelegt. Mit einzelnen wird gearbeitet (Ersatz einer lokalen Datenspeicherung auf einem Rechner), es kommen auch immer neue hinzu (Texte, Tabellen, Fotos etc.), aber es werden selten bis garnicht ältere gelöscht. "Daten-Messi" ;-)

 

[tollertyp]

Habe meinen Beitrag noch editiert.
Also aus meiner Sicht sind mehrfache Backups zwingend.
Zumal das NAS auch abbrennen könnte.

Deshalb würde ich mich mit dem Thema "Wie stelle ich sicher, dass ich jederzeit genug Backups meiner wichtigen Daten habe" höher gewichten als die Gefahr von gekippten Datenbits.

Und das Kippen passiert ja nicht beim Schreiben, sondern es wird falsch gelesen. Insofern steigt das Risiko da nicht wirklich. Außer das Ziellaufwerk ist Schrott.

 

[kieleich]

Festplatten geben normal keine falschen Daten raus sondern melden dies als Lesefehler ... die ein RAID dann ausgleicht

Um Lesefehler fest stellen zu können hat jeder Sektor eine Prüfsumme stimmt diese nicht gehen die Daten nicht raus

Der Übertragungsweg ist auch auf diese Weise geschützt (UDMA CRC Prüfsummen)

Ohne RAID ist die Datei dann natürlich kaputt aber das sollte dann auch entsprechende Fehlermeldung geben

so gesehen gibt eigentlich kein Bitrot oder ist sehr sehr unwahrscheinlich. Dateisysteme hatten, jahrzehnte Lang keine Prüfsummen ohne das dies ein großes Problem war, da eben andere Schutz Mechanismen vorhanden

aber oft ist so das man Fehler ignoriert nicht mitbekommt wie auch immer

Und wenn die kopie ein mal schlecht ist gibts bei weiteren Kopien davon keine Fehler mehr

Oder es ist so das Software selbst falsche Daten schreibt aufgrund Fehlbedienung Bugs oder durch RAM Fehler

Regelmäßige Memtests sind Pflicht. Mehr noch so wenn man was an der System Konfiguration ändert

Da gibts viele Fälle wo auch btrfs nicht schützt denn wenn falsche Daten geschrieben werden dann ist es halt so. Dann hat eben btrfs auch die Prüfsumme zu den falschen Daten.

Es gibt da schlicht weg nicht die all umfassende Lösung für

Backups am besten mehrfach und inkrementell damit alte Kopien nicht gleich überschrieben werden

Und ansonsten eben auch eigene prüfsummen führen ( MD5SUM datei wie auch immer ) weil sonst bleibt dir nur maneull Daten Sichten und das ist bei der Daten Flut schon lange nicht mehr oder nur stich proben mäßig durchführbar

 

[Nilson]

Beim kopieren passiert so gut wie nichts, da die ganzen Protokolle noch mal mit Schutzmechanismen arbeiten (z.B. CRC, 8b/10b) um sicherzustellen, dass nichts schief geht.

 

[Trombonist]

Okay. Und würde der Sicherheitsmechanismus von btrfs auch bei einer einzelnen Festplatte greifen / anschlagen? Oder ist dazu zwingend RAID1 notwendig?

 

[Nilson]

Du würdest den Fehler erkennen, aber nicht (ohne externes Backup) beheben können

 

[tollertyp]

Also die zusätzlichen Prüfsummen sind da - die würden also durchaus zuschlagen. Die Rekonstruktion ist logischerweise nicht möglich.

@kieleich: Was du schreibst ist richtig, und kenne ich auch so. Gerade auch, dass sich HDDs wenn sie einen Sektor nicht lesen können es auch immer wieder probieren selbstständig, das basiert ja auch auf den HDD-eigenen Prüfsummen.

Doof gefragt: Warum gibt es dann noch weitere im Dateisystem eigentlich?

 

[Trombonist]

Du würdest den Fehler erkennen, aber nicht (ohne externes Backup) beheben können

Naja, externe Backups habe ich. Ich sichere ja 1x täglich ein NAS auf ein anderes, das genau zu diesem Zweck kurz startet und danach wieder herunterfährt. Dazu noch externe Festplatten.

Also würde es sich lohnen, die beiden Synologys auf btrfs umzustellen? Bin noch nicht so ganz überzeugt (und scheue eigentlich den Zeitaufwand, nochmal alles umher zu kopieren..)

 

[tollertyp]

Wenn du genug Backups hast, würde ich wohl drauf verzichten.
Ist ja nicht so, dass die Bits ständig willkürlich kippen und die Dateien schreddern. Sowas passiert wie gesagt bei defektem Arbeitsspeicher gerne mal.

Und grundsätzlich, wenn die Datei gelesen werden kann aber ein Bit gekippt sein sollte, heißt das noch nicht, dass die Datei zwingend "Defekt" ist.

 

[Nilson]

Wenn man es genau nimmt, sollte man dazu auch ECC RAM nehmen. Die Bits können ja auch im RAM kippen...

 

[Trombonist]

... und Synology hat on Board non-ECC-RAM verbaut und will auch non-ECC als Erweiterung haben

 

[kieleich]

Doof gefragt: Warum gibt es dann noch weitere im Dateisystem eigentlich?

weil man das in Software haben möchte statt sich auf irgend eine Hardware zu verlassen

da in der Hardware (RAM-HDD-Cache, Controller) auch Bit Fehler produzieren könnte

weil Dateisysteme, auch auf ungewöhnliche Weise kopiert werden ( Clone Zilla, dd ) und dabei auch Fehler auftreten können worauf weder Hardware noch Dateisystem direkte Kontrolle haben

das diese Prüfsumme im Dateisystem sinnvoll ist, keine Frage

sinnvoll ja aber unverzichtbar? es wird damit regel recht hausieren gegangen und FUD verbreitet man könnte ja ohne diese checksummen gar nicht auskommen

aber das ist dann ein anderes Thema

Daten Verluste, kommen auch mit dem angepriesenen, btrfs zfs, immer wieder vor und je mehr Komplexität (Verschlüsselung Komprimierung Deduplizhierung usw) desto schlechter kann man dann noch was retten

Es gibt nicht die eine Lösung für alles man braucht ein Backup Konzept am besten eins mit verschiedenen Medien und verschiedenen Dateisystemen

denn der Fall das das Dateisystem im Kernel ein Bug hat und sich selbst abschiesst, das kommt leider, auch dann und wann mal vor. Aktuell erzeugt der NTFS3 Treiber im Linux 6.2 Kernel, scheinbar Datensalat. tja Mist blöd sowas

 

[madmax2010]

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

😅. Da kann man das Argument aber auch für ext4 mit Blick auf inodes anwenden. Da läuft man gern ins gleiche Problem und irgendwie habe ich das auch schon deutlich öfter erlebt, als dass btrfs keine Metadaten mehr ablegen konnte

 

[Trombonist]

Lt meines Bekannten scheint Btrfs zwingend RAID zu benötigen, wenn der Reparaturmechanismus funktionieren soll. Also würde das bedeuten, wenn ich keine 2. Platte für RAID 1 einsetze, hätte ich keinen Vorteil von brtfs?

Dann Umzug auf Btrfs: würde folgendes funktionieren / Voraussetzung 2x NAS DS220+, je 1 HDD

NAS 2: Volume löschen, neues Volume erstellen mit btrfs, mit Migration Tool NAS1 auf NAS2 umziehen (dauert dann nur 3h), Konfiguration zurücksichern, fertig?

Synology war sich nicht sicher, vielleicht weiss es hier jemand: würde bei Einsatz des Migration Tools (das ja schon ein DSM und damit Dateisystem voraussetzt) dann das Zieldateisystem beigehalten werden? Also in dem Fall btrfs?