Linux Deutsch

Ext-Dateisysteme und XFS mit debugfs und xfs_db untersuchen

Lernen Sie, ext2/ext3/ext4 und XFS sicher mit debugfs und xfs_db zu untersuchen: Superblocks, Inodes, gelöschte Dateien, Risiken und Reparaturwerkzeuge.

Mit speziellen Debug-Werkzeugen lassen sich interne Strukturen eines Linux-Dateisystems untersuchen. Dazu gehören Superblock-Informationen, Inodes, Verzeichniseinträge und Datenblock-Verweise. Für ext2, ext3 und ext4 ist debugfs vorgesehen; für XFS verwenden Sie xfs_db.

Diese Werkzeuge sind keine universellen Reparaturprogramme. Sie machen Metadaten sichtbar und helfen bei der Diagnose. Reparaturen gehören zu e2fsck beziehungsweise xfs_repair. Eine Datenwiederherstellung ist ein eigenes, besonders vorsichtiges Anwendungsgebiet.

Grundbegriffe und Zweck des Dateisystem-Debuggings

Ein Dateisystem organisiert Dateien, Verzeichnisse, Metadaten und Datenblöcke auf einem Speichermedium. Ein Blockgerät ist ein blockweise angesprochener Speicherbereich, zum Beispiel /dev/sdb1.

• Der Superblock enthält zentrale Angaben wie Größe, Blockgröße, Zustand und aktivierte Dateisystemmerkmale.
• Ein Inode speichert Metadaten einer Datei, etwa Eigentümer, Rechte, Zeitstempel, Größe und Verweise auf Datenblöcke.
• Ein Verzeichniseintrag verbindet einen Dateinamen mit einer Inode-Nummer.
• Datenblöcke enthalten den eigentlichen Dateiinhalt oder weitere Strukturen zur Blockverwaltung.

Das Debugging beantwortet beispielsweise Fragen wie: Welcher Inode gehört zu einem Pfad? Welche Größe und Zeitstempel sind gespeichert? Welche Dateisystem-Features sind aktiviert? Gibt es Hinweise auf gelöschte Inodes? Es ersetzt weder Backups noch eine forensisch saubere Analyse oder eine reguläre Konsistenzprüfung.

Bei Journaling werden bestimmte Metadatenänderungen protokolliert, damit ein Dateisystem nach einem Absturz konsistenter wieder eingebunden werden kann. Journaling garantiert jedoch keine Wiederherstellung gelöschter oder beschädigter Dateiinhalte.

Werkzeug nach Dateisystem auswählen

Die Werkzeuge sind nicht austauschbar. debugfs erwartet ein passendes ext-Dateisystem, während xfs_db die internen Strukturen von XFS kennt. Ext-Kommandos dürfen nicht einfach auf XFS angewendet werden, und umgekehrt.

Weitere Grundlagen zu Dateisystemen finden Sie unter ext4, XFS, Inodes und Einhängen und Aushängen.

Vorbereitung: Gerät sicher identifizieren

Verwenden Sie niemals einen geratenen Gerätenamen. Zeigen Sie zunächst Typ, UUID, Partitionen und Mountpoints an:

lsblk -f
findmnt
sudo blkid

Angenommen, lsblk -f zeigt, dass /dev/sdb1 ein ext4-Dateisystem enthält. Bestätigen Sie außerdem, ob genau diese Partition eingehängt ist. Ein Dateisystem ist eingehängt, wenn es über einen Mountpoint im Verzeichnisbaum verfügbar ist. Ausgehängt bedeutet, dass es nicht aktiv eingebunden ist.

findmnt /dev/sdb1
sudo umount /dev/sdb1

Der Aushängevorgang funktioniert nur, wenn keine Prozesse Dateien oder Arbeitsverzeichnisse dieser Partition verwenden. Bei System- oder Home-Partitionen benötigen Sie möglicherweise ein Rettungssystem oder einen Wartungsmodus. Root-Rechte sind für den Zugriff auf viele Blockgeräte erforderlich; sie schützen aber nicht vor dem Zugriff auf das falsche Gerät.

debugfs starten und bedienen

debugfs untersucht ext2, ext3 und ext4. Eine interaktive Sitzung starten Sie gegen die zuvor bestätigte Partition:

sudo debugfs /dev/BEISPIELPARTITION

Danach erscheint eine Eingabeaufforderung ähnlich wie debugfs:. Die Befehle dieser Sitzung sind keine normalen Shell-Befehle. Navigation und Pfadangaben beziehen sich auf das geöffnete Dateisystem, nicht automatisch auf Ihr aktuelles Shell-Verzeichnis.

debugfs: help
debugfs: stats
debugfs: quit

help zeigt verfügbare Befehle. Mit quit oder q beenden Sie die Sitzung. Anzeigeoperationen wie stat und stats sind von Befehlen zu unterscheiden, die Metadaten oder Inhalte verändern. Schreibende Funktionen sollten nur auf einer Kopie und mit eindeutigem Ziel verwendet werden.

Für eine einzelne lesende Abfrage kann ein Befehl direkt übergeben werden:

sudo debugfs -R 'stats' /dev/BEISPIELPARTITION

Superblock und Dateisystemstatistiken lesen

Mit stats erhalten Sie zentrale Dateisystemstatistiken. show_super_stats zeigt zusätzliche Informationen zu Superblöcken und Blockgruppen:

sudo debugfs -R 'stats' /dev/BEISPIELPARTITION
sudo debugfs -R 'show_super_stats' /dev/BEISPIELPARTITION

In der Ausgabe sind unter anderem folgende Angaben wichtig:

• Blockgröße: Sie beeinflusst, wie Speicher in Datenblöcke aufgeteilt wird.
• Inode-Anzahl: Sie beschreibt, wie viele Inode-Strukturen das Dateisystem verwalten kann.
• Dateisystemmerkmale: Features zeigen, welche ext-Funktionen aktiviert sind.
• Dateisystemzustand: Der gespeicherte Zustand kann Hinweise darauf geben, ob ein Dateisystem sauber ausgehängt wurde.
• Blockgruppen und freie Blöcke: Diese Angaben helfen, die Speicherorganisation und Auslastung einzuordnen.

Inode- und Dateimetadaten untersuchen

Mit stat lesen Sie den Inode einer vorhandenen Datei über ihren Pfad:

sudo debugfs /dev/BEISPIELPARTITION
debugfs: stat /pfad/zur/datei
debugfs: quit

Die Ausgabe enthält typischerweise die Inode-Nummer, Dateityp, Rechte, Eigentümer, Größe, Zeitstempel und Verweise auf Datenblöcke. Der Dateiname selbst liegt dabei im Verzeichniseintrag. Vereinfacht betrachtet verläuft die Zuordnung so:

1. Ein Verzeichniseintrag ordnet einem Namen eine Inode-Nummer zu.
2. Der Inode beschreibt die Datei und verweist auf ihre Datenblöcke.
3. Die Datenblöcke enthalten den Dateiinhalt.
4. Der Superblock beschreibt die übergeordnete Organisation des Dateisystems.

Ein Inode ist daher nicht dasselbe wie ein Dateiname. Mehrere Namen können beispielsweise über Hard Links auf denselben Inode zeigen. Weitere Grundlagen enthält der Artikel Harte Links.

Gelöschte Dateien auf ext-Dateisystemen

Beim Löschen wird normalerweise zuerst die Zuordnung des Dateinamens im Verzeichnis verändert. Auch der Inode kann als frei markiert werden. Die Datenblöcke bleiben möglicherweise noch eine Zeit lang unverändert, können aber durch neue Dateien oder andere Dateisystemaktivität überschrieben werden.

Stoppen Sie deshalb Schreibzugriffe, bevor Sie nach einer gelöschten Datei suchen. Öffnen Sie ein Image oder ein ausgehängtes Arbeitsmedium und listen Sie mögliche gelöschte Inodes auf:

sudo debugfs /dev/BEISPIELPARTITION
debugfs: list_deleted_inodes

Bewerten Sie mögliche Treffer anhand von Inode-Nummer, Größe, Zeitstempeln und Dateityp. Ein Kandidat ist noch kein Beweis für einen vollständig rekonstruierbaren Dateiinhalt.

Mit undelete können Sie anhand einer Inode-Nummer einen Wiederherstellungsversuch starten:

debugfs: undelete INODE neuer-dateiname

Die genaue Verfügbarkeit und das Ergebnis hängen vom Zustand der Inode- und Blockzuordnungen ab. Überschriebene Daten sind meist nicht rekonstruierbar. Journaling, die Zeit seit dem Löschen und moderne Dateisystemaktivität können die Chancen zusätzlich verringern. Schreiben Sie das Ergebnis niemals auf dasselbe betroffene Dateisystem; verwenden Sie ein separates, beschreibbares Zielmedium.

Dateien mit debugfs schreiben oder herauskopieren

Der Befehl write legt eine externe Quelldatei im geöffneten ext-Dateisystem ab:

debugfs: write /lokale/quelldatei /ziel/datei

Das ist ein Schreibzugriff auf Metadaten und Datenblöcke. Er gehört nicht in eine rein diagnostische Sitzung und kann bei einem beschädigten Dateisystem die Situation verschlimmern. Verwenden Sie ihn nur nach einer Sicherung beziehungsweise auf einer Kopie. Für Wiederherstellungsergebnisse und exportierte Dateien muss das Ziel auf einem anderen Dateisystem liegen.

Wichtige debugfs-Befehle

XFS mit xfs_db untersuchen

XFS ist ein eigenständiges Linux-Dateisystem mit eigenen internen Strukturen. Dafür verwenden Sie xfs_db, nicht debugfs. Identifizieren Sie die XFS-Partition, hängen Sie sie aus und starten Sie anschließend die Sitzung:

sudo xfs_db /dev/BEISPIELPARTITION
xfs_db: help

