Stille Datenkorruption: Warum ext4 schweigt und was Btrfs und ZFS auf dem NAS dagegen tun

Die Antwort vorweg: Ext4 berechnet standardmäßig keine Prüfsummen für den Inhalt von Datenblöcken. Liefert der Speicher lesbare, aber falsche Daten zurück, hat ext4 nichts, womit es sie vergleichen könnte — die Datei lässt sich öffnen, kopieren und sichern, nur stehen darin nicht mehr die ursprünglichen Daten. Btrfs und ZFS berechnen Prüfsummen für Daten und decken Schäden beim Scrub auf; reparieren können sie den Schaden aber nur, wenn eine zweite intakte Kopie existiert — also bei einem redundanten Verbund. Auch sie ersetzen kein separates Backup.

Ext4 ist kein schlechtes Dateisystem. Es ist schnell, ausgereift und stellt sich nach einem Stromausfall zuverlässig wieder her. Für ein Firmen-NAS hat es jedoch eine ganz bestimmte Schwäche, die erst auffällt, wenn es zu spät ist: Es kann nicht erkennen, dass sich der Inhalt einer Datei verändert hat. Dieser Text erklärt, wie ein stiller Fehler entsteht, warum ext4 ihn nicht sieht und was das konkret für Kauf und Konfiguration eines NAS bedeutet.

Was bedeutet stille Datenkorruption

Zwischen der Magnetoberfläche der Plattern und der Anwendung, die eine Datei öffnet, liegt eine ganze Reihe von Zwischengliedern: die Firmware der Festplatte, ihr Cache, die SATA- oder SAS-Verkabelung, der NAS-Controller, die RAID-Schicht, der RAM und schließlich das Dateisystem. Der Fehler kann an jeder Stelle dieser Kette entstehen.

Ein Teil der Störungen ist laut und sichtbar. Die Festplatte meldet einen nicht lesbaren Sektor, fällt aus dem Verbund, im SMART-Status tauchen Reallocated- oder Pending-Sektoren auf. Damit lässt sich arbeiten — das System weiß, dass etwas fehlgeschlagen ist.

Schlimmer ist die Situation, in der die gesamte Kette einen fehlerhaften Block für vollkommen gültig hält. Nirgendwo leuchtet eine Warnleuchte auf. In der Praxis sieht das so aus:

• ein ZIP- oder 7z-Archiv meldet einen CRC-Fehler, und ein Teil der Dateien lässt sich nicht entpacken,
• ein Foto hat mittendrin einen verschobenen Farbstreifen,
• ein älteres PDF öffnet sich mit einer Meldung über eine beschädigte Struktur,
• die virtuelle Festplatte einer VM startet nicht mehr,
• eine Datenbank stellt beim Lesen einer Seite einen Fehler in ihrer eigenen Prüfsumme fest,
• ein Backup-Programm ohne Verifikation überschreibt eine bisher gute Kopie mit der beschädigten Version.

Der letzte Punkt ist der heimtückischste. Die Backup-Rotation arbeitet in diesem Moment aktiv gegen Sie — der stille Fehler wird ebenso brav gesichert wie die korrekten Daten, und nach ein paar Zyklen gibt es nichts mehr, worauf man zurückgreifen könnte.

Für dieses Phänomen wird häufig der Begriff „Bit Rot” verwendet, er ist aber irreführend. Er suggeriert eine allmähliche Alterung des Mediums, während die Ursache genauso oft fehlerhafter RAM, ein Firmware-Fehler, ein Stromversorgungsproblem oder ein fehlerhafter Schreibvorgang ist, der schon Monate zurückliegt. Umfangreiche Messungen an Produktivsystemen haben dieses Phänomen schon lange beschrieben — am häufigsten zitiert werden die CERN-Studie und die Arbeit von NetApp/University of Wisconsin über Statistiken aus Millionen von Festplatten. Die konkreten Zahlen unterscheiden sich jedoch je nach Hardware-Typ und lassen sich nicht auf ein kleines Firmen-NAS als „Wahrscheinlichkeit, Daten zu verlieren” übertragen.

Entscheidend ist etwas anderes: SMART reagiert auf diese Art von Fehler nicht. SMART beschreibt den Zustand des Geräts und Ereignisse, die die Festplatte selbst erfasst hat — nicht die Korrektheit des Inhalts Ihres Vertrags. Wie man SMART liest und was sich daraus wirklich ablesen lässt, erklären wir im Artikel Woran man erkennt, dass eine HDD stirbt.

