Wir erwarten von Datenträgern und Dateisystemen, dass diese unsere Daten sicher speichern. In der Praxis kommt es allerdings immer wieder zu unerwarteten und unentdeckten Datenverlusten. Wie kommt es dazu, und wie kann die Wahl des (richtigen) Dateisystems die Situation entschärfen?

Das Standard-Dateisystem für neue Linux-Installationen ist üblicherweise immer noch ext4. Es bietet erhebliche Vorteile gegenüber älteren Dateisystemen, insbesondere verhindert das eingebaute Journaling Datenverlust im Falle eines Stromausfalls oder falls das System unerwartet nicht mehr reagieren sollte. Aber ext4 fehlen immer noch viele Funktionen, welche man heute von einem modernen Dateisystem erwartet:

• Konsistenter Zugriff auf ältere Dateisystemzustände (Snapshots), z.B. zum Erstellen von Backups ohne das System anhalten zu müssen
• Mehr als eine Dateisystemhierarchie auf einem einzelnen Massenspeicher (Subvolumes). Partitionen werden dadurch überflüssig, und der Speicherplatz kann eventuell effizienter genutzt werden
• Online-Kompression
• Deduplikation (Datenblöcke mit demselben Inhalt werden nur einmal gespeichert)
• Zusätzliche Prüfsummen, um Datenverluste zu verhindern
• Stärkere Kopplung an das/die Speichersubsystem(e), damit Prüfsummen in Fehlersituationen zur besseren Entscheidungsfindung verwendet werden können

Die Erweiterung von ext4 um diese Funktionen würde wesentliche Änderungen am Programmcode und den Datenstrukturen auf der Festplatte (dem sogenannten Disk-Layout) erfordern. Außerdem wären Konvertierungsstrategien für ältere Laufwerke erforderlich, und die Benutzer könnten ihre neu formatierten Datenträger nicht mit älteren Systemen verwenden. Dateisystem-Entwickler versuchen dies bis zu einem gewissen Grad zu vermeiden, indem sie generische Datenstrukturen und Flags verwenden. Häufig kann man bei der Formatierung des Dateisystems entscheiden, welche Funktionen aktiviert werden sollen, und einige davon sogar erst später aktivieren oder auch wieder deaktivieren.

Snapshots, Subvolumes, Deduplikation oder Kompression interessieren mich nicht, aber Datensicherheit ist mir sehr wichtig. Ich möchte daher kein Dateisystem mehr verwenden müssen, welches keine Prüfsummen verwendet.

Warum sollte ich mich für Datensicherheit interessieren?

Daten werden auf Massenspeichern normalerweise in Blöcken (oder “Sektoren”, wie man diese in den 1980er Jahren nannte) gespeichert. Man erwartet vom Laufwerk, dass es dem Betriebssystem mitteilt, falls es einen dieser Blöcke nicht mehr lesen kann. Dies kann besonders bei magnetischen Laufwerken vorkommen. Manchmal sind die Magnetplatten zu alt und können nicht mehr ausreichend magnetisiert werden, um während der nächsten Lesephase die korrekten Signale zu erzeugen. Oder der Lesekopf ist nicht richtig positioniert und liest den falschen Sektor. Oder die kosmische Hintergrundstrahlung lässt ein Bit “umkippen”. Solid-State-Laufwerke (SSDs) leiden allerdings auch unter Verschleiß. Ab einem gewissen Punkt sind die Flash-Zellen nicht mehr in der Lage, ihre Ladung bis zum nächsten Lesezyklus zu halten. Programmierfehler in der Laufwerks- oder Controller-Firmware sind ebenfalls eine mögliche Fehlerquelle.

In der Praxis kann den Laufwerken und Controllern nicht vertraut werden, und die ursprüngliche Annahme erweist sich leider als unwahr. Ich habe viel zu viele Fälle gesehen, in welchen ein Laufwerk/Controller falsche Daten oder sogar bei jedem Zugriff auf denselben Sektor unterschiedliche Daten zurückgeliefert hat. Entweder wusste das Laufwerk nicht, dass die Daten unbrauchbar waren, weil es gar keine Möglichkeiten hatte, diese zu überprüfen. Oder die Firmware war eben fehlerhaft.

Laut einer alten Studie von DeepSpar, einem Dienstleister für Datenwiederherstellung, war menschliches Versagen in nur zwölf Prozent der analysierten Fälle die Ursache für den Datenverlust, Softwarefehler in dreizehn Prozent der Fälle, aber Laufwerksausfälle (38%) und Lesefehler (30%) machten den Löwenanteil aus. Dies passt sehr gut zu meiner eigenen Erfahrung.

Ich erwarte nicht, dass sich die Situation in Zukunft verbessern wird. Die Hardwarefehlerraten werden nicht wesentlich sinken, aber die Softwarefehler scheinen sich zu verschlimmern. Ich musste in meiner ganzen professionellen Karriere (mittlerweile immerhin über 20 Jahre) nie die Firmware einer Magnetfestplatte aktualisieren. Aber im Falle von SSDs ist dies so üblich geworden, dass es sogar Firmware-Update-Tools mit grafischen Oberflächen für normale Heimanwender gibt.

