Bitrot, also die Vorstellung, dass ein einzelnes geflipptes Bit unentdeckt bleibt, ist wahrscheinlich ein Mythos, der auf einer Fehlinterpretation der üblichen HDD-Spezifikation von 1 unlesbaren Bit alle 1014 Bits (oder manchmal 1015) beruht. Diese Statistik bezieht sich auf Bits, die überhaupt nicht gelesen werden können. Vielleicht bedeutet es, dass man alle 400 PB einen unlesbaren 512-Byte-Sektor erhält. Vielleicht beziehen sich die Festplattenhersteller auch einfach auf den unlesbaren Standardsektor, der in SMART angezeigt wird. Die Vorstellung, dass ein einzelnes Bit umkippen und irgendwie durch alle Schichten der Hardware- und Software-Paritätsprüfung schlüpfen kann, ist ziemlich unplausibel, und ich habe noch nie empirische Daten oder einen einzigen dokumentierten Fall davon gesehen.

Aber es gibt noch andere Arten von Datenverfälschung, die auf verschiedenen Ebenen auftreten können. Aber warum über Theorien und Anekdoten reden? Wir sind doch Datenschützer, oder?

Ich habe 70 TB Daten (etwa 300.000 Dateien) genommen und zwei Kopien auf getrennten Festplatten gespeichert. Ein Satz ging in den kalten Speicher, der andere Satz wurde aktiv genutzt und zwischen verschiedenen Laufwerken und Dateisystemen hin- und hergeschoben/kopiert. Der Satz im Kältespeicher wurde einmal im Jahr hochgefahren, damit sich die Lagerflüssigkeit nicht absetzte. Der aktive Satz wurde in seiner Gesamtheit insgesamt vielleicht 5 Mal verschoben/kopiert (sagen wir 350 TB an Übertragungen). Der gesamte Arbeitsspeicher war nicht-ECC. Bei den Laufwerken handelte es sich um Consumer-Modelle, die aus einer Mischung aller Marken bestanden. Der aktive Satz verbrachte ein Jahr in ZFS unter FreeBSD (als ich mich besonders paranoid wegen Bitrot fühlte und die CRCs der Dateien haben wollte), den Rest der Zeit in NTFS unter Windows 7.

Nach 7 Jahren führte ich eine MD5-Prüfung beider Datensätze durch. Es gab 12 Dateien, die nicht übereinstimmten.

Datei 1 – Spieldaten-Datei, 2 KB. Identische Größe, deutlich unterschiedlicher Inhalt, und die aktive Kopie hatte ein neueres Datum. Sie sieht aus wie eine Spiel-Cache-Datei und wurde vom Spiel selbst verändert. Kein Schaden.

Datei 2 – Steam-Sicherungsdatei, 832 MB. Identische Größe, deutlich anderer Inhalt, und die aktive Kopie war 2 Stunden neuer. Sieht aus, als wäre es einfach ein neueres Backup, das ich erstellt habe. Kein Schaden.

Datei 3 – Video, 399 MB. Bei der Sicherungskopie wurden die ersten 64K durch Nullen ersetzt, und sie lässt sich nicht abspielen. Größe und Datum sind identisch.

Datei 4 – Video, 19 MB. Bei der Sicherungskopie wurden die ersten 64 KB durch einen Textabschnitt ersetzt, der sich in der Zwischenablage meines Notizblocks befand. Größe und Datum sind identisch.

Datei 5 – Video, 11,7 GB. Die Dateien unterscheiden sich um 232 Bytes beim Offset 9.693.699.010. Beide enthalten ununterscheidbare komprimierte Daten. Beide Videos werden abgespielt.

Datei 6 – Video, 2,9 GB. Die Dateien unterscheiden sich um 251 Bytes beim Offset 1.039.651.777. Beide enthalten ununterscheidbare komprimierte Daten. Beide Videos werden abgespielt. Identische Größe und Datum.

Datei 7 – Video, 9,4 GB. Die Dateien unterscheiden sich um 47 Bytes beim Offset 3.976.714.817. Beide enthalten ununterscheidbare komprimierte Daten. Beide Videos werden abgespielt. Identische Größe und Datum.

Datei 8 – Video, 4,6 GB. Die Dateien unterscheiden sich um 232 Bytes am Offset 627.313.318. Beide enthalten ununterscheidbare komprimierte Daten. Beide Videos werden abgespielt. Identische Größe und Datum.

Datei 9 – Video, 6,2 GB. Die Dateien unterscheiden sich um 104 Bytes beim Offset 1.496.829.600. Beide enthalten ununterscheidbare komprimierte Daten. Beide Videos werden abgespielt. Identische Größe und Datum.

