Dateien nach rm -rf auf ext4 wiederherstellen

Was in den ersten sechzig Sekunden zu tun ist

Zwei Dinge entscheiden darüber, ob Sie mit rm -rf gelöschte Dateien wiederherstellen können. Beide müssen geschehen, bevor Sie eine Suchmaschine öffnen. Beenden Sie alle Schreibvorgänge auf diesem Dateisystem. Nehmen Sie es anschließend außer Betrieb, indem Sie es aushängen oder schreibgeschützt erneut einhängen.

rm löscht nichts. Der Verzeichniseintrag wird entfernt. Danach markiert das System den Inode und die Datenblöcke der Datei als frei. Die Bytes befinden sich weiterhin auf dem Gerät. Sie bleiben dort, bis der Block-Allocator diese Blöcke einem anderen Zweck zuweist und neue Daten darauf schreibt. In jeder Sekunde, in der das Dateisystem eingehängt und aktiv ist, schreibt ein Daemon eine Logzeile oder eine Datenbank eine Seite. Jeder dieser Schreibvorgänge kann auf die Blöcke zugreifen, die Sie wiederherstellen möchten.

Die ersten Befehle müssen daher Schreibvorgänge stoppen. Sie dürfen nicht zuerst Dateien wiederherstellen.

sudo systemctl stop nginx postgresql
sudo umount /mnt/data

Wenn umount mit umount: /mnt/data: target is busy. antwortet, ermitteln Sie, welcher Prozess das Dateisystem geöffnet hält.

sudo fuser -vm /mnt/data
sudo lsof +D /mnt/data

Wenn Sie es nicht freigeben können, hängen Sie es stattdessen schreibgeschützt erneut ein. Ein schreibgeschütztes Mount verhindert neue Speicherzuweisungen. Das deckt den wichtigsten Teil der erforderlichen Maßnahmen ab.

sudo mount -o remount,ro /mnt/data

Wenn sich der gelöschte Pfad auf dem Root-Dateisystem befand, ist das schwieriger. sudo mount -o remount,ro / schlägt normalerweise mit mount: /: cannot remount /dev/vda1 read-only. fehl, weil laufende Prozesse Dateien zum Schreiben geöffnet halten und der Kernel sie nicht zwangsweise schließen wird. Auf einem VPS ist der praktische Weg der Rescue- oder Recovery-Modus Ihres Providers. Dabei wird ein separates Live-System gestartet, an das Ihre Festplatte angeschlossen, aber nicht eingehängt ist. Jeder folgende Befehl läuft dann auf einem Gerät, auf das kein Prozess schreibt.

Für den gesamten Leitfaden gilt eine Regel: Schreiben Sie wiederhergestellte Dateien, ein Festplatten-Image oder ein neu installiertes Tool niemals auf das Dateisystem, von dem Sie Daten wiederherstellen. Schließen Sie ein zweites Volume an oder senden Sie die Ausgabe über SSH an einen anderen Rechner.

Warum die Wiederherstellung nach rm -rf auf ext4 meist aussichtslos ist

Setzen Sie Ihre Erwartungen, bevor Sie irgendetwas installieren. Prüfen Sie zunächst, mit welchem Dateisystem Sie arbeiten:

lsblk -f

Auf ext4, dem Standard bei nahezu jedem VPS-Image, ist der Speicherort der Dateidaten im Inode als Extent-Baum hinterlegt. Ein Extent ist ein Datensatz, der angibt, dass der logische Block N dieser Datei am physischen Block M beginnt und sich über L Blöcke erstreckt. Kleine Dateien speichern bis zu vier dieser Datensätze direkt im Inode. Größere Dateien verweisen auf zusätzliche Blöcke, die den restlichen Baum enthalten.

Wenn der letzte Link auf eine Datei entfernt wird, durchläuft ext4 diesen Baum, gibt jeden Extent an den Block-Allocator zurück und löscht den Baum aus dem Inode. Der Inode wird anschließend als frei markiert und mit einer Löschzeit versehen. Die Daten selbst bleiben unverändert. Die einzige Information über ihren Speicherort wurde jedoch gelöscht.

Das unterscheidet ext4 von ext3. Bei ext3 enthielt ein gelöschter Inode noch genügend Informationen, damit ein Tool wie ext3grep ihm folgen konnte. Auch auf ext4 können Sie gelöschte Inodes auflisten:

