Muss ich mir sorgen um "bit-rot" machen?

[xXThunderbyteXx]

Hallo,

Ich nutze eine Synology DS220+ mit zwei 8TB HDDs im RAID 1 und BTRFS als primäres NAS.
Im Sale habe ich zwei weitere 8TB HDDs günstig gekauft.

Ich möchte nun ein zusätzliches kleines NAS, entweder als weiteren Speicher oder Offsite Backup anschaffen.
Bei der Recherche bin ich oft auf die Aussage gestoßen, dass nur BTRFS oder ZFS als Dateisystem geeignet ist, da ansonsten "Bit-rot" auftreten kann.

Generell findet man leider nur wenig zu dem Thema, hat davon jemand etwas mehr Ahnung?


Grüße

 

[underclocker2k4]

Das Thema wird hier im Forum schon seit Jahren behandelt, auch ausführlich. Es betrifft letztendlich auch schon einzelne Platten, die müssen nur groß genug sein. Diese Platten sind per Design quasi (Bit)Fehler behaftet...

 

[tolga9009]

Wie wahrscheinlich / unwahrscheinlich Silent (!) Bit-Rot im Heimbetrieb mit paar Dutzend HDDs ist, dazu kann ich nichts sagen, außer dass ich in den letzten 10 Jahren weder einen URE (trotz angeblich so hoher Wahrscheinlichkeit bei Consumer-Platten), noch einen Silent Bit Rot gesehen habe. Habe ca. 20 HDDs, BJ 2009 - 2018 mit einer Gesamtkapazität von ca. 40TB. Im Rechenzentrum mit 100.000+ Festplatten wird die Erfahrung anders sein. Ist bei Wahrscheinlichkeiten halt so.

Wenn du aber auf Nummer sicher gehen willst, muss auf irgendeiner Ebene Checksummen gemacht werden - das muss nicht unbedingt auf Dateisystemebene sein. Das kann auch z.B. vollautomatisch über ein Backup-Tool wie z.B. borg-backup auf einem normalen ext4 sein, oder so eine Lösung wie SnapRAID (Dateisystem unabhängig). Auto-Heal kann borg-backup meines Wissens nicht, SnapRAID könnte dies aber.

Also je nach Anwendungsgebiet / wie man's haben möchte gibt es i.d.R. ein Tool dafür.

Es kommt drauf an, wie wichtig einem die Daten sind, aber ich mache das so: Primärstorage muss Checksummen haben. Und ich will auch auf mind. einem Backup alles drin haben: Versionierung + Checksummen. Beim 2. Backup (also 3. Kopie) ist es mir dann egal. Da lasse ich i.d.R. Checksummen und Versionierung weg. Wenn ich auf das 3. Backup zurückgreifen muss (Hausbrand / Diebstahl), dann habe ich ganz andere Sorgen als Linux-ISOs mit gekippten Bits. Nehme ich als Risiko in Kauf.

 

[underclocker2k4]

Wie wahrscheinlich / unwahrscheinlich Silent (!) Bit-Rot im Heimbetrieb mit paar Dutzend HDDs ist, dazu kann ich nichts sagen, außer dass ich in den letzten 10 Jahren weder einen URE (trotz angeblich so hoher Wahrscheinlichkeit bei Consumer-Platten), noch einen Silent Bit Rot gesehen habe.

Woran machst du das nicht Gesehen haben fest?
Hast du für alle Files eine Checksumme und prüfst diese beim Öffnen auch Korrektheit?

 

[tolga9009]

Nein, mit Scrubbing. Auch beim traditionellen RAID gibt es Scrubbing - das kann dir zwar nicht sagen, welches die richtige / falsche Kopie ist (da keine Checksummen), kann dir aber schon sagen, ob es Mismatches gibt (also z.B. Silent Bit-Rots). Ich habe weder einen Mismatch beim traditionellen RAID, noch einen Fehler beim BTRFS Scrub gesehen.

 

[besterino]

