Computer sind nicht unfehlbar: Es kommt vor, dass ein Bit im RAM kippt und die Integrität des Dateisystems gefährdet. Dagegen helfen verschiedene Tests des Arbeitsspeichers und der Umbau der Btrfs-Systempartition zum RAID 1.

Hardwarehersteller stehen unter Druck, Performance aus ihren Komponenten herauszukitzeln. Gamer übertakten den Arbeitsspeicher manchmal über die Stabilitätsgrenze hinaus. Man darf realistisch davon ausgehen, dass auf einem Heim-PC jede Woche ein Bit im RAM kippt, also einen falschen Wert annimmt. Dieser Fehler landet beim Speichern womöglich auf der Festplatte. Unter Umständen lässt sich dann die betroffene Datei nicht mehr öffnen. Bit Rot oder Data Degradation sind griffige Namen für dieses Phänomen.

JPEG-Dateien mit Blitzern (Abbildung 1), bei denen wegen der Kompression ein einzelnes gekipptes Bit die Optik des Bilds beeinflusst, dürfte jeder schon einmal gesehen haben. An belastbaren Untersuchungen zur Häufigkeit von Bit-Flips mangelt es in der Praxis aber [1]. Schlimmer wirkt es sich aus, wenn ausführbare Dateien im Root-Dateisystem korrumpiert sind. Versucht der Computer, eine solche Datei auszuführen, kommt es unweigerlich zum Absturz. Zwar ist die Ursache dafür in der Praxis fast immer ein Programmierfehler, doch eine Korruption der ausführbaren Dateien lässt sich nicht kategorisch ausschließen.

Abbildung 1: Eine Datenkorruption in der Mitte der Datei hat dieses JPEG-Bild zerstört.

Sicher gehen

Es mag zunächst vielleicht paranoid klingen, sich um fehlerhafte Systemdateien zu sorgen. Weil sie in der Praxis aber vorkommen, schadet es nicht, sich darum zu kümmern. Auf Distributionen mit RPM-Paketverwaltung wie OpenSuse fällt es jedenfalls leicht, alle per Paket installierten Dateien mit ihrer Ausgangsversion im Paket selbst zu vergleichen. Dazu genügt der Befehl rpm --verify --all, den Sie als Root ausführen.

Bei bestimmten Dateien ist es ganz normal, dass sie sich im laufenden System verändern: Das gilt für das Verzeichnis /var, das ja nicht umsonst die Variabilität schon im Namen trägt, sowie für Konfigurationsdateien im Verzeichnis /etc, bei denen die Softwarepakete lediglich eine Default-Version installieren.

Ausführbare Dateien und Bibliotheken sollten sich jedoch auf keinen Fall von ihren Ursprungsversionen aus dem Installationspaket unterscheiden. Sonst liegt entweder Datenkorruption vor oder Schadsoftware hat sie böswillig verändert. Für eine Übersicht erweitern Sie den RPM-Verify-Aufruf um einen Filter, der alle unkritischen, zu erwartenden Änderungen ausblendet (Listing 1, erste Zeile). Dieser Aufruf sollte keine Ausgabe liefern, die in der ersten Spalte die Zahl 5 enthält, das Kürzel für Prüfsummenfehler. In Abbildung 2 stimmt beispielsweise das Gimp-Binary nicht mehr mit der aus dem Paket installierten Fassung überein.

# rpm --verify --all | grep -E "/usr/lib*|/usr/bin*"
# zypper in -f $(rpm -q -a --qf '%{NAME} ')

Abbildung 2: Die Ziffer 5 in der Ausgabe von rpm --verify --all warnt, dass eine ausführbare Datei von der aus dem Paket installierten Version abweicht. Die beiden letzten Zeilen deuten dagegen nicht auf Datenkorruption hin.