sudo debugfs -R lsdel /dev/vdb1

debugfs öffnet das Gerät schreibgeschützt, sofern Sie nicht -w übergeben. Auf einem nicht eingehängten Gerät ist dieser Vorgang daher sicher und kostet nichts. Die Inodes werden aufgelistet. Beim Dump eines Inodes endet die Wiederherstellung jedoch, weil die Blockzuordnung, die dieser Inode früher enthielt, gelöscht wurde. dump kann ihr daher nicht folgen.

Zwei Tools versuchen, dieses Problem durch das Lesen des Journals zu umgehen. Das Journal ist ein Ring mit fester Größe, den ext4 verwendet, um die Metadaten nach einem Absturz konsistent zu halten. Es kann noch eine ältere Kopie des Inodes aus der Zeit vor dem Löschen enthalten. extundelete und ext4magic durchsuchen beide das Journal. Prüfen Sie, mit welcher Größe Sie arbeiten:

sudo dumpe2fs -h /dev/vdb1 | grep -i journal

Das Journal enthält ausschließlich Metadaten und ist klein. Daher wird es durch gewöhnliche Schreibvorgänge schnell überschrieben. Auf einem laufenden Server beträgt das Zeitfenster, in dem der Inode aus der Zeit vor dem Löschen noch vorhanden ist, nur wenige Minuten. Keines der beiden Tools wird aktiv gepflegt, und keines ist in jeder Distribution als Paket verfügbar. Betrachten Sie beide als wenig aussichtsreich. Führen Sie sie auf einem nicht eingehängten Gerät oder einem Disk-Image aus. Stellen Sie sich darauf ein, dass sie nichts zurückgeben.

Wenn lsblk -f xfs meldet, ist die Situation nicht besser, weil es auch für XFS keine unterstützte Wiederherstellung gelöschter Dateien gibt. Die Reihenfolge der folgenden Optionen ändert daran nichts.

Ist die Datei in einem laufenden Prozess noch geöffnet?

Dies ist die Wiederherstellungsmethode auf dieser Seite mit guten Erfolgsaussichten. Deshalb sollten Sie den Dienst, der die Datei verwendet hat, nicht neu starten.

Eine Datei ist erst dann vollständig gelöscht, wenn zwei Zähler den Wert null erreicht haben: die Anzahl der Verzeichniseinträge, die auf ihren Inode verweisen, und die Anzahl der geöffneten Dateideskriptoren. rm setzt den ersten Zähler auf null. Wenn ein Prozess die Datei noch geöffnet hält, ist der zweite Zähler nicht null. Der Inode und seine Blöcke sind dann weiterhin belegt, und die Daten können noch gelesen werden.

Suchen Sie nach geöffneten Dateien, deren Link-Anzahl auf null gefallen ist:

sudo lsof +L1

+L1 bedeutet, geöffnete Dateien mit einer Link-Anzahl unter 1 aufzulisten. Jeder Treffer zeigt den Prozess, die Nummer des Dateideskriptors, ein NLINK von 0 und einen Pfad, der mit (deleted) endet. Übernehmen Sie die PID und die Dateideskriptor-Nummer für /proc:

sudo ls -l /proc/1234/fd

Ein Eintrag sieht beispielsweise wie 3 -> /var/log/app/events.log (deleted) aus. Über diesen Link ist der Zugriff auf die Daten weiterhin möglich. Kopieren Sie die Datei in ein anderes Dateisystem:

sudo cp /proc/1234/fd/3 /mnt/rescue/events.log

Verwenden Sie cp, nicht mv. Wenn Sie /proc/1234/fd/3 öffnen, erhalten Sie ein neues Handle für denselben Inode, beginnend bei Offset null. Dadurch erhalten Sie die gesamte Datei und nicht nur den Teil nach der aktuellen Position des Schreibprozesses.