Warum das ext4-Journal nicht ausreicht

Das ext4-Journal löst eine völlig andere Aufgabe, als man sich davon verspricht. Es sorgt dafür, dass nach einem unterbrochenen Schreibvorgang keine halb durchgeführten Änderungen an Metadaten zurückbleiben — dass in einem Verzeichnis kein Eintrag für eine Datei hängen bleibt, deren Blöcke nie jemand zugewiesen hat. Das ist Strukturkonsistenz, nicht inhaltliche Korrektheit.

Modernes ext4 beherrscht Prüfsummen für Metadaten und Journal (Funktion metadata_csum, bei heutigen Distributionen standardmäßig per mkfs aktiviert). Das bedeutet, dass das System einen beschädigten Inode oder einen defekten Verzeichnisblock erkennt. Es bedeutet aber keine Ende-zu-Ende-Prüfsumme für Nutzdaten — die führt ext4 nicht. Liefert der Speicher für einen bestimmten Block einen anderen, aber weiterhin lesbaren Inhalt zurück, hat ext4 keine Referenz, gegen die es ihn prüfen könnte. Es hat also keine Möglichkeit festzustellen, dass etwas nicht stimmt, und schweigt.

Auch fsck schließt diese Lücke nicht. Es prüft die Struktur: Verzeichnisse, Belegungs-Bitmaps, Inodes, Link-Zähler. Es interessiert nicht, ob in der Datei der Betrag 120.000 Kč stehen sollte oder ob sich darin ein einzelnes Bit gedreht hat.

Außerdem lässt es sich nicht einfach so ausführen. Die Prüfung erfordert ein ausgehängtes Volume:

umount /dev/ihr_volume
e2fsck -f /dev/ihr_volume

Das bedeutet Ausfallzeit und erfordert, das richtige Gerät zu treffen. Auf einem NAS mit Linux-RAID, LVM oder einer proprietären Herstellerschicht sollten Sie diesen Befehl nicht ohne Kenntnis der konkreten Architektur ausführen — die Geräteschichtung sieht dort anders aus, als es die Weboberfläche zeigt.

Was Btrfs und ZFS zusätzlich leisten

Btrfs speichert Prüfsummen für Daten und Metadaten in separaten Bäumen, getrennt von den Blöcken, die sie beschreiben. ZFS legt die Prüfsumme jedes Blocks in seinem übergeordneten Zeiger ab, sodass beim Lesen die gesamte Kette vom Wurzelknoten des Baums bis zu den Daten überprüft wird. Die Implementierung unterscheidet sich im Detail, die Konsequenz ist dieselbe: Stimmt die berechnete Summe nicht mit dem gespeicherten Wert überein, weiß das System, dass es dem gelesenen Block nicht vertrauen kann, und meldet einen Fehler, anstatt ihn an die Anwendung weiterzugeben.

Hier müssen zwei Dinge getrennt werden, die in Marketingunterlagen gerne verschwimmen. Die Erkennung funktioniert auch auf einer einzelnen Festplatte. Die Reparatur nicht. Das System braucht eine Quelle für die korrekte Kopie — einen zweiten Spiegel, ein anderes Mitglied des Verbunds, die Parität in RAIDZ. Auf einem Single-Disk-Volume benennt Ihnen Btrfs die beschädigte Datei exakt und verweigert deren Auslieferung, kann den ursprünglichen Inhalt aber nicht aus dem Nichts erzeugen. Das ist trotzdem besser als ext4, das Ihnen die Datei beschädigt ausliefert und dabei so tut, als sei alles in Ordnung.

Eigenschaft	ext4	Btrfs	ZFS
Prüfsummen für Metadaten	Ja (metadata_csum)	Ja	Ja
Prüfsummen für Dateiinhalte	Standardmäßig nein	Ja	Ja
Online-Scrub der Daten im laufenden Betrieb	Nicht in diesem Umfang	Ja	Ja
Selbstreparatur der Daten aus redundanter Kopie	Nicht auf FS-Ebene	Ja, bei vorhandener Redundanz	Ja, bei vorhandener Redundanz
Integrierte Snapshots	Nein	Ja	Ja
Wo Sie es in fertigen NAS finden	QNAP QTS und andere	Synology DSM, Linux	QuTS hero, TrueNAS

Scrub: die Prüfung, die wirklich laufen muss