Es fällt unter OpenSuse leicht, alle Pakete neu zu installieren und damit die fehlenden oder verfälschten Dateien aufzufrischen (Listing 1, zweite Zeile). Der Zeitbedarf und die Zahl der Dateien zum Herunterladen sind mit dem eines Dist-Upgrades vergleichbar. Die Neuinstallation stellt die Systemintegrität wieder her, behebt aber nicht den Auslöser der Datenkorruption.

OpenSuse setzt für die Systempartition auf das relativ neue Dateisystem Btrfs, dem eine Datenverfälschung im Gegensatz zu den traditionellen Linux-Dateisystemen wie Ext4 dank Prüfsummen nicht mehr einfach durchrutscht. Entsprechende Fehlermeldungen landen in den Kernel-Logs (Abbildung 3), wo sie Durchschnittsanwendern allerdings verborgen bleiben. Sie lassen sich jedoch mit dem Kommando aus der ersten Zeile von Listing 2 leicht aufspüren.

Abbildung 3: Im Fehlerspeicher dieses Linux-Systems finden sich Hinweise auf fehlerhaften Daten im Root-Dateisystem.

# journalctl --grep "checksum error at"
# btrfs scrub start -Bd /
# btrfs scrub status /

Der Kernel prüft die Checksummen bei jedem Lese- und Schreibvorgang. Dateien, auf die das System selten bis nie zugreift, können dennoch unbemerkt von Datenkorruption betroffen sein. Um dies an den Tag zu fördern, kennt Btrfs das sogenannte Scrubben (Schrubben). Dabei durchkämmt der Kernel das gesamte Dateisystem und prüft alle Checksummen für Datendateien und interne Daten des Dateisystems wie Verzeichnisstrukturen oder Metadaten.

Das Kommando aus der zweiten Zeile von Listing 2 stößt den Scrub-Vorgang für das Root-Verzeichnis an und druckt nach Abschluss einen Statusbericht (Abbildung 4). Der Befehl aus der dritten Zeile zeigt den Status eines früheren Scrub-Vorgangs. In beiden Fällen ist entscheidend, dass in der Ausgabe hinter Error summary: das Resultat no errors found steht. Generell stößt bei OpenSuse ein Systemdienst monatlich einen Scrub aller Btrfs-Dateisysteme an. Dort fehlt allerdings eine gut sichtbare Benachrichtigung auf dem Desktop, wenn der Check einen Fehler zutage gefördert hat.

Abbildung 4: Die Root-Partition dieses Systems, eines RAID 1 auf zwei SSDs an M.2-Schnittstellen des Motherboards, ist fehlerfrei.

Bei Scrub-Fehlern handelt es sich immer um ein Alarmzeichen, das Sie keinesfalls ignorieren sollten. Allerdings kann es sich im Einzelfall um einen sogenannten Single-Event Error handeln, der im selben System nie wieder auftritt.

Single-Event Error

Mit ausreichend Pech können die kosmische Hintergrundstrahlung oder Schwankungen der Versorgungsspannung einen einzelnen Fehler im Dateisystem verursachen [2]. Treten solche Fehler allerdings mehrfach auf, könnte ein tatsächliches Hardwareproblem vorliegt. In den weitaus meisten Fällen erweist sich unzuverlässiger Arbeitsspeicher als Ursache.

Selbst RAM in technisch einwandfreiem Zustand und ohne Übertaktung ist nicht völlig immun gegen kippende Bits. Deswegen liegt es nahe, nach Problemen mit korrupten Daten auf Festplatten oder SSDs das Paket Memtest86+ zu installieren und den Speicher zu prüfen (Abbildung 5). Nach einem Reboot wählen Sie im Startmenü dazu die Option Memtest. Je öfter die Fehlersuche durchläuft, desto besser, denn es liegt in der Natur von Instabilitäten, dass sie manchmal nur sporadisch auftreten. In der Praxis lassen Sie die Prüfroutine am besten über Nacht durchlaufen.

