Par accident, j'ai utilisé rm sur un fichier que je ne voulais pas supprimer. Y a-t-il un moyen de le récupérer sous Linux ?
Réponses
Trop de publicités?
Voici les étapes génériques pour récupérer des fichiers texte.
-
Utilisez d'abord la commande wall pour indiquer à l'utilisateur que le système est en train de s'arrêter en mode mono-utilisateur :
# wall System is going down to .... please save your work.Appuyez sur CTRL+D pour envoyer le message.
-
Ensuite, utilisez la commande init 1 pour passer le système en mode utilisateur unique :
# init 1 -
Utilisation de grep (méthode traditionnelle UNIX) pour récupérer des fichiers
Utilisez la syntaxe grep suivante :
grep -b 'search-text' /dev/partition > file.txtOU
grep -a -B[size before] -A[size after] 'text' /dev/[your_partition] > file.txtOù,
-i : Ignore case distinctions in both the PATTERN and the input files i.e. match both uppercase and lowercase character. -a : Process a binary file as if it were text -B Print number lines/size of leading context before matching lines. -A: Print number lines/size of trailing context after matching lines.Pour récupérer un fichier texte commençant par "nixCraft" sur /dev/sda1, vous pouvez essayer la commande suivante :
# grep -i -a -B10 -A100 'nixCraft' /dev/sda1 > file.txt -
Ensuite, utilisez vi pour voir file.txt.
Cette méthode n'est utile QUE si le fichier supprimé est un fichier texte. Si vous utilisez le système de fichiers ext2, essayez la commande recover.
Trouvé à http://www.cyberciti.biz/tips/linuxunix-recover-deleted-files.html
Sjoerd
Points
1161
- Si c'est très, très important, retirez le disque de l'ordinateur et faites appel à une société pour le faire.
- Si elle n'est que très importante, montez le disque en lecture seule, copiez toute la partition dans un fichier en utilisant la fonction
ddet essayer de trouver le fichier à l'intérieur de celui-ci (en utilisantgrepou un rédacteur).
Edit : parfois ddrescue fonctionne mieux que dd .
Jonathan Bennett
Points
131
Daniel Andersson
Points
22765
Je l'ai fait il y a quelques années. Mon approche était de démonter directement, sans perdre de temps, la partition et ensuite
dd if=/dev/hda1 of=backup_image.ext3pour avoir un fichier de sauvegarde de l'état exact de la partition. Vous pouvez ensuite remonter la partition et continuer à travailler comme d'habitude en recherchant le fichier supprimé dans l'image que vous avez créée. L'image sera probablement TRES grande puisque vous avez besoin de tout l'espace "vide", donc cela pourrait être un problème pratique pour la stocker.
Ensuite, il ne s'agissait plus que d'effectuer des recherches ennuyeuses après des extraits de texte que je m'attendais à trouver quelque part dans la soupe de contenu de partition. Par exemple, pour trouver des fichiers .tex, j'ai exécuté
grep --binary-files=text -1000 "subsection" < backup_image.ext3 > latexfilesqui imprimait un grand contexte autour de la phrase "sous-section" et sauvegardait la sortie dans un fichier pour être recherchée manuellement. J'ai imprimé un contexte aussi large car la recherche de l'image prenait tellement de temps que je préférais ne pas le faire plus de fois que nécessaire.
De même, la commande strings a été utile pour supprimer les déchets binaires de la sortie, mais si je me souviens bien, il a également supprimé toutes les nouvelles lignes, ce qui pourrait poser problème.
Pour trouver des fichiers binaires de la même manière, on pourrait réussir à trouver un en-tête caractéristique ou autre d'un certain fichier, mais j'imagine que c'est une assez grande aventure.
Brèves notes techniques : il y a des difficultés techniques avec la récupération de disque et Ext3/4. C'est une chose longue à expliquer, mais brièvement (et de manière inadéquate) : Ext3/4 supprime les "marqueurs" qui indiquent à l'OS où se trouvent les fichiers sur le disque lorsque vous les supprimez. Les fichiers ne sont pas effacés, mais personne ne sait plus où sur le disque ils commencent et finissent, et parfois ils sont même fragmentés à plusieurs endroits. Certains autres systèmes de fichiers définissent simplement l'état des fichiers comme "supprimé", mais conservent les données d'emplacement. Dans ce cas, la suppression n'est pas plus difficile que de regarder les pointeurs de fichiers avec ce drapeau (ils devraient toujours être disponibles s'il n'y a pas eu trop d'activité), et ensuite espérer que leur contenu n'a pas été écrasé.
Qu'est-ce qui est le mieux ? Rhétorique, à mon avis. Une sauvegarde fréquente est la réponse à tous ces problèmes. Des données importantes sans automatisé Le système de sauvegarde est un accident qui risque de se produire, à mon avis.
Anecdote personnelle obligatoire : J'allais enlever foo\ foo* de ~ . J'ai écrit
rm -r foo<Tab>*ce qui, malheureusement, puisque foo était apparemment un lien symbolique et le seul fichier correspondant, le Shell fait en
rm -r foo\ foo *J'ai appuyé sur Entrée et je suis resté assis à regarder la commande, qui aurait dû prendre une seconde tout au plus. Après un peu plus de temps rm m'a demandé si je voulais "supprimer le fichier protégé en écriture 'quelque chose'". assez rapidement, j'ai eu des frissons et j'ai appuyé doucement et de manière très contrôlée sur Ctrl+c . ~La moitié de mon ~ a été supprimé, mais j'ai réussi à récupérer tout ce qui avait de la valeur grâce à la récupération décrite ci-dessus et à des sauvegardes plus ou moins récentes. J'avais personnellement des données de mesure très précieuses (lire : qui prennent du temps) et très récentes sur le disque qui ont été perdues, mais j'avais fait des sauvegardes quadruples. Une a disparu ici, une autre à cause d'une panne de système à l'école, une autre était corrompue, et au début je ne pouvais pas trouver la quatrième, puisque je l'avais mise par erreur dans le mauvais dossier :-D . Je n'avais pas rm -r est resté bloqué sur un fichier protégé en écriture, le quatrième aurait été mangé puisque ce dossier était monté via sshfs dans mon système d'exploitation. ~ . Je fais beaucoup plus attention à ce genre de choses depuis.
- Réponses précédentes
- Plus de réponses