Prüfsummen allein überwachen nichts. Geprüft wird nur der Block, den jemand liest. Eine Datei, auf die drei Jahre lang niemand zugegriffen hat, kann beschädigt sein, ohne dass das System davon weiß — bis sie jemand vollständig liest. Genau das macht der Scrub: Er durchläuft die gespeicherten Daten, berechnet die Summen neu und vergleicht sie. Findet er eine Abweichung und existiert eine korrekte redundante Kopie, überschreibt er den fehlerhaften Block mit dem richtigen Inhalt und protokolliert das.

Unter Linux mit Btrfs:

btrfs scrub start -Bd /data
btrfs scrub status /data
btrfs device stats /data

Bei ZFS:

zpool status -v tank
zpool scrub tank
zpool status tank

/data und tank sind nur Beispiele — prüfen Sie bei einem Produktivsystem zuerst den tatsächlichen Mountpoint und den Namen des Pools. Im Synology DSM findet sich dasselbe im Storage Manager unter Data Scrubbing und lässt sich planen.

Als Ausgangspunkt ist ein monatlicher Scrub sinnvoll. Der konkrete Zeitplan hängt aber von Kapazität, Festplattengeschwindigkeit und Betriebslast ab. Rechnen Sie damit, dass er bei einem gefüllten Verbund Stunden bis Tage läuft und dabei die ganze Zeit alle Festplatten mit durchgehendem Lesen belastet.

Und eine nachdrückliche Warnung: Starten Sie keinen Scrub, solange sich der Verbund im Modus Degraded, Volume Crashed oder Read-Only befindet. Durchgehendes Lesen aller Festplatten ist genau die Belastung, unter der Sie einen geschwächten Verbund endgültig zerstören — derselbe Mechanismus, durch den ein Rebuild oft den RAID-Verbund zerstört. Das Vorgehen bei einem bereits beschädigten Synology im Zustand Storage Pool Degraded und bei einem QNAP mit RAID Group Degraded behandeln wir gesondert.

Wie sich Synology, QNAP und TrueNAS unterscheiden

Synology. Btrfs unterstützen vor allem die firmenorientierten Plus-Reihen — etwa die DS224+ oder DS923+. Die Verfügbarkeit sollten Sie aber immer in der Spezifikation des konkreten Modells und der DSM-Version prüfen, es ist keine Eigenschaft der ganzen Marke. Ein wichtiges technisches Detail: Synology kombiniert Festplatten nicht mit einem nativen Btrfs-RAID. Btrfs liegt bei Synology über einem Linux-Software-RAID (md) und LVM. Damit das zusammen funktioniert, hat Synology einen Weg ergänzt, über den Btrfs bei einer Prüfsummen-Abweichung eine zweite Kopie aus der darunterliegenden RAID-Schicht anfordert. Das funktioniert nur, wenn Prüfsummen für den betreffenden freigegebenen Ordner aktiviert sind und ein redundanter Verbund vorliegt — beides muss man prüfen, nicht annehmen.

QNAP. Die Familie TS-464 und viele weitere QTS-Modelle laufen auf ext4. Dort gibt es schlicht keinen Schutz für Dateiinhalte. ZFS bietet QNAP in dem separaten System QuTS hero an, etwa bei der Reihe TVS-h674. Es reicht also nicht, ein „QNAP mit vier Einschüben” zu kaufen — entscheidend sind das Modell, das installierte Betriebssystem und die Art, wie der Pool angelegt wird. Die Migration zwischen QTS und QuTS hero ist kein Schalter, sondern bedeutet, die Daten umzukopieren.

TrueNAS SCALE. Baut auf OpenZFS auf und bietet die größte Kontrolle über die Gestaltung von Spiegeln, RAIDZ, Snapshots und Replikation. Dafür zahlen Sie mit der Notwendigkeit, das Ganze zu verstehen. Für eine kleine Firma ist es dort sinnvoll, wo ein Dienstleister existiert, der die Lösung entwirft, dokumentiert und ihren Zustand überwacht — nicht als Blackbox, die jemand einmal zusammenklickt und dann sich selbst überlässt.

Was dieser Schutz kostet

Prüfsummen sind kostenlos — sie stecken im Dateisystem. Bezahlen müssen Sie für das, was zur Reparatur nötig ist: redundante Kapazität, genug Einschübe, RAM, eine USV und einen zweiten Standort für das Backup.