help zeigt die für die installierte Version verfügbaren Befehle und Kontexte. Die Befehlssprache und das Datenmodell unterscheiden sich von debugfs. Übertragen Sie daher keine ext-Annahmen ungeprüft auf XFS. Beginnen Sie möglichst lesend und offline; schreiben Sie nicht in Strukturen, deren Bedeutung Sie nicht sicher verstehen.

Ein xfs_db-Aufruf mit einem ext-Gerät oder ein debugfs-Aufruf mit einer XFS-Partition führt typischerweise zu einer Fehlermeldung oder unbrauchbaren Ergebnissen. Das ist ein Werkzeugauswahlproblem, nicht automatisch ein Beweis für einen Defekt.

Diagnose, Reparatur und Wiederherstellung unterscheiden

e2fsck ist das vorgesehene Prüf- und Reparaturwerkzeug für ext-Dateisysteme. Eine Prüfung kann beispielsweise so gestartet werden:

sudo e2fsck -f /dev/BEISPIELPARTITION

Für XFS ist xfs_repair vorgesehen. Die Option -n simuliert eine Prüfung ohne Änderungen:

sudo xfs_repair -n /dev/BEISPIELPARTITION

Auch Reparaturprüfungen gehören normalerweise auf ein ausgehängtes Dateisystem und sollten erst nach Sicherung oder Image-Erstellung erfolgen. debugfs und xfs_db sind keine automatischen Reparaturprogramme.

Typische Probleme und ihre Ursachen

debugfs erkennt kein passendes ext-Dateisystem

• Prüfen Sie mit lsblk -f oder blkid, ob das Ziel tatsächlich ext2, ext3 oder ext4 verwendet.
• Kontrollieren Sie, ob Sie die Partition statt des falschen Gesamtgeräts ausgewählt haben.
• Bei beschädigten Metadaten oder I/O-Fehlern sollte zuerst die Datensicherung beziehungsweise Image-Erstellung behandelt werden.

Die Partition lässt sich nicht aushängen

Bestätigen Sie den Mountpoint mit findmnt. Prozesse können Dateien geöffnet haben oder ihr aktuelles Arbeitsverzeichnis dort haben. Bei kritischen Systempartitionen wechseln Sie in einen Wartungsmodus oder starten ein Rettungssystem. Beenden Sie Prozesse nicht unüberlegt, wenn dadurch weitere Datenverluste entstehen könnten.

list_deleted_inodes findet keinen brauchbaren Treffer

Der Inode oder seine Datenblöcke können bereits wiederverwendet worden sein. Auch Zeitablauf, Journaling und weitere Schreibvorgänge verschlechtern die Chancen. Stoppen Sie Schreibzugriffe, erstellen Sie ein Image und setzen Sie die Analyse darauf fort. Eine Wiederherstellung kann nicht garantiert werden.

undelete liefert eine beschädigte Datei

Wahrscheinlich wurden einzelne Datenblöcke überschrieben oder die Blockzuordnung ist nicht mehr vollständig gültig. Sichern und prüfen Sie das Ergebnis auf einem separaten Zielmedium. Arbeiten Sie am Original nicht weiter; bei wichtigen Daten ist eine Analyse des Images mit geeigneten Recovery-Verfahren vorzuziehen.

xfs_db-Ausgaben passen nicht zu debugfs

XFS verwendet andere Strukturen und eine andere Befehlssprache. Nutzen Sie xfs_db: help, arbeiten Sie mit XFS-spezifischer Dokumentation und wenden Sie keine ext-Kommandos oder ext-Reparaturwerkzeuge auf XFS an.

Praktischer Ablauf als Checkliste

1. Definieren Sie das Ziel: Metadaten lesen, Inkonsistenz prüfen oder Daten wiederherstellen.
2. Ermitteln Sie Gerät, Partition, Dateisystemtyp und Mountpoint mit lsblk -f, findmnt und bei Bedarf blkid.
3. Bei Datenverlust oder Hardwareverdacht: Schreibzugriffe stoppen und ein Image erstellen.
4. Hängen Sie die eindeutig identifizierte Partition aus.
5. Wählen Sie debugfs für ext2/ext3/ext4 oder xfs_db für XFS.
6. Beginnen Sie mit lesenden Befehlen wie help, stats, show_super_stats oder stat.
7. Führen Sie Schreib- und Wiederherstellungsbefehle nur auf einer Kopie und mit einem separaten Zielmedium aus.
8. Verwenden Sie für Konsistenzprüfungen die passenden Werkzeuge e2fsck oder xfs_repair.

Prüfungsrelevante Merksätze

• debugfs gehört zu ext2, ext3 und ext4; xfs_db gehört zu XFS.
• Ein Verzeichniseintrag verbindet Dateiname und Inode; der Inode verweist auf Metadaten und Datenblöcke.
• Diagnose ist nicht Reparatur, und Reparatur ist nicht automatisch Datenwiederherstellung.
• Offline und lesend ist das sicherere Ausgangsszenario.
• Gelöschte Dateien sind nur wiederherstellbar, solange relevante Metadaten und Datenblöcke nicht überschrieben wurden.
• Ein Backup oder Image ist vor riskanten Operationen wichtiger als ein weiterer Debug-Befehl.