Abbildung 5: Auf diesem System genügt es laut dem im Bootmenü anwählbaren Testprogramm Memtest86+, etwas mehr als 1 KByte RAM auszublenden, um Instabilitäten zu umgehen.

Memtest kennt einen Report-Modus, in dem das Programm nicht mehr alle fehlerhaften RAM-Adressen einzeln benennt, sondern die niedrigste und höchste betroffene Speicherzelle. Um diesen Modus zu wählen, drücken Sie gleich nach dem Start von Memtest hintereinander [F1]+[F4] und [F2]+. Zweimal [F10] schließt das Konfigurationsmenü wieder.

Erscheinen beim Test des Arbeitsspeichers Fehlermeldungen, so müssen Sie nicht unbedingt die RAM-Riegel (Abbildung 6) tauschen: Linux gestattet es, defekte Speicherbereiche vom Systemstart an zu sperren. In der Praxis handelt es sich bei Problemen mit Arbeitsspeicher oft um wenige Zellen, sprich eine so geringe Speichermenge, dass der Verlust für die System-Performance nicht ins Gewicht fällt. Es lohnt sich also definitiv, den defekten Arbeitsspeicher so auszublenden, wie es der Kasten “Fehlerhaftes RAM in Grub ausblenden” beschreibt.

Abbildung 6: Tritt auf dem Rechner Datenkorruption auf, sind häufig die Arbeitsspeicherriegel im Motherboard die Ursache.

Betreiben Sie ein System mit instabilem RAM ohne Gegenmaßnahmen weiter und nehmen die meist nur sporadisch auftretenden Hänger in Kauf, bekommen Sie unvermeidlich über kurz oder lang Probleme mit der Systempartition. Nach dem Ausblenden defekter Blöcke dagegen kann das System ohne Hardwaretausch potenziell noch über Jahre stabil weiterlaufen. Es ist zumindest umstritten, ob das Vorhandensein defekter Blöcke im Arbeitsspeicher überhaupt die Wahrscheinlichkeit eines weiteren Ausfalls steigert.

Abbildung 7: Der KDE-Taschenrechner kennt einen Hexadezimalmodus, der die Differenz zwischen der von Memtest86+ ermittelten Highest Error Address und der Lowest Error Address errechnen kann.

Abbildung 8: In der langen Ausgabe von cat /proc/iomen taucht nach dem entsprechenden Eintrag im Bootloader die via Memtest86+ ermittelte Lowest Error Address für einen als reserved gekennzeichneten Speicherblock auf.

Smart überwacht

Eine weitere potenzielle Quelle von Datenkorruption liegt in defekten Speichergeräten selbst. Alle aktuellen Festplatten und SSDs bringen das Selbstüberwachungssystem SMART mit, dessen Werte Sie im Verdachtsfall auslesen sollten. Einen Überblick über alle im Rechner verbauten Speichergeräte liefert Gparted (Abbildung 9) aus dem gleichnamigen Installationspaket.

Abbildung 9: Per Dropdown rechts oben bietet Gparted einen Überblick über alle Partitionen sämtlicher im Rechner vorhandenen Speichergeräte.

Abbildung 10 zeigt eine typische Ausgabe von smartctl -a /dev/sda, also die Resultate für die erste Festplatte im Rechner. Relevant in der Ausgabe ist zunächst die Zeile SMART overall-health self-assessment test result:. Steht hier PASSED zu sehen, schätzt die eingebaute Überwachungslogik die Platte als funktional ein. FAILED dagegen bedeutet, dass Sie die Daten auf der Platte so schnell wie möglich sichern und die Hardware tauschen sollten.

Abbildung 10: Alle aktuellen Festplatten und SSDs sind mit dem Selbsttestsystem SMART ausgerüstet, über das das Speichergerät seinen eigenen Status überwacht.