Bei einem Zwei-Platten-Spiegel erhalten Sie etwa die Hälfte der Bruttokapazität. RAIDZ1 oder ein Verbund mit einfacher Parität kostet Sie die Kapazität einer Festplatte, RAIDZ2 oder ein Verbund mit doppelter Parität die Kapazität von zweien. Für Firmendokumente ist ein NAS mit vier Einschüben meist die vernünftigere Wahl als das billigste Modell mit zwei Einschüben — es ermöglicht eine widerstandsfähigere Konfiguration und eine spätere Erweiterung, und der Preisunterschied beim Gehäuse selbst ist im Vergleich zum Wert der Daten gering. Festplatten, externen Backup-Speicher und den Migrationsaufwand rechnen Sie separat.

Bei ZFS ist ECC-Speicher empfehlenswert, besonders für wichtige Firmendaten. Die Internet-Legende, dass ZFS ohne ECC Daten zerstört, stimmt nicht — es gilt aber eine einfache Logik: Die Prüfsumme wird im RAM berechnet, sodass ein RAM-Fehler als „korrekt” in den Pool geschrieben wird. ECC senkt dieses Risiko. Und falls Sie keinen konkreten Grund und keinen berechneten Speicherbedarf haben, lassen Sie die ZFS-Deduplizierung deaktiviert; ihr Speicher-Overhead ist der häufigste Grund, warum ein kleiner Pool unbrauchbar langsam wird.

Welche Festplatten und Konfigurationen sinnvoll sind

Wählen Sie Festplatten, die für den Dauerbetrieb im Verbund ausgelegt sind — WD Red Plus oder Red Pro, Seagate IronWolf und IronWolf Pro, Toshiba N300. Prüfen Sie bei jeder konkreten Modellbezeichnung die Aufzeichnungstechnologie; bei niedrigeren Kapazitäten tauchten in der Vergangenheit SMR-Festplatten auf, die sich beim Rebuild im RAID problematisch verhalten. Den Unterschied zwischen CMR und SMR sowie den Vergleich einzelner Serien finden Sie in den Artikeln CMR vs. SMR und WD Red vs. Seagate IronWolf vs. Toshiba N300.

WD Purple gehört nicht in ein NAS für Dokumente, auch wenn er gleich groß und günstiger ist. Er ist für Kamerasysteme gebaut, und seine Firmware ist auf durchgehendes Schreiben von Videodaten optimiert, bei dem der Verlust eines einzelnen Frames toleriert wird. Für Datenbanken und virtuelle Maschinen ist er kein Ersatz.

Was wir beim Entwurf prüfen:

• ob das System überhaupt Datenprüfsummen verwendet,
• ob der Schutz auch für konkrete freigegebene Ordner aktiviert ist, nicht nur theoretisch auf dem Volume,
• welche Redundanz eine Selbstreparatur ermöglicht, nicht nur das Überleben eines Festplattenausfalls,
• ob der Scrub tatsächlich geplant wird und durchläuft,
• wohin die Warnmeldungen gehen und ob sie jemand liest,
• ob das NAS an einer USV hängt und sich korrekt herunterfahren kann,
• ob ein separates Backup existiert und ein Wiederherstellungstest durchgeführt wurde.

Bei nativem Btrfs wählt man für wichtige Daten RAID1 oder RAID10. Die Btrfs-Profile RAID5/6 haben ein seit Langem bekanntes Write-Hole-Problem und sind in der Upstream-Dokumentation als für den Produktivbetrieb nicht empfohlen gekennzeichnet — als automatische Wahl für ein Firmen-NAS taugen sie nicht.

RAID, Snapshot und Backup lösen unterschiedliche Probleme

Hier passieren die häufigsten Denkfehler, nicht Konfigurationsfehler:

• RAID hält den Betrieb bei Ausfall einer bestimmten Anzahl von Festplatten aufrecht.
• Prüfsummen decken auf, dass sich der Inhalt verändert hat.
• Snapshot ermöglicht die Rückkehr zu einer älteren Version.
• Backup rettet die Daten, wenn das gesamte NAS verschwindet oder kompromittiert wird.

