Re-Linken gelöschter Dateien

[ViennaAustria]

Hallo!

Ich hab ein ärgerliches Problem: ich habe unabsichtlich ein VMDK (VMware Disk) File gelöscht und natürlich keine aktuelle Sicherung. Die VM läuft aber noch! D.h., das File selbst ist noch nicht gelöscht, wie man auch schnell mit `lsof´ erkennt

host001.selfnet.at:~ 16:15# lsof | grep "vmdk.*deleted"
vmware-vm 4060 vmware 130u REG 9,0 2201092096 11027273 /var/lib/vmware/Virtual Machines/vbrad02.video-broadcast.at/vbrad02.video-broadcast.at.vmdk (deleted)

oder im /proc Dateisystem

host001.selfnet.at:/proc/4060/fd 16:16# l -i | grep deleted
266109038 lrwx------ 1 root root 64 Jun 12 16:14 110 -> /var/lib/vmware/Virtual Machines/vbrad02.video-broadcast.at/564dd0c5-92a7-08fe-af02-141ae27a7b73.vmem (deleted)
266109058 lrwx------ 1 root root 64 Jun 12 16:14 130 -> /var/lib/vmware/Virtual Machines/vbrad02.video-broadcast.at/vbrad02.video-broadcast.at.vmdk (deleted)
266108945 lrwx------ 1 root root 64 Jun 12 16:14 17 -> /var/lib/vmware/Virtual Machines/vbrad02.video-broadcast.at/vmware.log (deleted)
266108985 lrwx------ 1 root root 64 Jun 12 16:14 57 -> /tmp/vmware-vmware/ram0 (deleted)

Ich weiss also, dass die Daten im Inode 266109058 liegen. Doch wie kann ich für den wieder einen Verzeichniseintrag machen? Sonst sind die Daten futsch, sobald ich die VM beende, weil der RefCount vom Inode dann ja auf 0 geht! :eek:

Mit `debugfs´ konnte ich kein Ergebnis produzieren, denn das kann anscheinend mit gelöschten Inodes auch nicht umgehen:

debugfs: ln <266109058> /tmp/vbrad02.video-broadcast.at.vmdk
<266109058>: Illegal inode number while reading inode 269582466
(/tmp und /var/lib/vmware/Virtual Machines/vbrad02.video-broadcast.at liegen am selben Root-FS; daran kann's also nicht gelegen haben)

Ausserdem würde es vermutlich nicht viel Nützen, denn lt. debugfs Manpage wird damit der RefCount vom Inode nicht inkrementiert, bliebe damit auf 1 und das File würde trotzdem beim Beenden der VM von der Platet entfernt werden.

Hat jemand eine Idee oder zumindest einen Ansatz?

Danke & liebe Grüsse,
Thomas


P.S.: es handelt sich bei meinem Problem nicht um eines mit VMware (dewegen auch nicht dort gepostet), sondern möchte ich allgemein herausfinden, ob/wie man eine gelöschte Datei wieder ins Dateisystem zurück linken kann, wenn sie noch von einem Prozess geöffnet und somit noch nicht physisch gelöscht sind.

[marce]

zur eigentlichen Frage fällt mir spontan nichts ein - aber evtl. ginge es, wenn Du unter vmware einen Snapshot erstellst?

[ViennaAustria]

Hallo!

zur eigentlichen Frage fällt mir spontan nichts ein - aber evtl. ginge es, wenn Du unter vmware einen Snapshot erstellst?

Das wird eher nicht funktionieren, denn dann legt VMware ja eine neue Datei an, in welcher es ab diesem Zeitpunkt alle Änderungen im Dateisystem speichert. Damit fehlt mir noch immer der Inhalt der "restlichen" virtuellen Festplatte.

Ich hab ja bei meiner Blödheit zwei VMs vernichtet (das hab ich bisher verschwiegen). Die eine habe ich damit gerettet, in dem ich mich per Netzwerk in die ja noch laufende Linux Maschine eingelogt habe, alle Serverprozesse (bis auf den sshd) beendet habe und dann mittels tar und netcat alle Files in eine neu gebaute VM kopiert habe, der ich dann nur noch einen neuen Bootloader verpassen musste.

Das ist eine machbare Lösung, wenn man VMDK Files von laufenden Linux Gastsystemen vernichtet - aber ich will hier ja eine Grundsatzdiskussion vom Zaun brechen, wie man vorgehen kann, wenn man z.B. ein immer noch offenes File eines SQL/Web/...-Serverdienstes löscht. Ich denke mir, dass muss doch irgendwie gehen! Ist ja schliesslich Linux und nicht Windoof... ;)

servus,
Thomas

[Sidolin]

die liegen alle irgendwo in /proc. davon halt kopieren oder anderweitig sichern.

[ViennaAustria]

die liegen alle irgendwo in /proc. davon halt kopieren oder anderweitig sichern.

Kopieren von /proc/<pid>/fd/<n> geht grundsätzlich. Blöd dabei ist, dass ich ja eine offene Date eines laufenden Prozesses kopiere. Im Falle einer VMDK Datei also ein offenes Dateisystem! Das ist nicht gut.

Im Zweifelsfall sind Kopien offener Dateien natürlich besser, als gar keine Kopien. Aber eine tolle Lösung ist das nicht.


Aaaaber, Dein Hinweis hat mich zur Lösung gebracht! :D

Ich Dumpfbacke habe dem debugfs den falschen Inode gegeben. Die Inodes, die ich mit `l -i /proc/<pid>/fd´ lese, sind ja Inodes von den SymLinks im /proc Dateisystem und nicht die vom Root-Dateisystem!!! Ganz klar, dass debugfs damit nicht glücklich wird...

Ich hab's nochmal versucht mit dem Inode 11027273, den mir lsof gegeben hat und damit hat es auch sofort funktioniert:

host001.selfnet.at:~ 16:43# debugfs -w /dev/md0
debugfs 1.39 (29-May-2006)
debugfs: ln <11027273> /tmp/vbrad02.video-broadcast.at.vmdk
debugfs: quit
Blieb nur noch das Problem mit dem RefCount - siehe Manpage:

ln filespec dest_file
Create a link named dest_file which is a link to filespec.
Note this does not adjust the inode reference counts.
Das habe ich dadurch gelöst, dass ich einen weiteren Hardlink ganz normal per BASH `ln´ angelegt habe. Damit erstelle ich eine "Sicherheitskopie" und bewirke vor allem RefCount++, womit der Inode nicht mehr entfernt wird, wenn ich den VM Prozess beende - fclose() bewirkt ja RefCount-- und bei RefCount==0 wird ein Inode mitsamt den Daten dahinter vom Dateisystem gelöscht.

Anschliessend habe ich die Maschine rebootet. Zuvor habe ich noch mittels `tune2fs -c 1 -C 1 /dev/md0´ dafür gesorgt, dass beim Reboot ein fsck stattfindet, damit der falsche RefCount vom Inode 11027273 korrigiert wird, was auch bestend geklappt hat.

Yep. Alles wieder im Lot! :D

Nächstesmal werd' ich genauer schauen und mitdenken...

Thomas