Details liefert die Tabelle Vendor Specific SMART Attributes with Thresholds. Einwandfreie Speichergeräte weisen für Reallocated_Sector_Ct und Current_Pending_Sector einen Wert von 0 aus, es gibt also keine defekten Sektoren der Plattenoberfläche. Liegen dagegen bereits defekte Sektoren vor, dann müssen Sie von einer gewissen Ausfallwahrscheinlichkeit ausgehen. Es ist aber keineswegs gesagt, dass die Daten auf der Platte schon korrupt sind. Steigt die Zahl der defekten Sektoren jedoch weiter an, bewegt sie sich in Richtung Totalausfall.

SSDs kennen andere Vendor Specific SMART Attributes als Festplatten. Hier erweist sich zusätzlich zum globalen PASSED vor allem das Attribut Available Spare als relevant. Ein Wert von 100 Prozent deutet auf eine vollständig intakte SSD hin. Die Percentage Used nennt die zu erwartende Restlebensdauer: Die Zahl der Schreibvorgänge pro Sektor auf der SSD ist begrenzt, was früher ein Problem darstellte. Bei hochwertigen SSDs im Desktop-Bereich ergibt sich heute typischerweise eine Abnutzung von grob 1 Prozent pro Jahr, ohne dass man die SSD dafür besonders schonen muss.

Lösungen gefragt

Aber was ist zu tun, sollte die Btrfs-Root-Partition tatsächlich beschädigt sein, also ein Scrub Fehlermeldungen liefert beziehungsweise solche im System-Journal auftauchen? Die schlechte Nachricht zuerst: Es gelingt nicht immer, ein Btrfs-Dateisystem mit schadhaften internen Strukturen zu reparieren. Im schlimmsten Fall bleibt nur noch, das Dateisystem neu zu formatieren und ein Backup zurückzuspielen oder das System neu zu installieren.

Um 2010, als Btrfs als experimentell galt, begründeten Entwickler diesen Status meist damit, dass es kein zuverlässiges Fsck-Pendant gab, um ein kaputtes Dateisystem zu reparieren. Tatsächlich gibt es ein solches bis heute nicht. Das Kommando btrfs check --repair sollte man, wie die Manpage erläutert, nur auf Anraten eines Kernel-Entwicklers oder erfahrenen Benutzers zum Einsatz bringen – was immer das heißen mag. Auf jeden Fall tun Sie gut daran, einen Reparaturversuch niemals ohne vorheriges Backup zu starten.

Die altgedienten Dateisysteme wie Ext4 dagegen lassen sich mit Befehlen wie fsck.ext4 in einen konsistenten Zustand zurückversetzen. Allerdings heißt das im Grunde nichts anderes, als dass das System sämtliche nicht mehr zuzuordnenden Daten verwirft. Es legt sie in kleinen Stücken, die keineswegs den Dateigrenzen vor der Datenkorruption entsprechen müssen, im Ordner /lost+found ab. Btrfs verweigert eine solche “Reparatur”, was im Grunde nicht weniger praxistauglich ist, sondern schlicht ehrlicher.

Wenn das Root-Dateisystem Probleme macht, starten Sie am besten zuallererst eine Datensicherung. Läuft das System noch stabil, dann genügt ein normales Backup der Root-Partition mit Rsync, wie es das Arch-Linux-Wiki empfiehlt [3]. Dabei dürfen Sie der Exclude-Liste '/home' hinzufügen, sofern bereits ein gesondertes, aktuelles Backup ihrer Benutzerdaten vorliegt.

Zunächst gilt es, zu klären, wie schwer das Root-Dateisystem beschädigt ist. Hat der Journalctl-Befehl nur einen oder wenige Prüfsummenfehler zutage gefördert, reicht es eventuell, die von den gegen Ende der Logzeilen als Path genannten Dateien per Paket neu zu installieren. Das Kommando zypper wp /Pfad/zur/Datei nennt die erforderlichen Paketnamen. Dem path in der Fehlermeldung im System-Journal stellen Sie dabei noch ein / voran.