Keine dieser Schichten ersetzt die anderen. Ein Snapshot auf demselben NAS ist kein Backup — er verschwindet mit dem Pool, mit dem Gerät und mit einem kompromittierten Administratorkonto. Auch Btrfs und ZFS schützen nicht vor Ransomware, wenn ein Angreifer die Rechte erlangt, Snapshots und Replikate zu löschen; wie so ein Ablauf aussieht, beschreiben wir im Artikel über Ransomware auf dem NAS. Neben lokalen Snapshots brauchen Sie deshalb eine getrennte Kopie: ein zweites NAS, einen Objektspeicher mit passender Aufbewahrungsfrist oder ein Offline-Medium — und die Prinzipien der 3-2-1-Backup-Regel gelten auch für eine Firma mit NAS. Die Wiederherstellung wird getestet, nicht vorausgesetzt.

Woran Sie ein qualitativ gut geplantes NAS erkennen

Ihr Dienstleister sollte Ihnen nicht nur eine Box mit blinkendem RAID übergeben. Zur Übergabe sollte gehören:

• eine Beschreibung von Festplatten, Pool, Volumes und freigegebenen Ordnern,
• wo genau Prüfsummen aktiviert sind,
• ein Zeitplan für Scrub, SMART-Tests und Backups,
• Warnmeldungen, die auf eine konkrete verantwortliche Person eingestellt sind,
• ein Protokoll des Wiederherstellungstests mehrerer Dateien,
• eine Dokumentation der Zugänge und die Möglichkeit der Übergabe an einen anderen Administrator,
• ein Vorgehensplan für den Fall einer defekten Festplatte und eines degradierten Verbunds.

ITHOPE kann vor dem Kauf das Datenvolumen, die geforderte Wiederherstellungszeit, die Kompatibilität der Festplatten und das nötige Redundanzniveau bewerten. Das Ergebnis soll eine dokumentierte Lösung sein, bei der Sie wissen, was sie schützt, was nicht, und wie viel ihr Betrieb kostet.

QUICK ANSWER

Für ein NAS mit wichtigen Firmendaten hat Btrfs gegenüber ext4 einen entscheidenden Vorteil: Prüfsummen für Dateiinhalte und einen Scrub, der stille Datenkorruption erkennt, bevor sie sich in die Backups ausbreiten kann. ZFS bietet denselben Schutz und eine deutlich stärkere Speicherverwaltung, verlangt aber leistungsfähigere Hardware und erfahrenere Administration. Die Erkennung funktioniert auch auf einer einzelnen Festplatte, die Reparatur nur bei Redundanz. Keines der beiden Systeme ersetzt ein separates Backup.

FAQ

Erkennt ext4 eine beschädigte Datei?

Nur dann, wenn sich der Fehler als nicht lesbarer Block zeigt oder wenn ihn die Anwendung selbst über einen eigenen Prüfmechanismus bemerkt — etwa ein Archivierungsprogramm über CRC oder eine Datenbank über die Prüfsumme einer Seite. Ext4 prüft den Inhalt von Datenblöcken standardmäßig nicht gegen eine gespeicherte Prüfsumme.

Repariert Btrfs beschädigte Daten auf einer einzelnen Festplatte?

Es erkennt sie und verweigert die Auslieferung, hat aber ohne eine zweite korrekte Kopie nichts, woraus es wiederherstellen könnte. Für die Selbstreparatur von Daten brauchen Sie einen redundanten Speicher — einen Spiegel oder einen Paritätsverbund.

Ist ZFS immer besser als Btrfs?

Nein. ZFS hat eine ausgefeiltere Pool-Verwaltung, Integritätsprüfung und Replikation, stellt aber höhere Anforderungen an Design, RAM und Administration. Für eine kleinere Firma ist oft ein unterstütztes Synology-System mit Btrfs praktischer, sofern Scrub, Warnmeldungen und Backup richtig eingerichtet sind.

Wie oft sollte man einen NAS-Scrub durchführen?

Einmal im Monat ist ein vernünftiger Ausgangspunkt. Passen Sie den Zeitpunkt an Speichergröße, Betriebslast und Herstellerempfehlung an. Bei einem degradierten Verbund sollten Sie den Scrub nicht ohne vorherige Diagnose starten.

Schützen Btrfs oder ZFS vor Ransomware?

Prüfsummen nicht — eine verschlüsselte Datei ist aus Sicht des Dateisystems eine korrekt geschriebene Datei. Ein Snapshot kann helfen, zum Zustand vor dem Angriff zurückzukehren, aber nur, wenn der Angreifer ihn nicht löschen kann. Sie brauchen getrennte Zugänge, eine passende Aufbewahrungsfrist und ein Backup außerhalb des Haupt-NAS.