Debian 8.9 stellt gelöschte, aber gesperrte Dateien wieder her

509
SevenOfNine

Ich lief aus Versehen rm -R / home /. Mein Homefolder enthielt mehrere Festplatten mit virtuellen Maschinen, die zu diesem Zeitpunkt verwendet wurden. Ich habe auch den Fehler bekommen, dass einige Dateien nicht gelöscht werden konnten. Ich kann jedoch nicht mehr auf die Dateien in meinem Ordner / home / zugreifen.

Auf der Suche nach einer Lösung fand ich heraus, dass ich versuchen könnte, die Dateien mit cp / proc / PID / fd / 12 / target / wiederherzustellen.

Jetzt bin ich etwas verwirrt - da die virtuelle Maschine noch arbeitet, schreibt sie wahrscheinlich auf die Festplatte, die ich wiederherzustellen versuche.

Erhalte ich Inkonsistenzen bei diesen Festplatten? Oder hast du vielleicht noch einen Hinweis?

Ich freue mich über jede Hilfe!

Vielen Dank!

0
Nein, die angegebene Methode sollte file sein: Auf POSIX-Systemen gilt ein geöffneter Dateideskriptor als Referenz (Link) auf die Datei, sodass der von dieser Datei belegte Speicherplatz im Dateisystem intakt bleibt. Es hat nur keine Namen im Dateisystem selbst, um darauf zuzugreifen. kostix vor 6 Jahren 1
Sie könnten einen zweiten Verweis auf die namenlose Datei öffnen (z. B. `sleep 99999 </ proc / PID / fd / 12 &`), um das Löschen zu vermeiden, und anschließend die VM einfrieren oder stoppen, um sicherzustellen, dass die cp-Sicherung nicht inkonsistent ist . Wenn Sie die VM anhalten, ist natürlich kein Fehler zulässig nach (und vor: in dem Befehl, der zum Speichern einer Referenz verwendet wird). A.B vor 6 Jahren 1
Vielen Dank für diesen tollen Rat! Ich habe einige VMs ohne die zweite Referenz und das Aussetzen und einige mit der von Ihnen beschriebenen Methode kopiert. Beide Methoden funktionierten gut, obwohl einige Maschinen beim Booten mithilfe des Journals einige Blöcke wiederherstellen mussten. Wahrscheinlich, weil während des Kopierens der Datei Schreibvorgänge ausgeführt wurden. Ich konnte jedoch alle VirtualMachines wiederherstellen. @AB Wenn du magst, kannst du eine Antwort schreiben, damit ich sie als solche kennzeichnen kann. Danke für deine Hilfe!! SevenOfNine vor 6 Jahren 0
Fertig, fügte eine Antwort hinzu, mit einigen Erklärungen A.B vor 6 Jahren 1

1 Antwort auf die Frage

1
A.B

Eine Datei auf einem bestimmten Dateisystem zeichnet sich durch seine referenzierten Indexknoten aka Inode . Solange es Verweise auf diesen Inode gibt, sei es auf der Festplatte (als Dateiname verknüpft, kann mehrmals existieren) oder "im Arbeitsspeicher" (geöffneter Dateideskriptor aka fd, Einhängepunkt, mmaped ...) die Datei und Ihre Daten bleiben auf der Festplatte. Wenn kein Verweis mehr vorhanden ist, wird er wirklich gelöscht und der Speicherplatz wieder freigegeben. Wenn die Plattenreferenz zu 0 wird, auch wenn noch Verweise "im Speicher" vorhanden sind, gibt es keine Möglichkeit, sie mit einem neuen Namen zu verknüpfen, da für den Benutzer keine Kernel-API vorhanden ist, die es beispielsweise erlaubt, einen Inode zu verknüpfen, auf den fd oder das referenzierte Element verweist Inode Wert selbst, es ist nur nach Dateinamen (es sei denn, auf einem angemessenes Dateisystem mit dunklen und gefährlicher Magie : debugfs ln).

Der Linux-Kernel bietet noch einige Möglichkeiten, auf diese Datei mit dem /procPseudo-Dateisystem zuzugreifen . Jede geöffnete Datei in wird als Symlink angezeigt, der auf eine Datei verweist. Der Dateiname ist kosmetische Information (und kann falsch sein, wenn die Datei nicht verknüpft wurde), aber die Datei selbst wird als die eigentliche Datei betrachtet, wie sie vom Kernel gesehen wird./proc/PID/fd/

In diesem Fall ist die als VM-Backend verwendete VM weiterhin vorhanden, solange die VM ausgeführt wird. Sie kann jedoch nicht erneut auf die Festplatte gesetzt werden. Was leicht zu tun ist, ist es mit einem entsprechenden Befehl zu kopieren, zum Beispiel:

cp --sparse=always /proc/PID/fd/12 > backup.

Da die VM läuft, kann dies zu einem inkonsistenten Ergebnis führen: Das Dateisystem (in der Datei) kann sich während des Kopiervorgangs ändern und inkonsistent und beschädigt werden. Sie können also entweder die VM einfrieren, wenn ihr Hypervisor dies zulässt, und die Festplattendatei der VM nicht schließt, wenn sie eingefroren ist, oder fügen Sie der namenlosen Datei eine neue Referenz hinzu und stoppen Sie die VM. Wenn Sie keine Chance ergreifen möchten, fügen Sie die Referenz trotzdem hinzu, bevor Sie sie einfrieren. Jeder Befehl, der die Datei liest und lange genug dauert, ist in Ordnung. Zum Beispiel:

$ sleep 99999 < /proc/PID/fd/12 & [1] 12087

Sie sollten jetzt überprüfen, ob auf /proc/12087/fd/0dieselbe ... (deleted)Datei verwiesen wird.

Die VM kann jetzt eingefroren oder sogar gestoppt werden (kann dann jedoch nicht erneut gestartet werden). Da das Dateisystem nicht mehr aktiv ist, sollte die Sicherung konsistent sein (bei Wiederherstellung des Dateisystem-Journals, wenn sie einfach eingefroren wird). Die Verwendung cpmit der Option --sparse=alwaysscheint eine gute Wahl zu sein, wenn die Festplattendatei der VM "faul" war und meist leer war, um weniger Speicherplatz zu benötigen.

Verwandte Probleme