Liegen in der System-Protokolldatei dagegen Meldungen vor, dass die interne Verweisstruktur des Dateisystems Fehler aufweist (Abbildung 11), lässt sich das Problem vermutlich nur noch durch Neuformatieren und Neuinstallation oder Zurückspielen eines Backups lösen. Alle Optionen zur Reparatur eines Btrfs-Dateisystems fasst eine Seite im OpenSuse-Wiki [4] zusammen.

Abbildung 11: Gibt es in den Kernel-Logs wie hier Einträge vom Typ metadata leaf (...) in tree ..., dann ist das zugehörige Btrfs-Dateisystem wahrscheinlich nicht mehr zu retten.

Alles auf Anfang

Die Meldungen über Prüfsummenfehler verschwinden nach dem Neuinstallieren betroffener Pakete nicht. Es ist das einfachste, sie zu ignorieren, sofern die Reinstallation der betroffenen oder aller Pakete sicherstellt, dass die Dateien trotz der Meldungen wieder intakt sind.

Legen Sie Wert auf ein fehlermeldungsfrei laufendes System, dann setzen Sie die Checksummen aus einem Live-System heraus zurück (Listing 3). Wie bereits erwähnt, sollten Sie die Option--repair allerdings nie ohne vorherige Datensicherung anwenden.

# btrfs check --repair --init-csum-tree /dev/sda2

Bei einem jenseits der Wiederherstellbarkeit beschädigten OpenSuse-System ist es oft das einfachste, die Konfigurationsdateien aus /etc zu retten und eine Liste der installierten Pakete anzulegen. Damit gelingt es schnell, ein neu installiertes System wieder so einzurichten wie das havarierte.

Der Befehl aus der zweiten Zeile von Listing 4 erzeugt eine Liste der gegenwärtig installierten Pakete. Haben Sie eigene Repositorys eingebunden, dann liefert das Kommando aus der dritten Zeile einen Überblick inklusive der Repository-URLs, mit denen Sie die Pakete im neuen System wieder einbinden.

### Auf dem alten System
# rpm -q -a --qf '%{NAME} ' > paketliste.txt
# zypper lr -u > repositories.txt
### Auf dem neuen System
# cat paketliste.txt | xargs zypper install

Nach der Neuinstallation binden Sie zuerst die zusätzlichen Repositorys wieder ein, was am leichtesten im YaST-Modul Repositorys gelingt. Sie müssen dazu lediglich die URLs aus der im alten System gesicherten Datei repositories.txt und einen eindeutigen Namen eintragen (Abbildung 12).

Abbildung 12: Mit den Repository-URLs aus der vor der Neuinstallation erzeugten Liste gelingt das Neueinbinden eventuell per Hand hinzugefügter Repositorys mit wenigen Mausklicks.

Anschließend kopieren Sie die Paketliste in ein Verzeichnis des neuen Systems und führen dort den Befehl aus der letzten Zeile von Listing 4 aus, um den alten Paketbestand wiederherzustellen.

Doppelt sicher

Haben Sie sich schon einmal mit dem Thema Datensicherheit beschäftigt, dürfte Ihnen der Begriff RAID begegnet sein. Bei RAID 1 liegen alle Daten parallel auf zwei Speichergeräten. Das verdoppelt zwar den Platzbedarf, erhöht die Sicherheit der Daten vor allem in Kombination mit den Prüfsummen von Btrfs.

Stellt der Kernel einen Prüfsummenfehler auf einer der RAID-1-Komponenten fest, überschreibt er die Daten automatisch mit den gespiegelten Daten aus der anderen, sofern dort die Checksummen stimmen. Dass die Daten beider Instanzen gleichzeitig einer Korruption unterliegen, ist äußerst unwahrscheinlich. Die Selbstheilung erfolgt bei jedem Lese- und Schreibzugriff sowie beim monatlichen Scrub des Dateisystems. Sie deckt neben den Nutzdaten im Dateisystem auch alle Metadaten und internen Strukturen des Dateisystems ab.