Datei 10 – Video, 8,5 GB. Die Dateien unterscheiden sich um 512 Bytes beim Offset 6.517.833.728. Beide enthalten ununterscheidbare komprimierte Daten. Beide Videos werden abgespielt. Identische Größe und Datum.

Datei 11 – Video, 1 GB. Die aktive Kopie hat 54.784 beschädigte Bytes am Offset 684.589.056. Zu den beschädigten Daten gehören große Teile von Nullen, sich wiederholende Bytes und Textabschnitte wie „root_dataset“, „sync_bplist“, „vdev“ und „zpool create“, die anscheinend mit ZFS zusammenhängen. Identische Größe und Datum.

Datei 12 – Video, 817 MB. Die aktive Kopie hat 43.520 beschädigte Bytes am Offset 418.578.432. Die beschädigten Daten sind vom gleichen Typ wie in Datei 11. Identische Größe und identisches Datum.

Wir haben hier also 4 Arten von beschädigten Daten.

Die Dateien 1 und 2 sind nicht wirklich beschädigt, sie stimmen nur nicht überein, weil sie geändert wurden.

Die Dateien 3 und 4 hatten genau 65.536 Bytes, die am Anfang der Datei durch zufälliges Material aus dem Speicher ersetzt wurden. Ich habe keine Erklärung dafür, aber es muss beim Erstellen des Backups passiert sein, denn die aktive Version war noch in Ordnung. Es könnte auch daran liegen, dass ich SuperCopier verwendet habe, das wahrscheinlich nicht ganz fehlerfrei ist. Einmal habe ich gesehen, wie er eine Datei überschrieben hat, weil der lange Dateiname einer Datei in der Warteschlange mit dem 8.3-Dateinamen einer Datei am Zielort übereinstimmte, aber das ist ein ziemlich seltener Fall. Ich weiß es nicht mit Sicherheit.

Die Dateien 5-10 haben alle die gleiche Art von Beschädigung. Ein kleines Stück zusammenhängender Daten an einer zufälligen Stelle in der Datei wurde durch eine ähnlich aussehende Datenfolge ersetzt. Es ist zu klein, um es bei der Wiedergabe zu erkennen, also weiß ich nicht, welches die gute Kopie ist. Keine Ahnung, was das verursacht hat.

Die Dateien 11 und 12 haben eindeutig einen Schaden, weil sie unter ZFS gespeichert wurden. Ich habe jede Woche einen Scrub durchgeführt, und FreeBSD hat immer etwas „Falsches“ gefunden und es repariert. Es war mir nicht klar, was diese Fehler waren oder warum sie auftraten, aber ich hatte ein schlechtes Gefühl dabei. Ich bin in erster Linie wegen der CRCs von ZFS auf FreeBSD umgestiegen, aber nach einer Weile kam mir der Gedanke, dass, wenn NTFS überall korrupte Dateien hätte, die ganze Welt davon erfahren würde. Aber der Hauptgrund, warum ich zu Windows zurückkehrte, war, weil ich die FreeBSD-Oberfläche nicht mochte.

Ich bin auf eine fünfte Art von Korruption gestoßen. Die meisten der alten 1,5-TB-Festplatten von Seagate im Kältespeicher begannen, fehlerhafte Sektoren zu entwickeln. Dies wurde bei der jährlichen Überprüfung festgestellt, und die Festplatten wurden ausgetauscht, bevor Daten auf ihnen beschädigt wurden.

Ich führe immer noch einen MD5-Hash-Datensatz meiner Sicherungen, aber ich mache mir keine Sorgen mehr über Bitrot. Ich glaube nicht, dass es ein Phänomen gibt, das heimlich einzelne Bits hier und da umdreht. Wenn es echt wäre, hätte ich etwa 28 isolierte geflippte Bits zwischen den Datensätzen sehen müssen.

Als praktischen Rat empfehle ich, ein Offsite-Backup von allem und ein zusätzliches Backup von wichtigen Dingen wie Familienfotos anzulegen. Vergewissern Sie sich in regelmäßigen Abständen, dass Ihre Backups wiederhergestellt werden können. Ich empfehle auch die Erstellung von Dateilisten, damit Sie wissen, was bei einem Festplattenausfall wiederhergestellt werden muss, und von Datei-Hashes, damit Sie seltene Fälle von Dateibeschädigung erkennen können. Ich empfehle kein RAID für alles, was mit Backups zu tun hat.

Ich persönlich denke, dass die 3-2-1-Backup-Strategie ein wenig schwerfällig ist, um in allen Fällen verwendet zu werden – ich werde nicht drei Kopien eines alten Linux-ISOs behalten.