Dabei sind zwei Einschränkungen wichtig. Ein gelöschter Verzeichnisbaum kann auf diese Weise nicht wiederhergestellt werden, weil nur die einzelnen Dateien weiterhin gehalten werden, die ein Prozess geöffnet hatte. Eine Datenbankdatei, die während eines Schreibvorgangs der Datenbank-Engine kopiert wurde, ist außerdem nur konsistent im Sinne einer Wiederherstellung nach einem Absturz. Planen Sie daher, darauf die Wiederherstellung der Engine auszuführen, statt die Kopie als fehlerfrei zu behandeln. Einträge, bei denen lsof anstelle einer Dateideskriptor-Nummer mem anzeigt, sind per Memory Mapping eingebunden. Für diese gibt es keinen /proc/<pid>/fd-Eintrag, aus dem Sie kopieren können.

Gibt es einen Snapshot auf btrfs, ZFS oder LVM?

Wenn das Dateisystem Snapshots unterstützt, befinden sich die gelöschten Dateien möglicherweise unverändert in einem davon. Das hilft nur, wenn vor dem Löschen bereits ein Snapshot vorhanden war. Ein Snapshot, den Sie jetzt erstellen, kann die Vergangenheit nicht wiederherstellen.

btrfs speichert Snapshots als Subvolumes:

sudo btrfs subvolume list /

Durchsuchen Sie den Snapshot und kopieren Sie die benötigten Pfade mit cp -a heraus. Kopieren Sie bevorzugt einzelne Pfade, statt ein gesamtes Subvolume zurückzusetzen. Bei einem Rollback werden auch alle Daten verworfen, die seit der Erstellung des Snapshots geschrieben wurden.

ZFS stellt jeden Snapshot als schreibgeschütztes Verzeichnis bereit:

zfs list -t snapshot
ls /tank/data/.zfs/snapshot/

Das Verzeichnis .zfs ist verborgen und erscheint daher nicht in einer einfachen Ausgabe von ls im Root des Datasets. Sie können es jedoch über seinen Namen öffnen. Kopieren Sie die Dateien von dort heraus. zfs rollback setzt das gesamte Dataset zurück und löscht jeden Snapshot, der neuer ist als der angegebene. Verwenden Sie diesen Befehl daher nur als letzten Ausweg.

LVM-Snapshots sind Copy-on-Write-Volumes mit fester Größe:

sudo lvs
sudo mount -o ro /dev/vg0/data-snap /mnt/snap

Hängen Sie den Snapshot schreibgeschützt ein und kopieren Sie die benötigten Daten heraus. Prüfen Sie lvs, bevor Sie dem Snapshot vertrauen. Wenn ein LVM-Snapshot den zugewiesenen Speicherplatz vollständig belegt, wird er vom Kernel ungültig gemacht. Danach sind seine Inhalte verloren.

Ein Snapshot ist kein Backup. Er liegt auf derselben Festplatte oder im selben Pool wie das Original und ist daher denselben Ausfällen ausgesetzt. Ein Snapshot eignet sich sehr gut, um einen Fehler von vor zwei Minuten rückgängig zu machen. Genau dafür wird er hier verwendet.

Carving mit PhotoRec gegen ein Image, niemals gegen den Live-Datenträger

Wenn nichts davon zutrifft, bleibt nur noch Carving: Das Raw-Gerät wird nach Byte-Mustern durchsucht, die den Beginn eines bekannten Dateityps kennzeichnen. Anschließend wird alles geschrieben, was darauf folgt. Carving liest nur Dateidaten. Dateinamen, Verzeichnisstruktur, Zeitstempel und Eigentümerinformationen sind Dateisystem-Metadaten. Genau diese Metadaten hat rm zerstört. Sie lassen sich daher nicht wiederherstellen. Sie erhalten Dateien mit Namen wie f0384512.jpg in einem nummerierten Ausgabeverzeichnis und müssen sie manuell sortieren.

Zwei Regeln entscheiden darüber, ob dieses Verfahren überhaupt funktioniert.

Erstens müssen Sie den Datenträger als Image sichern, bevor Sie ein anderes Tool darauf ansetzen. Unter Debian und Ubuntu heißt das Paket gddrescue, und die darin installierte Binärdatei heißt ddrescue.

sudo apt update && sudo apt install -y gddrescue testdisk
sudo ddrescue -n /dev/vdb1 /mnt/rescue/vdb1.img /mnt/rescue/vdb1.map