Das Btrfs-Dateisystem einer bestehenden OpenSuse-Standardinstallation lässt sich im Handumdrehen zum RAID 1 aufrüsten, wenn eine zweite Festplatte oder SSD im Rechner steckt, die Platz für eine zweite Partition in der Größe der Root-Partition bietet. Bei RAID 1 bremst das langsamere der beiden Speichergerät das schnellere aus. Daher eignen sich für ein RAID 1 zwei Speichergeräte des gleichen Typs am besten.

Am einfachsten gelingt das Partitionieren einer bisher unbenutzten Festplatte oder SSD mit dem grafischen Programm Gparted. Abbildung 13 zeigt eine Festplatte, auf der eine mit den Standardeinstellungen vorgenommene OpenSuse-Installation liegt. Den meisten Platz nimmt dabei die Systempartition ein, wie sie der Installer ohne händischen Eingriff anlegt.

Abbildung 13: Mit Gparted richten Sie mühelos eine zweite Instanz der Root-Partition auf der zweiten Festplatte ein (hier in einer VM vda2, sonst sda2).

Richten Sie auf dem noch unbenutzten Laufwerk per Rechtsklick und anschließender Auswahl von Neu eine Partition in genau der Größe der ursprünglichen Systempartition an. Es bietet sich an, den Dateisystemtyp der neuen Partition per Formatieren als auf gelöscht zu setzen, also die Partition als unformatiert zu kennzeichnen. Erstellen Sie sie erst jetzt mit einem Klick auf den grünen Haken in der Schalterleiste von Gparted. Über einen Reboot machen Sie anschließend die neue Partition im System verfügbar.

Merken Sie sich vorher den in Gparted in der linken Spalte angezeigten Device-Namen der neuen Partition. Im folgenden Beispiel verwenden wir /dev/sdb1 für die erste (und einzige) Partition auf der zweiten Platte. Diesen Bezeichner müssen Sie gegebenenfalls durch den richtigen Gerätenamen auf Ihrem System ersetzen.

Registrieren Sie jetzt mit Administratorrechten die neue Partition im Root-Dateisystem (Listing 5, erste Zeile). Dann wandeln Sie den eben angelegten Verbund aus zwei Festplattengeräten in ein RAID 1 um (zweite Zeile). Nach dem Abschluss des Kopiervorgangs der vorliegenden Daten auf die zweite Partition zeigt Gparted für beide Partitionen identische Platzangaben (Abbildung 14).

# btrfs device add /dev/sdb1 /
# btrfs Pflanze start -dconvert=raid1 -mconvert=raid1 /

Abbildung 14: Nach der balance-Operation weisen die ursprüngliche Root-Partition und deren neu angelegter RAID-1-Spiegel denselben Belegungsgrad auf (gelber Bereich im Partitionsbalken).

Weitere Änderungen am System, etwa an der Konfigurationsdatei /etc/fstab, können Sie sich schenken: Hängt Linux beim Start die bisherige Root-Partition ein, erkennt der Kernel automatisch, dass es sich dabei nun um einen Teil eines RAID-1-Verbunds handelt. Sie testen dies jederzeit durch Eingabe des Kommandos btrfs filesystem show, das alle auf dem System eingebundenen Btrfs-Dateisysteme listet. Ein RAID 1 liegt dann vor, wenn ein Dateisystem aus zwei Devices besteht und außerdem der als used ausgewiesene Speicherplatz auf beiden Geräten gleich groß ausfällt.

Fazit

Eine zweite Festplatte oder SSD in den Rechner einzubauen und das unter OpenSuse standardmäßig genutzte Btrfs-Dateisystem zum RAID 1 zu erweitern, gelingt einfach und kommt der Sicherheit der Daten auf dem Rechner sehr zugute. (uba)