Produktgrenzen für das Btrfs-Volume
Btrfs: erst die Snapshots, dann alles andere
Wie hole ich gelöschte Dateien von einem Btrfs-Volume zurück?
Kurzantwort
Zuerst über die Snapshots: btrfs subvolume list -s zeigt alle Schnappschüsse, und aus einem Stand vor dem Verlust kopierst du die Datei einfach heraus. Ohne Snapshot hilft copy-on-write, weil alte Blöcke liegen bleiben, bis der Platz neu belegt wird; dann aushängen, ein Abbild ziehen und btrfs restore anwenden. File Recovery Hero liest Btrfs nicht.
Der Befund
Auf einem Linux-Volume mit Btrfs fehlen Dateien, oder das Dateisystem lässt sich nicht mehr einhängen.
Bei Btrfs beginnt die Rettung mit einem Schritt, den kein anderes Linux-Dateisystem so kennt: der Snapshot-Liste. Der Befehl btrfs subvolume list -s zeigt jeden vorhandenen Schnappschuss; findest du dort einen aus der Zeit vor dem Verlust, ist die Datei kein Rettungsfall mehr, sondern eine Kopie, die du aus dem Snapshot-Verzeichnis herausholst. Erst wenn es keinen Snapshot gibt, gilt die gleiche harte Reihenfolge wie überall: aushängen, ein unkomprimiertes Abbild ziehen, und nur noch mit diesem Abbild arbeiten. Lässt sich das Volume gar nicht mehr einhängen, liest btrfs restore es ausdrücklich ohne Reparaturversuch aus — das ist der Weg, nicht btrfs check --repair.
01 / Einordnen
Was wahrscheinlich passiert ist
Kläre zuerst, ob überhaupt etwas verloren ist. Ein Volume, das nicht einhängt, ist bei Btrfs häufig ein Baum, dessen jüngste Wurzel unbrauchbar ist; ein rein lesender Einhängeversuch mit -o ro,rescue=usebackuproot greift dann auf eine ältere Wurzel zurück, ohne zu schreiben. Meldet das System dagegen Prüfsummenfehler, ist das eine gute Nachricht in schlechter Verpackung: Btrfs sagt dir damit genau, welcher Block beschädigt ist, statt dir stillschweigend falsche Daten zu liefern. Auf einem gespiegelten Profil holt es sich die heile Kopie selbst.
Btrfs arbeitet nach dem Prinzip copy-on-write: Ein geänderter Block wird an neuer Stelle geschrieben, und erst danach zeigt der Baum darauf. Deshalb bleibt die vorherige Fassung physisch liegen, solange der Platz nicht neu vergeben wurde — und deshalb sind Snapshots hier billig und verbreitet. Genau dieses Verhalten macht aber auch die Blindsuche nach Dateisignaturen schwierig: Eine große Datei liegt am Ende über viele, weit auseinanderliegende Auszüge verteilt, und ein Programm ohne Btrfs-Kenntnis setzt sie nicht wieder korrekt zusammen.
Prüfe den letzten Pfad, Zielordner und Backups. Schreibe nichts auf den betroffenen Datenträger.
02 / Sofortmaßnahmen
So schützt du die verbliebenen Daten
- 1
Sieh zuerst mit
btrfs subvolume list -snach vorhandenen Snapshots, bevor du irgendein Rettungsprogramm startest. - 2
Hänge das betroffene Volume aus; ist das nicht möglich, hänge es mit
-o roerneut nur lesend ein. - 3
Erstelle mit
ddoderddrescueein unkomprimiertes Abbild auf ein anderes physisches Laufwerk und arbeite nur damit. - 4
Speichere jeden Fund auf ein drittes Ziel, nie zurück in das Volume und nie in das Abbild hinein.
Führe btrfs check --repair nicht aus, solange du die Daten noch brauchst — die Reparatur schreibt in die Metadatenbäume und hat schon vollständige Dateisysteme unbrauchbar gemacht. Hänge das Volume nicht schreibend ein, auch nicht „nur kurz zum Nachsehen“, denn schon das Einhängen kann eine Bereinigung anstoßen. Lösche keine Snapshots, um Platz zu schaffen; sie sind hier möglicherweise deine einzige vollständige Kopie.
03 / Scan
Die Methode muss zur Quelle passen
Für stabil lesbares exFAT, NTFS und FAT16/FAT32 oder unkomprimierte IMG-, DD-, RAW- und BIN-Images.
Die Formatstruktur wird geprüft. Unbestätigte Exporte tragen .UNVERIFIED.
File Recovery Hero liest Btrfs-Metadaten nicht — weder Subvolumes noch Snapshots noch die Prüfsummenbäume. Die unterstützte Basis sind lesbare exFAT/NTFS/FAT16/FAT32-Datenträger sowie unkomprimierte IMG-, DD-, RAW- und BIN-Images, jeweils ausschließlich lesend. Ein Btrfs-Abbild lässt sich damit auf Signaturen durchsuchen, aber Verzeichnisbaum, Dateinamen und die copy-on-write-Verkettung großer Dateien kommen aus den Btrfs-Metadaten und bleiben dabei außen vor. Physische Defekte und verschlüsselte Datenträger gehören ebenfalls nicht dazu.
04 / Ergebnis
Woran du eine brauchbare Wiederherstellung erkennst
Öffne jede zurückgeholte Datei vollständig und vergleiche die Größe mit dem Erwarteten. Aus einem Snapshot geholte Dateien sind der sichere Teil — dort stimmt die Struktur. Alles, was aus einer Signatursuche im Abbild stammt, trägt weder Namen noch Ordner mehr und kann bei großen Dateien in der Mitte aus fremden Blöcken bestehen; lies deshalb bis zum Dateiende.
Bewahre die Quelle bis zu zwei geprüften Kopien auf. Eine Vorschau allein genügt nicht.
Quellen und technische Hinweise
Häufige Fragen
Fragen zu diesem Fall
Kann das Btrfs-Volume in diesem Fall gerettet werden?+
Bei Btrfs beginnt die Rettung mit einem Schritt, den kein anderes Linux-Dateisystem so kennt: der Snapshot-Liste. Der Befehl btrfs subvolume list -s zeigt jeden vorhandenen Schnappschuss; findest du dort einen aus der Zeit vor dem Verlust, ist die Datei kein Rettungsfall mehr, sondern eine Kopie, die du aus dem Snapshot-Verzeichnis herausholst. Erst wenn es keinen Snapshot gibt, gilt die gleiche harte Reihenfolge wie überall: aushängen, ein unkomprimiertes Abbild ziehen, und nur noch mit diesem Abbild arbeiten. Lässt sich das Volume gar nicht mehr einhängen, liest btrfs restore es ausdrücklich ohne Reparaturversuch aus — das ist der Weg, nicht btrfs check --repair. Entscheidend bleibt, was auf der Quelle noch lesbar ist.
Was sollte ich vor dem Scan vermeiden?+
Führe btrfs check --repair nicht aus, solange du die Daten noch brauchst — die Reparatur schreibt in die Metadatenbäume und hat schon vollständige Dateisysteme unbrauchbar gemacht.
Wird auf meine Speicherkarte geschrieben?+
Deine Speicherkarte wird nur gelesen. Nichts wird darauf gespeichert.
Woran erkenne ich ein vollständiges Ergebnis?+
Öffne jede zurückgeholte Datei vollständig und vergleiche die Größe mit dem Erwarteten.