/mnt/rescue muss sich auf einem anderen Gerät befinden und mindestens so viel freien Speicher haben, wie die Partition groß ist. lsblk -b gibt die exakten Größen in Bytes aus. Die Map-Datei ermöglicht es, eine unterbrochene Kopie fortzusetzen, statt von vorn zu beginnen. Sobald das Image vorliegt, können Sie später ein zweites Tool gegen exakt dieselben Bytes einsetzen. Das ist nicht möglich, wenn das erste Tool den Datenträger überschrieben hat.

Zweitens müssen Sie das Recovery-Tool auf die Image-Datei verweisen.

sudo photorec /d /mnt/rescue/recup /mnt/rescue/vdb1.img

photorec öffnet ein textbasiertes Menü. Wählen Sie die Partition, anschließend den Dateisystemtyp, dann die zu suchenden Dateisignaturen und zuletzt das Zielverzeichnis. Beschränken Sie die Liste der Signaturen vor dem Start auf die Dateitypen, die tatsächlich verloren gegangen sind. Die Standardliste findet alles und erzeugt zehntausende Fragmente, die Sie anschließend durchsuchen müssen.

testdisk aus demselben Paket verfügt über eine eigene Undelete-Funktion. Sie unterstützt jedoch nur FAT, exFAT, NTFS und ext2. Bei ext4 bleibt damit photorec.

Rechnen Sie damit, dass fragmentierte Dateien beschädigt wiederhergestellt werden. Carving geht davon aus, dass die Blöcke einer Datei zusammenhängend gespeichert sind. Hat der Allocator eine Datei über den Datenträger verteilt, wird sie entweder falsch zusammengesetzt oder gar nicht gefunden. Mediendateien lassen sich meist relativ zuverlässig carven, weil sie markante Header besitzen. Reiner Text, Konfigurationsdateien und Quellcode lassen sich schlecht carven, weil kein Byte-Muster den Beginn eines Shell-Skripts kennzeichnet.

Das Leerzeichen: Wie der falsche Pfad gelöscht wurde

Fast jeder rm -rf-Unfall ist ein Shell-Problem. rm erhält eine Liste von Pfaden und entfernt sie nacheinander. Der Befehl erkennt nicht, was Sie beabsichtigt haben.

Der klassische Fall ist ein einzelnes Leerzeichen:

rm -rf /home/deploy/app /old
rm -rf /home/deploy/app/old

Die erste Zeile enthält zwei Argumente. Sie löscht zuerst die Anwendung und anschließend /old. Wenn /old nicht existiert, gibt rm überhaupt nichts aus, weil -f den Fehler für die fehlende Datei unterdrückt. Keine Ausgabe ist keine Bestätigung.

Das zweite Muster ist eine nicht in Anführungszeichen gesetzte Variable, deren Wert ein Leerzeichen enthält:

dir="/srv/my app"
rm -rf $dir

Die Shell teilt den Wert an Whitespace auf. Dadurch erhält rm /srv/my und app als zwei separate Pfade. In der Schreibweise rm -rf "$dir" ist es ein einzelner Pfad.

Das dritte Muster ist eine leere Variable. Ursache ist meist, dass der Befehl, der sie hätte befüllen sollen, fehlgeschlagen ist:

rm -rf "$TARGET"/*

Wenn TARGET nicht gesetzt ist, wird daraus rm -rf /*. GNU rm lehnt die unveränderte Form ab: rm -rf / gibt rm: it is dangerous to operate recursively on '/' aus und beendet sich. Die Glob-Form bietet diesen Schutz nicht. Die Shell ersetzt /* durch eine Liste tatsächlich vorhandener Pfade der obersten Ebene, bevor rm überhaupt ausgeführt wird. / gehört nicht zu dieser Liste, daher wird die Abfrage nie ausgelöst.

Gewohnheiten, die den nächsten Fehler verhindern

• Setzen Sie jede Variable, die als Pfad verwendet wird, in Anführungszeichen. Schreiben Sie jedes Mal "$dir", auch innerhalb von Tests und Schleifen.
• Brechen Sie bei leeren Werten ab. rm -rf "${TARGET:?TARGET is not set}"/* beendet die Shell mit Ihrer Meldung, bevor rm startet, wenn TARGET nicht gesetzt oder leer ist. Setzen Sie set -euo pipefail an den Anfang jedes Skripts, das Dateien löscht.
• Fügen Sie --one-file-system hinzu. Damit weist rm an, Verzeichnisse zu überspringen, die sich auf einem anderen Dateisystem als das angegebene Argument befinden. Dadurch kann ein rekursiver Löschvorgang nicht in ein eingebundenes Backup-Volume oder einen Bind-Mount wechseln.
• Löschen Sie nicht als root. Ein Dienstkonto kann nur Dateien und Verzeichnisse löschen, deren Eigentümer es ist. Genau darauf basiert der Betrieb jedes Dienstes unter einem eigenen Benutzer ohne privilegierte Rechte. Wenn Sie nicht wissen, auf welche Pfade ein bestimmtes Konto zugreifen kann, beantwortet das Lesen der Berechtigungsbits in einer ls-Ausgabe die Frage mit einem Befehl.
• Geben Sie die Liste aus, bevor Sie darauf arbeiten. Erstellen Sie in einem Skript die Pfade, printf '%s\n' sie, prüfen Sie die Ausgabe und löschen Sie die Pfade erst in einem zweiten Durchlauf.
• Halten Sie einen Befehl zum Verschieben in den Papierkorb bereit. sudo apt install trash-cli bietet Ihnen trash-put, trash-list, trash-restore und trash-empty. Gelöschte Dateien werden nach ~/.local/share/Trash verschoben, und trash-empty 30 entfernt alles, was älter als dreißig Tage ist.

rm auf trash-put zu setzen, klingt nach dem naheliegenden nächsten Schritt. Es ist jedoch eine Falle. Der Alias führt zu einem Reflex, der auf dem nächsten Server ohne diesen Alias scheitert. Außerdem gelten Aliase nicht innerhalb von Skripten. Dort entstehen die kostspieligsten Fehler. Geben Sie stattdessen bewusst trash-put ein.

Die einzige Wiederherstellung, die immer funktioniert

Alles oben ist eine Möglichkeit. Ein Backup ist keine Möglichkeit.

Zwei Dinge machen ein Backup verlässlich. Es läuft nach einem Zeitplan, ohne dass Sie daran denken müssen. Außerdem haben Sie mindestens einmal daraus wiederhergestellt. Ein Repository, aus dem noch nie wiederhergestellt wurde, beruht auf Vertrauen. Die Fehler, die es unbrauchbar machen – etwa ein falscher Pfad in der Include-Liste oder ein Repository-Passwort, das niemand dokumentiert hat –, zeigen sich erst an dem Tag, an dem Sie es benötigen.

Mit restic besteht eine Wiederherstellung aus zwei Befehlen.

restic -r /srv/restic-repo snapshots
restic -r /srv/restic-repo restore latest --target /mnt/rescue --include /srv/appdata

Stellen Sie die Daten in einem leeren Verzeichnis wieder her, nicht über dem aktiven Pfad. So können Sie beide Verzeichnisse vergleichen, bevor Daten an ihren endgültigen Platz verschoben werden. restic-Backups auf einem VPS einrichten beschreibt die Einrichtung des Repositorys und des systemd-Timers, der das Backup ausführt.

Mit Borg:

borg list /srv/borg-repo
borg extract /srv/borg-repo::daily-2026-08-08 srv/appdata

Pfade in einem Borg-Archiv werden ohne den führenden Schrägstrich gespeichert. Daher findet srv/appdata passende Einträge, während /srv/appdata nichts findet. borg extract schreibt in das aktuelle Arbeitsverzeichnis. Verwenden Sie daher zuerst cd für ein temporäres Verzeichnis.

Wenn Sie sich noch nicht zwischen den beiden Tools entschieden haben, behandelt der Vergleich von restic und Borg Deduplizierung und Append-only-Repositorys. Diese Eigenschaft verhindert, dass ein kompromittierter Server seine eigene Backup-Historie löscht. Beide Tools sind geeignet. Die falsche Entscheidung ist, keines davon auszuführen.

Bei einem neuen Server lässt sich dies am günstigsten einrichten, bevor sich darauf Daten befinden, deren Verlust problematisch wäre. Die ersten zehn Minuten auf einem neuen VPS ist der richtige Zeitpunkt dafür, zusammen mit der SSH- und Firewall-Konfiguration.

Legen Sie anschließend einen wiederkehrenden Kalendereintrag an: Stellen Sie jeden Monat ein Verzeichnis aus dem Repository in /tmp wieder her und lesen Sie die Dateien. Diese eine Gewohnheit ist mehr wert als jedes Tool auf dieser Seite.

FAQ

Kann ich eine Datei auf ext4 wiederherstellen?

In der Regel nicht. Wenn der letzte Link auf eine Datei entfernt wird, löscht ext4 den Extent-Baum aus dem Inode. Danach ist auf dem Datenträger nicht mehr verzeichnet, wo die Daten lagen. extundelete und ext4magic durchsuchen das ext4-Journal nach einer älteren Kopie dieses Inodes. Das hilft nur, wenn die Löschung vor wenigen Minuten erfolgt ist und das Dateisystem seitdem nicht verändert wurde. Beide Projekte werden nicht mehr aktiv gepflegt. Führen Sie eines der beiden Tools nur auf einem nicht eingehängten Gerät oder einem Disk-Image aus, niemals auf einem eingehängten Dateisystem. Prüfen Sie zuerst mit sudo dumpe2fs -h /dev/vdb1 | grep -i journal, worauf Sie arbeiten.

Ein Dienst hat die gelöschte Datei noch geöffnet. Kann ich sie wiederherstellen?

Ja. Das ist der beste Fall. Solange ein Prozess die Datei geöffnet hält, bleiben ihr Inode und ihre Datenblöcke belegt. Die Daten sind daher weiterhin lesbar. Starten Sie den Dienst nicht neu. Beim Schließen des letzten Deskriptors wird die Löschung abgeschlossen. Führen Sie sudo lsof +L1 aus, um geöffnete Dateien mit einer Link-Anzahl von 0 aufzulisten. Notieren Sie die PID und die Dateideskriptor-Nummer. Kopieren Sie die Datei anschließend mit /proc und sudo cp /proc/1234/fd/3 /mnt/rescue/events.log. Schreiben Sie die Kopie in ein anderes Dateisystem. Einträge, bei denen mem anstelle einer Deskriptor-Nummer angezeigt wird, sind speicherabgebildet. Für sie gibt es keinen /proc/<pid>/fd-Pfad, von dem die Datei kopiert werden kann.

Warum sollte ich den Datenträger als Image sichern, statt das Wiederherstellungstool darauf auszuführen?

Weil jedes Tool seine Ausgabe irgendwo schreiben muss. Ein Schreibvorgang in das wiederherzustellende Dateisystem kann freie Blöcke überschreiben, die Ihre Daten noch enthalten. Kopieren Sie die Partition zuerst mit sudo ddrescue -n /dev/vdb1 /mnt/rescue/vdb1.img /mnt/rescue/vdb1.map auf ein anderes Gerät. Verweisen Sie photorec anschließend auf die Image-Datei. Mit dem Image können Sie später ein zweites Tool mit exakt denselben Bytes testen. Das ist nicht mehr möglich, sobald etwas das Original überschrieben hat.

Zerstört rm -rf / weiterhin ein Linux-System?

Der unveränderte Befehl tut das nicht. GNU rm verweigert die Ausführung und gibt rm: it is dangerous to operate recursively on '/' aus. Gefährlich sind Varianten, die auf anderem Weg entstehen. rm -rf "$TARGET"/* wird mit nicht gesetztem TARGET zu rm -rf /* erweitert. Die Shell übergibt rm dann eine Liste realer Verzeichnisse der obersten Ebene. / gehört nicht dazu, daher greift die Schutzmaßnahme nicht. Schreiben Sie stattdessen "${TARGET:?TARGET is not set}". Dann beendet die Shell die Ausführung, bevor rm gestartet wird.

Ist ein Dateisystem-Snapshot ein Backup?

Nein. Ein btrfs- oder ZFS-Snapshot liegt im selben Pool wie die geschützten Daten. Bei einem ausgefallenen Datenträger oder einem zerstörten Pool gehen daher beide verloren. Ein LVM-Snapshot hat zusätzlich eine feste Größe. Sobald er voll ist, macht der Kernel ihn ungültig und sein Inhalt ist verloren. Snapshots eignen sich sehr gut, um eine Löschung von vor zwei Minuten rückgängig zu machen. Für alle anderen Fälle sollten Sie ein Repository auf separater Hardware vorhalten.