Tjo, das kann man halt echt nicht sagen. Im Zweifel passiert halt nix oder es passiert und man merkt nix (weil das Bit in irgendeiner unwichtigen Datei an einer unwichtigen Stelle kippt). Doof isses halt, wenn's einen an einer wichtigen Stelle erwischt und man das ewig nicht merkt und das letzte Backup zu alt (z.B. Datei nicht drauf) oder zu jung (Datei schon mit Fehler gesichert) ist...

Ich hab auch seit bestimmt knapp 20 Jahren irgendwelche Server, aber noch keine Fehler "bemerkt" - wobei ich allerdings erst seit ca. 2016 mit ZFS unterwegs bin und es da zumindest irgendwie eine Meldung hätte geben können. (Aktuelle Uptime der VM immerhin 213 Tage. )

 

[Trambahner]

Ich hatte schon Files, die defekt wurden. Farbstreifen oder halb defekte Bilddateien, korrupte Zipdateien die sich nicht mehr entpacken ließen.
Ob es Ram-Defekte waren oder auf den HDDs defekt wurden weiß ich nicht mehr.

Seit 2013 mit ZFS und Storage-tauglicherer Hardware (statt Gaming/Desktop/OC-Setup) ist mir das nie wieder passiert.

 

[Ceiber3]

Komisch wie es klingt, hatte bis jetzt bei meinen Qnap ohne ECC und bei der Synology ohne ECC noch keine Defekte Datein gehabt, auch Video Datein i.o.
Bei meinen WIndows PC hatte ich früher sehr oft Bit Fehler, auch wie manche schon schreiben, Streifen im Video, Ton passt nicht mehr zu Video oder Bild ist komplett Schwarz oder ganz Defekt.

Erst wo ich Windows mit ECC Ram und SAS Raidcontroller + BBU hatte, hatte ich auch keine Fehler mehr. Jedenfalls keine die mir aufgefallen sind.

 

[gea]

Ohne Prüfsummen auf Daten und Metadaten bleiben Fehler unentdeckt, bis auf offensichtliche Sachen wie Bilder mit Streifen oder abstürzende Programme. Ansonsten ist es Statistik. Fehler treten mit einer bestimmten Wahrscheinlichkeit auf. Die ist nicht hoch und war bei einer 10GB Platte noch vernachlässigbar. Bei einer 10TB Platte aber nicht mehr, da ist die Wahrscheinlichkei bei gleicher Fehlerrate 1000x höher. Es macht auch einen Unterschied wie lange es her ist, dass man die Daten geschrieben hat. Je länger die Daten liegen, desto häufiger gibts Fehler.

 

[Trambahner]

Drum bei mir: alle Monat mal ein Scrub der Pools, damit auch die "coldstorage"-Dateien regelmässig geprüft werden.
Trotz ECC und Datacenter-Platten bzw. DC-SSDs. Sicher ist Sicher.

 

[tolga9009]

Ich halte nichts von dieser Panikmache. Die Fehlerrate von Consumer Festplatten wird mit *weniger* als 1 pro 10^-14 gelesenen Bits angegeben. Einige Leute machen aus *weniger als* ein gleich draus und kommen daher auf einen *garantierten* URE auf ~12TB.

Dass das extrem konservativ oder gar falsch ist, dürfte jedem klar sein, der paar TB sein Eigen nennt: ich scrubbe seit über 8 Jahren monatlich über 8TB, seit 2 Jahren über ca. 20TB. Laut Hersteller bzw. Schwarzmaler müsste ich also jeden Monat 1 - 2 singuläre UREs haben - habe ich aber nicht. Und noch nie gehabt.

Festplatten haben sich weiterentwickelt. Eine 10TB Festplatte ist nicht einfach eine 100GB Platte in größer. Moderne HDDs verwenden auch intern verschiedene Error Correction Mechanismen, um Fehler auszubügeln.

Viel häufiger als ein Silent Bit-Rot oder ein URE sind Probleme mit Hardware, Stromunterbrechungen, Software- / Firmwarebugs. Allein deshalb machen Checksummen oder zumindest eine Möglichkeit der Fehlerüberprüfung Sinn.

