VMware ESXi and vSphere Cluster Management

Dateisysteme unter Linux debuggen: ext2/ext3/ext4 mit debugfs und XFS mit xfs_db

Linux-Dateisysteme sicher untersuchen: debugfs für ext2, ext3 und ext4 sowie xfs_db für XFS. Mit Superblock-, Inode- und Datenrettungsbeispielen.

Mit Dateisystem-Debugging untersuchst du interne Strukturen eines Linux-Dateisystems. Dafür stehen je nach Dateisystem unterschiedliche Werkzeuge zur Verfügung: debugfs für ext2, ext3 und ext4 sowie xfs_db für XFS.

Diese Werkzeuge arbeiten hauptsächlich auf der Metadatenebene. Sie zeigen unter anderem Superblock-Informationen, Inodes, Verzeichniseinträge und Blockzuordnungen. Eine Analyse ist nicht dasselbe wie eine Reparatur oder Datenwiederherstellung.

Zweck und Grenzen des Dateisystem-Debuggings

Ein Dateisystem ist die Struktur und Regelmenge, mit der ein Datenträger Dateien, Verzeichnisse und Metadaten verwaltet. Beim Debugging untersuchst du diese Strukturen möglichst kontrolliert und zunächst lesend.

Ändernde Befehle können einen beschädigten Zustand verschlimmern. Deshalb sollte die Diagnose zuerst nur lesend erfolgen. Ein Dateisystem-Check ersetzt keinen Debugger und umgekehrt: e2fsck oder xfs_repair haben andere Aufgaben als die interaktiven Analysewerkzeuge.

Sicherheitsmaßnahmen vor dem Einsatz

1. Gerät eindeutig identifizieren: Unterscheide Blockgerät, Partition und Dateisystem-Image. Ein Blockgerät ist eine Gerätedatei für einen Datenträger oder eine Partition, beispielsweise unter /dev/.
2. Mount-Status prüfen: Das betroffene Dateisystem sollte vor der Untersuchung ausgehängt werden. Aushängen bedeutet, es vom laufenden Verzeichnisbaum zu trennen.
3. Image oder Backup erstellen: Vor riskanten Arbeiten ist ein sektorbasiertes Image oder ein verlässliches Backup sinnvoll.
4. Schreibzugriffe stoppen: Bei einem beschädigten Datenträger möglichst nur lesend arbeiten. Jede weitere Aktivität kann gelöschte Datenblöcke überschreiben.
5. Separates Zielmedium verwenden: Gerettete Daten dürfen nicht auf dasselbe Dateisystem geschrieben werden, aus dem sie stammen.

Besonders bei Datenrettung ist ein Image die bessere Arbeitsgrundlage. So kannst du Befehle und Varianten an einer Kopie testen, während das Original unverändert bleibt.

Werkzeugzuordnung nach Dateisystem

debugfs für ext2, ext3 und ext4

debugfs ist eine interaktive Debug-Shell für die ext-Familie. ext2 ist ein älteres Linux-Dateisystem ohne Journaling. ext3 ergänzt Journaling, also die Protokollierung bestimmter Metadatenänderungen. ext4 ist eine weiterentwickelte und weit verbreitete Variante.

Starte debugfs mit einer passenden Partition, einem Blockgerät oder einem Image:

debugfs /dev/DEVICE

Ersetze /dev/DEVICE durch das tatsächlich identifizierte Gerät. Nach dem Start erscheint ein Prompt. Befehle werden nun innerhalb von debugfs eingegeben, nicht als normale Shell-Befehle:

debugfs 1.47.x
debugfs:  help

Die verfügbaren Befehle und ihre Syntax können je nach Version variieren. Mit help rufst du die eingebaute Hilfe auf. Verwende den Schreibmodus nur bewusst und erst nach Sicherung und Aushängen des Dateisystems.

Superblock und Dateisystem-Metadaten untersuchen

Der Superblock ist eine zentrale Metadatenstruktur. Er beschreibt grundlegende Eigenschaften des Dateisystems, etwa seine Größe und Konfiguration. Innerhalb von debugfs kannst du Statistiken anzeigen:

debugfs:  show_super_stats
debugfs:  stats

show_super_stats liefert ausführliche Superblock- und Gruppeninformationen. stats ist eine kompaktere beziehungsweise alternative Statistikabfrage. Die konkrete Ausgabe hängt von Version, Dateisystem und Konfiguration ab.

Achte insbesondere auf:

• Dateisystemtyp: Bestätigt, dass das gewählte Werkzeug passt.
• Blockgröße und Blockanzahl: Helfen bei der Einordnung der Speicherstruktur.
• Inode-Anzahl: Zeigt, wie viele Inode-Objekte vorgesehen sind.
• Mount-Status: Gibt Hinweise darauf, ob das Dateisystem sauber ausgehängt wurde oder noch als aktiv gilt.
• UUID: Eine Kennung zum Abgleich mit anderen Geräteinformationen.
• Features: Aktivierte Dateisystemfunktionen, beispielsweise Journaling oder ext4-spezifische Merkmale.
• Fehlerstatus: Hinweise auf erkannte Fehler oder einen nicht sauberen Zustand.