Man muss also davon ausgehen, dass ein Laufwerk irgendwann stillschweigend Daten verlieren wird, die technische Bezeichnung dafür ist Silent Data Corruption (“Stille Datenkorruption”). Das ist natürlich eine ziemlich schlechte Nachricht für uns alle. Die Laufwerke speichern immer mehr Daten, sind immer länger im Einsatz und die Migration der Daten auf ein neues Laufwerk dauert immer länger. Silent Data Corruption umgeht sogar Backup-Strategien, welche die Daten regelmäßig zu einem “zuverlässigen” Server oder Cloud-Provider übertragen. Wenn die Daten auf dem lokalen System beschädigt sind, wird das Backup irgendwann auch mit den fehlerhaften Daten überschrieben – was man dann erst herausfindet, wenn es zu spät ist.

Dies betrifft auch alle Datentransfers zwischen zwei Systemen, z.B. mit Hilfe von USB-Laufwerken. Die Daten, welche das erster Gerät auf dem Laufwerk speichert, sind möglicherweise nicht identisch mit den Daten, welche das zweite Gerät später lesen wird.

Selbst RAID hilft nicht

Die Nutzer erwarten, dass RAID-Arrays ihre Daten schützen, aber fast alle Implementierungen tun dies nicht. RAID 0 bietet sowieso keine Redundanz, falls eines der Laufwerke einen Block verliert, sind die Daten nicht mehr vorhanden. Aber auch die RAID-Level 1/5/6, welche Redundanz und/oder Paritäten zur Erhöhung der Datensicherheit verwenden, haben ein großes Problem: Die Entwickler opfern im Normalfall Datensicherheit zu Gunsten einer höheren Geschwindigkeit. Die redundanten Kopien oder die Paritäten werden dann nur überprüft, wenn ein Laufwerk einen Lesefehler gemeldet hat. Andernfalls wäre das gesamte Array – im besten Fall – nur so schnell wie ein einzelnes Laufwerk.

In den letzten zwanzig Jahren ist mir nur einen einziger Hardware-RAID-Controller untergekommen, welcher dazu gezwungen werden konnte, die Parität bei jedem einzelnen Lesevorgang zu überprüfen. Software-Implementierungen wie Linux md-raid und LVM können ebenfalls nicht dazu gezwungen werden. Alles, was man tun kann, ist regelmäßige Überprüfungen (“Scrubs”) des gesamten Arrays durchzuführen. Aber wenn die Daten zwischen zwei Scrubs stillschweigend verloren gegangen sind, hat man ja schon die ganze Zeit mit den fehlerhaften Daten gearbeitet. Herzlichen Glückwunsch.

Im Fall von RAID 1, welches einfach eine Kopie der Daten auf einem zweiten Laufwerk speichert, kommt es sogar noch schlimmer. Wenn man bei jedem Zugriff beide Kopien eines Datums lesen würde (was sowieso niemand tut), und sie wären nicht identisch, welcher der beiden könnte man dann vertrauen? Es gibt keine automatische Lösung für dieses Problem. Daher werfen die meisten Implementierungen (einschließlich das in Linux enthaltene Software-RAID md-raid) eine Münze und vertrauen dem beschädigten Block in 50% der Fälle. RAID 1 ist also ohne zusätzliche Vorsichtsmaßnahmen wertlos. Eine recht ironische Situation, da viele Heimanwender ihren RAID-1-NAS-Boxen mit zwei Laufwerken schließlich ihre Backups anvertrauen.

Wie Prüfsummen Daten schützen helfen

Die Standardlösung für all diese Probleme besteht darin, für jeden Datenblock eine Prüfsumme zu berechnen und diese zusätzlich separat zu speichern. Jedes Mal, wenn ein Block gelesen wird, überprüft der Dateisystemcode, ob die Prüfsumme immer noch mit den Daten übereinstimmt. Falls nicht, lügt das Laufwerk. Enterprise-Laufwerke können Prüfsummen in einem separaten Bereich speichern, indem sie im Hintergrund größere Blöcke mit einer Größe von 520/4104 statt 512/4096 Bytes verwenden.

Auf die zusätzlichen acht Bytes kann das Betriebssystem über eine Funktion namens T10 Protection Information (T10-PI) zugreifen. Auf Consumer-Laufwerken muss das Dateisystem die Prüfsummen zusammen mit dem Rest der Daten speichern, wodurch der dem Nutzer zur Verfügung stehende Speicherplatz leicht reduziert wird.

Dies ist in allen Situationen nützlich. Selbst wenn nur ein einziges Laufwerk verwendet wird, erfährt man sofort, falls dieses Daten verliert und kann dann Schlimmeres verhindern. Das Betriebssystem meldet dann Lesefehler an die Anwendungen, statt beschädigte Daten zurück zu liefern. Die Backup-Software überschreibt das gute Backup auf dem Server oder in der Cloud nicht. Man liest keine keine beschädigten Daten von einem billigen USB-Stick.