Auf dem Primärstorage hat OP bereits BTRFS, daher sehe ich beim Backup NAS nicht das Problem, wenn ZFS / BTRFS (aus welchen Gründen auch immer) dort nicht eingesetzt werden soll. Man muss dann auf irgendeine andere Weise die Möglichkeit haben, die Integrität des Backups überprüfen zu können - das geht auch mit mdadm Mirror- bzw. Parity-RAID oder eben Backup Tools (rsync mit Checksummen, borg-backup etc.).

 

[gea]

Bit-rot hat nicht nur was mit der Fehlerrate einer Platte beim Lesen zu tun sondern bedeutet zunächst dass mit einer bestimmten Wahrscheinlichkeit eine Anzahl von Bytes nicht (mehr) so sind wie ursprünglich geschrieben oder dem entsprechen was geschrieben werden sollte. Die absolute Anzahl betroffener Dateien hängt von der Plattengröße und der Lagerzeit ab. Die Problemquote ist nochmal deutlich geringer als die URE einer Platte - das aber nur wenn kein weiteres Problem dazu kommt das man ohne Prüfsummencheck nicht erkennt.

Das kann man entweder ignorieren ("Was ich nicht weiß macht mich nicht heiß") und hoffen dass es nichts wichtiges betrifft oder Korrekturmaßnahmen einsetzen. Die interne ECC Korrektur einer Festplatte kann helfen, das Raid kann helfen - aber halt nicht immer weil damit nicht alle Fehler erkannt werden können. Gerade deshalb wurden ja Echtzeit Prüfsummen auf Daten und Metadaten in den neuen Dateisystemen eingeführt weil nur damit alle Fehler sicher erkannt werden und mit Raid oder Mehrfachspeicherung (doppelte Metadaten, copies=2) automatisch repariert werden können oder man zumindest einen Checksum Fehler für die defekte Datei erhält. Die Alternative bedeutet ansonst dass bei bestimmten Fehlern korrupte Daten "problemfrei" gelesen werden.

Für "Archivspeicher" ist das Problem gravierend, bei normalem Speicher nicht alltäglich erkennbar. Ich habe ca ein Dutzend Filer hier mit ca 150 TB Kapazität. Ich kann mich in den 12 Jahren seit ich ZFS nutze nur an wenige "einzelne" Checksum Fehler erinnern, meist waren das dann plötzlich viele Fehler wenn eine Platte Probleme bekam oder es sonstige Probleme (RAM, PSU, Backplane, Kabel etc) auftraten. Da war ich dann immer froh das sofort zu bemerken. Aber wie heißt es ansonst so schön "Shit happens".

Ratgeber

Ratgeber und Tipps von den PC-WELT Experten, der zuverlässigen Quelle für technische Informationen, Ratgeber und Kaufberatungen für Verbraucher.

www.pcwelt.de

Die vernachlässigte Gefahr: Silent Data Corruption | IT-Administrator Magazin

www.it-administrator.de

http://indico.cern.ch/getFile.py/access?contribId=3&sessionId=0&resId=1&materialId=paper&confId=13797

 

[MisterY]

Ich habe schon Bilder dadurch verloren.

 

[craxity]

@gea Hast du das CERN-Paper gelesen? Das ist doch für normale Nutzer völlig unerheblich. Der IT-Administrator.de-Artikel ist auch pure Panikmache. Das hätte von einem schäbigen Versicherungsvertreter kommen können.

 

[gea]

Das Cern Papier ist von 2007. Ist aber immer noch einer der wenigen größeren Untersuchungen zu dem Thema. Zum anderen Artikel: Man kann das Problem bitrot ignorieren oder groß herausstellen wie hier. Es bleibt ein Problem. Man kann allenfalls diskutieren wie schwerwiegend das ist.

Für mich ist das klar. Ich bin vor ca 12 Jahren zu ZFS gewechselt nachdem mir mein Mailserver einen IO Fehler gemeldet hat und ein chkdsk (Windows NT) haben wollte. Der lief dann 2 Tage (> 1Mio Dateien) und ergab im Ergebnis eine Rührei Situation. Backup war da (Restore dauerte nochmal 3 Tage) aber sowas wollte ich nicht nochmal haben. Seitdem nutze ich ZFS und seither hatte ich keinen Datenverlust mehr (reparierte checksum errors aber schon mehrere).