Inodes, Dateien und Verzeichnisse untersuchen

Ein Inode ist das Metadatenobjekt einer Datei oder eines Verzeichnisses. Er enthält typischerweise Dateityp, Berechtigungen, Eigentümer, Größe, Zeitstempel, Link-Zahl und Verweise auf Datenblöcke. Der Dateiname steht üblicherweise nicht im Inode.

Ein Verzeichniseintrag verbindet einen Dateinamen mit einer Inode-Nummer. Vereinfacht sieht die Beziehung so aus:

Dateiname -> Verzeichniseintrag -> Inode -> Datenblöcke

Die Metadaten einer bekannten Datei oder Inode fragst du mit stat ab:

debugfs:  stat /pfad/zur/datei
debugfs:  stat <INODE>

Die genaue Schreibweise für eine Inode-Nummer und die verfügbaren Navigationsbefehle prüfst du mit help. Je nach Version kannst du innerhalb der Debug-Shell Verzeichnisse wechseln, Einträge auflisten und unterstützte Dateisystemoperationen ausführen. Solche Operationen solltest du bei einem beschädigten Original nicht als Experiment verwenden.

Beispiel: Metadaten einer bekannten Datei

1. Öffne debugfs auf dem richtigen, möglichst ausgehängten ext-Dateisystem.
2. Frage den Pfad mit stat ab.
3. Vergleiche Dateityp, Größe, Berechtigungen, Eigentümer, Zeitstempel und Link-Zahl mit deinen Erwartungen.
4. Prüfe bei Unstimmigkeiten zusätzlich die Verzeichniseinträge und die Blockzuordnung.
5. Dokumentiere die Inode-Nummer und beende die Sitzung mit quit.

Gelöschte Dateien mit ext-Dateisystemen untersuchen

Beim Löschen verschwinden häufig der Verzeichniseintrag und die aktuelle Zuordnung der Inode. Die Datenblöcke können jedoch noch vorhanden sein, solange sie nicht durch neue Daten überschrieben wurden. Deshalb ist eine Wiederherstellung möglich, aber keineswegs garantiert.

Suche zunächst nach gelöschten Inodes:

debugfs:  list_deleted_inodes

Bewerte gefundene Inodes anhand von Größe, Zeitstempeln, Dateityp und weiteren Hinweisen. Ein möglicher Wiederherstellungsversuch verwendet eine Inode-Nummer und einen neuen Namen:

debugfs:  undelete INODE NAME

Der Erfolg hängt unter anderem von folgenden Faktoren ab:

• ob die Datenblöcke bereits überschrieben wurden,
• wie lange die Löschung zurückliegt und welche Schreibaktivität danach stattfand,
• wie stark die Datei fragmentiert war,
• ob die Metadaten noch ausreichend intakt sind,
• ob die Datei vollständig und mit einem erkennbaren Typ rekonstruiert werden kann.

Nach einem Wiederherstellungsversuch müssen Dateigröße, Inhalt, Dateityp und möglichst auch eine Prüfsumme kontrolliert werden. Eine scheinbar erzeugte Datei ist nicht automatisch vollständig oder korrekt.

Dateien aus debugfs exportieren

Bei einem Rettungsversuch soll das untersuchte Dateisystem nicht als Ziel für gerettete Inhalte dienen. Quellobjekt und Zielpfad müssen eindeutig getrennt sein.

Wichtig ist die Semantik der Befehle: In vielen e2fsprogs-Versionen schreibt write eine lokale Quelldatei in das untersuchte ext-Dateisystem. Das kann den Datenträger verändern und ist daher kein sicherer Export aus dem Dateisystem:

debugfs:  write QUELLDATEI DATEI

Für das Auslesen eines Inode-Inhalts auf einen separaten lokalen Zielpfad ist je nach debugfs-Version der dafür vorgesehene Exportbefehl, häufig dump, die passendere Wahl. Prüfe die Syntax mit help und arbeite auf einem Image oder einem ausgehängten Dateisystem:

debugfs:  help
debugfs:  dump <INODE> /sicheres/ziel/gerettete-datei

Falls deine Version den im Arbeitsablauf vorgesehenen write-Befehl für einen bestimmten Export unterstützt, verifiziere seine genaue Bedeutung vor der Ausführung. Niemals einen Zielpfad auf dem beschädigten Quell-Dateisystem verwenden.

Wichtige debugfs-Befehle

xfs_db für XFS

XFS ist ein leistungsfähiges Linux-Dateisystem mit eigener Werkzeugfamilie. Für die interaktive Metadatenanalyse verwendest du xfs_db, nicht debugfs.

xfs_db /dev/DEVICE

Alternativ kannst du ein XFS-Image öffnen. Nach dem Start arbeitest du am interaktiven Prompt:

xfs_db /dev/DEVICE
xfs_db> help

Mit help listest du die verfügbaren, versionsabhängigen Befehle auf. Der Schwerpunkt von xfs_db liegt auf der Untersuchung XFS-spezifischer Metadaten. Reparatur und Datenwiederherstellung erfordern gegebenenfalls andere XFS-Werkzeuge und Verfahren, insbesondere xfs_repair für eine geplante Reparatur.

Auch bei XFS gilt: Dateisystemtyp zuerst bestätigen, das Dateisystem möglichst aushängen oder ein konsistentes Image verwenden und die Analyse zunächst lesend durchführen.

Beispiel: XFS-Metadaten prüfen

1. Stelle sicher, dass das Gerät tatsächlich XFS enthält.
2. Hänge das Dateisystem aus oder verwende ein forensisches Image.
3. Starte xfs_db mit dem Gerät oder Image.
4. Rufe help auf und wähle nur Befehle zur Metadatenanalyse.
5. Dokumentiere Ausgaben und bewerte Reparaturmaßnahmen separat.

Sicherer Ablauf bei Diagnose und Wiederherstellung

Fehlerdiagnose und typische Probleme

Das falsche Werkzeug wurde gewählt

Problem: debugfs wird auf einem XFS-Dateisystem verwendet. Ursache: Der Dateisystemtyp wurde nicht geprüft. Lösung: Gerätetyp anhand von Mount-Informationen, UUID, Label und Dateisystemprüfung bestätigen und für XFS xfs_db einsetzen.

Das Dateisystem ist noch eingehängt

Ursache: Das laufende System oder ein Prozess verwendet den Einhängepunkt noch. Prüfe Mount-Status und zugreifende Prozesse. Hänge das Dateisystem ordnungsgemäß aus oder arbeite im Wartungsmodus beziehungsweise mit einem konsistenten Image.

Eine gelöschte Datei erscheint nicht

Metadaten können bereits bereinigt worden sein, oder die Datei ist über diesen Mechanismus nicht mehr auffindbar. Stoppe weitere Schreibzugriffe, sichere ein Image und berücksichtige spezialisierte Datenrettungsverfahren.

Die wiederhergestellte Datei ist beschädigt

Teilweise Überschreibung oder Fragmentierung kann zu unvollständigen Inhalten führen. Kontrolliere Größe, Dateityp, Prüfsumme und Anwendungslesbarkeit. Bewahre die gerettete Kopie auf und teste weitere Ansätze nur am Image.

Der Superblock meldet einen unerwarteten Zustand

Ein unsauberes Herunterfahren, ein nicht korrekt ausgehängtes Dateisystem oder ein Metadatendefekt kann Fehler- und Mount-Status erklären. Dokumentiere die Ausgabe, beziehe Systemprotokolle ein und plane eine Reparatur erst nach Backup oder Image mit dem passenden Werkzeug.

Die richtige Partition ist unklar

Bei mehreren Datenträgern oder verschachtelten Speicherstrukturen vergleichst du Größe, Label, UUID, Partitionierung und Mount-Zuordnung. Starte debugfs oder xfs_db erst nach eindeutiger Identifikation und führe niemals auf Verdacht schreibende Befehle aus.

Sitzung beenden und Ergebnisse dokumentieren

Beende eine debugfs-Sitzung mit:

debugfs:  quit

Dokumentiere mindestens:

• Gerät, Partition oder Image und den bestätigten Dateisystemtyp,
• UUID, Blockgröße, Mount-Status und Fehlerstatus,
• verwendete Befehle und vollständige relevante Ausgaben,
• Inode-Nummern, Pfade und Namen bei Wiederherstellungsversuchen,
• Quell- und Zielmedien sowie jeden Schreibzugriff,
• Validierungsergebnisse wie Dateigröße, Prüfsumme und Lesbarkeit.

Nach der Analyse wählst du gegebenenfalls ein geeignetes Prüf- oder Reparaturwerkzeug: Für ext-Dateisysteme kommen je nach Situation fsck oder e2fsck infrage, für XFS xfs_repair. Diese Werkzeuge planst du erst nach Sicherung und nicht als unüberlegten nächsten Schritt.

Zusammenfassung

• Dateisystem-Debugger analysieren interne Metadaten; sie sind keine universellen Reparatur- oder Rettungsprogramme.
• Verwende debugfs ausschließlich für ext2, ext3 und ext4 und xfs_db ausschließlich für XFS.
• Arbeite möglichst mit ausgehängten Dateisystemen oder Images und zunächst nur lesend.
• Mit debugfs untersuchst du unter anderem Superblock-Statistiken, Inodes und gelöschte Inodes.
• Eine Wiederherstellung gelöschter Dateien ist wegen Überschreibung und Fragmentierung nicht garantiert.
• Exportiere gerettete Daten auf ein separates Zielmedium und dokumentiere jeden Schritt.

Als Einstieg in die weitere Arbeit kannst du die Anleitung Dateisysteme Debuggen verwenden.