Prüfsummen lösen auch die meisten der erwähnten RAID-Probleme. In einem RAID 1 kann man nun plötzlich herausfinden, welches der beiden Laufwerke lügt, und dann der guten Kopie vertrauen. Man kann schnelle UND sichere RAID-5/6-Arrays bauen, da man jetzt bei jedem Lesezugriff mit Sicherheit feststellen kann, ob die Daten beschädigt wurden, und diese dann aus den Paritäten rekonstruieren kann. Man kann sogar versuchen, die beschädigten Daten mit der guten Kopie zu überschreiben (sogenanntes “Resilvering”). Oft wird das Laufwerk dann den Block neu zuordnen und muss nicht sofort ersetzt werden.

Warum ZFS oder BTRFS?

Von den gängigen Linux-Dateisystemen sollten ext4 und XFS um Prüfsummen sowohl für Metadaten als auch für Datenblöcke erweitert werden. Die xfsprogs aktivieren seit Version 3.2.3 (veröffentlicht im Mai 2015) ab Werk Metadaten-Prüfsummen für alle neu angelegten XFS-Dateisysteme. Die e2fsprogs aktivieren das Flag metadata_csums (Metadaten-Prüfsummen) erst seit der Version 1.44.0 (veröffentlicht im März 2018). Ältere Linux-Distributionen liefern in der Regel keine ausreichend aktuelle Version von e2fsprogs aus, so dass dieses Feature die meiste Zeit ungenutzt bleibt.

Der experimentelle xfs_scrub-Befehl kann eine Online-Überprüfung eines XFS-Dateisystems durchführen, für ext4 gibt es keine Online-Dateisystemüberprüfung.

Ext4 und die meisten anderen Linux-Dateisysteme sind auch nur sehr lose mit der Speicherschicht verbunden. Zum Beispiel interessiert es den Dateisystem-Code nicht, ob das Dateisystem auf einem RAID-Array, einer internen SSD oder einem USB-Stick läuft. Er sieht in allen Fällen nur einen einzelnen, großen, simplen Massenspeicher. Selbst wenn Prüfsummen vollständig hinzugefügt und aktiviert werden würden, könnten alle weiter oben genannten RAID-Tricks nicht realisiert werden. XFS und ext4 sind also trotz der existierenden Metadaten-Prüfsummen keine guten Lösungen für das Problem.

Sun Microsystems hat für Solaris das ursprünglich Zettabyte File System getaufte ZFS als modernes Dateisystem mit vielen Funktionen entwickelt, darunter Prüfsummen für alle Daten. Es verfügt über eine eigene Speicherschicht, eigene RAID-Implementierungen und kann alle Prüfungen online durchführen (also während das Dateisystem eingebunden ist). Es wurde als Teil von OpenSolaris unter einer Open-Source-Lizenz freigegeben, kann aber aufgrund von Lizenzbeschränkungen nicht einfach in den Linux-Kernel integriert werden. Ubuntu ist die einzige Linux-Distribution, welche ein vorgefertigtes ZFSonLinux-Kernel-Modul mitliefert. Unter allen anderen Distributionen ist die Installation komplizierter.

Ich empfehle die Verwendung von ZFS, sofern nichts dagegen spricht, benutze es selbst aber auch nur in meiner Ubuntu-basierten NAS und einigen anderen Servern. Die Einrichtung ist vergleichsweise kompliziert. ZFS wurde auch nicht für die Nutzung auf externen, entfernbaren Laufwerken (z.B. USB-Festplatten) ausgelegt, was es für viele Anwendungsfälle weniger attraktiv macht.

BTRFS bietet viele der von ZFS eingeführten Funktionen, einschließlich Prüfsummen und eigener RAID-Level-Implementierungen, ist aber Teil des Standard-Linux-Kernels und unter der GPL lizenziert. Es kann mit den meisten Linux-Installationen bereits seit vielen Jahren genutzt werden. Im Gegensatz zu ZFS unterstützt es externe Laufwerke, man kann diese sogar einfach wie gewohnt anschließen und mit der bevorzugten graphischen Oberfläche mounten. Leider hat BTRFS einige große Probleme mit möglichen Datenverlusten in den RAID5/6-Modi, daher sollten diese Modi nicht verwendet werden. Es ist immer ratsam, erst im BTRFS-Wiki zu überprüfen, ob der eigene Anwendungsfall vollständig unterstützt wird.

Ich verwende BTRSFS seit ca. zwei Jahren ohne Probleme im RAID 1- und RAID10-Modus für Scratch-Arrays und alle externen USB-Laufwerke. Meines Wissen ist Synology der einzige Hersteller, welches BTRFS auf seinen NAS-Systemen anbietet, ich habe die genaue Implementierung aber nicht überprüft.

Dieser Gastbeitrag wurde ursprünglich von Simon Raffeiner für lieberbiber.de verfasst und erschien dort auf Englisch unter dem Titel “Improving data safety on Linux systems using ZFS and BTRFS”.

Artikelbild von Patrick Lindenberg auf Unsplash