Relier un fichier supprimé

Parfois, des personnes suppriment des fichiers qu’elles ne devraient pas, un processus de longue durée a toujours le fichier ouvert, et récupérer les données à la volée /proc/<pid>/fd/Nn’est tout simplement pas assez impressionnant. Ce serait assez génial si vous pouviez "annuler" la suppression en exécutant une option magique sur ln qui vous permettrait de vous reconnecter au numéro d'inode (récupéré via lsof).

Je ne trouve aucun outil Linux pour le faire, le moins avec Google rapide.

Qu'est-ce que tu as, serverfault?

EDIT1: La raison pour laquelle le fichier /proc/<pid>/fd/Nn'est pas assez impressionnant est parce que le processus qui a toujours le fichier ouvert est encore en train de l'écrire. Une suppression supprime la référence à l'inode de l'espace de noms du système de fichiers. Ce que je veux, c'est un moyen de recréer la référence.

EDIT2: 'debugfs ln' fonctionne, mais le risque est trop élevé car il bloque les données brutes du système de fichiers. Le fichier récupéré est également fou incohérent. Le nombre de liens est égal à zéro et je ne peux pas y ajouter de liens. Je suis pire de cette façon puisque je peux simplement utiliser /proc/<pid>/fd/Npour accéder aux données sans corrompre mon fs.

Ce serait assez génial si vous pouviez "annuler" la suppression en exécutant une option magique sur ln qui vous permettrait de vous reconnecter au numéro d'inode (récupéré via lsof).

Cette génialité a été introduite lndans la v8.0 (GNU / coreutils) avec l’ -L|--logicaloption qui permet lnde déréférencer une /proc/<pid>/fd/<handle>première. Donc un simple

ln -L /proc/<pid>/fd/<handle> /path/to/deleted/file

est suffisant pour relier un fichier supprimé.

On dirait que vous comprenez déjà beaucoup, alors je n’entrerai pas dans les détails. Il existe plusieurs méthodes pour trouver l'inode et vous pouvez généralement chat et rediriger STDOUT. Vous pouvez utiliser debugfs. Exécutez cette commande dans:

ln <$INODE> FILENAME

Assurez-vous que vous avez des sauvegardes du système de fichiers. Vous aurez probablement besoin de lancer un fsck après. J'ai testé cela avec succès avec un inode toujours en cours d'écriture et cela fonctionne pour créer un nouveau lien dur vers un inode déréférencé.

Si le fichier n'est pas lié à un fichier non ouvert dans ext3, les données sont perdues. Je ne suis pas sûr que cela soit toujours vrai, mais l'essentiel de mon expérience de récupération de données se fait avec ext2. De la FAQ ext3:

Q: Comment puis-je récupérer (récupérer) des fichiers supprimés de ma partition ext3? En fait, vous ne pouvez pas! Voici ce qu'en dit l'un des développeurs, Andreas Dilger:

Afin de garantir que ext3 puisse reprendre en toute sécurité une dissociation après un crash, il supprime en fait les pointeurs de bloc dans l'inode, alors qu'ext2 marque simplement ces blocs comme inutilisés dans les bitmaps de bloc et marque l'inode comme "supprimé" et laisse le bloc. pointeurs seuls.

Votre seul espoir est de "grep" pour des parties de vos fichiers qui ont été supprimés et qui espèrent mieux.

Il y a aussi des informations pertinentes dans cette question:

J'ai écrasé un fichier volumineux par un fichier vierge sur un serveur Linux. Puis-je récupérer le fichier existant?

la méthode de débogage que vous avez vue ne fonctionne pas vraiment et au mieux votre fichier sera automatiquement supprimé (à cause du journal) après le redémarrage et au pire vous pouvez détruire votre système de fichiers, ce qui entraînerait un "cycle de redémarrage de la mort". The Right Solution (TM) consiste à effectuer la suppression de suppression au niveau VFS (ce qui présente également l’avantage supplémentaire de fonctionner avec pratiquement tous les systèmes de fichiers Linux actuels). La voie d'appel système (flink) a été supprimée chaque fois qu'elle est apparue dans LKML. La meilleure façon de procéder consiste donc à utiliser un module + ioctl.

Fdlink ( https://github.com/pkt/fdlink.git pour une version testée avec le noyau d'ubuntu maverick) est un projet qui met en œuvre cette approche et a un code raisonnablement petit et propre . Avec celui-ci, après avoir inséré le module (sudo insmod flink_dev.ko), vous pouvez simplement faire "./flinkapp / proc // fd / X / my / link / path" et il fera exactement ce que vous voulez.

Vous pouvez également utiliser une version à port transféré de vfs-undelete.sourceforge.net qui fonctionne également (et peut également renvoyer automatiquement le lien au nom d'origine), mais le code de fdlink est plus simple et fonctionne tout aussi bien, c'est donc ma préférence.

Je ne sais pas comment faire exactement ce que vous voulez, mais ce que je ferais, c'est:

• Ouvrir le fichier RO depuis un autre processus
• Attendez que le processus original se termine
• Copiez les données de votre FD ouvert dans un fichier

Pas idéal, évidemment, mais possible. L'autre option consiste à jouer avec debugfs (à l'aide de la linkcommande), mais c'est plutôt effrayant sur une machine de production!

Couru dans le même problème aujourd'hui. Le mieux que je puisse trouver est de courir

% tail -n +0 -f /proc/<pid>/fd/<fd> /path/to/deleted_file

dans une session tmux / screen jusqu'à la fin du processus.

Question interessante. Un interviewer m'a posé la même question lors d'un entretien d'embauche. Ce que je lui ai dit, c'est qu'il n'y avait pas de moyen facile de faire cela et qu'en général, cela ne valait pas le temps et les efforts nécessaires. Je lui ai demandé quelle était, à son avis, la solution à ce problème ...

1. Utilisez lsof pour trouver le numéro d’inode sur le disque pour le processus car il apparaîtra même si le fichier a été supprimé ... la clé est qu’il est toujours ouvert.
2. Extrayez les informations du système de fichiers en fonction de cela via un débogueur de système de fichiers.

Utilisez Sleuthkit icat.

sudo icat /dev/rdisk1s2 5484287 > accidentally_deleted_open_file

La solution rapide qui a fonctionné pour moi, sans outils intimidants:

1) trouvez le processus + fd en regardant directement dans / proc:

ls -al /proc/*/fd/* 2>/dev/null | grep {filename}

2) Ensuite, une technique similaire à celle de @ nickray, avec pv:

tail -c +0 -f /proc/{procnum}/fd/{fdnum} | pv -s {expectedsize} > {recovery_filename}

Vous devrez peut-être appuyer sur Ctrl-C lorsque ls /proc/{procnum}/fd/{fdnum}vous aurez terminé ( vous indiquerez que le fichier n'existe plus), mais si vous connaissez la taille exacte en octets, vous pouvez l'utiliser pv -Spour le faire quitter lorsque le nombre est atteint.