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 ?
Les étapes suivantes sont des é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 panne en mode mono-utilisateur :
Ensuite, utilisez la commande init 1 pour passer en mode mono-utilisateur :
Utiliser grep (méthode traditionnelle d'UNIX) pour récupérer les fichiers :
Utilisez ensuite vi pour voir le fichier .txt.
Trouvé à http://www.cyberciti.biz/tips/linuxunix-recover-deleted-files.html
dd et essayez de trouver le fichier à l'intérieur (en utilisant grep, ou un éditeur). Edit : parfois ddrescue fonctionne mieux que dd.
Testdisk ](http://en.wikipedia.org/wiki/TestDisk) dispose d'une option de suppression qui devrait fonctionner avec Linux.
Il existe un guide pour Linux . Notez qu'il fonctionne pour ext2 , ext3 , et ext4 .
J'ai fait cela il y a quelques années. Mon approche consistait à démonter directement, sans perdre de temps, la partition et ensuite
dd if=/dev/hda1 of=backup_image.ext3
pour avoir un fichier de sauvegarde de l'état exact de la partition. Ensuite, vous pouvez remonter la partition et continuer comme si de rien n'était en recherchant le fichier supprimé dans l'image que vous avez créée. L'image sera probablement TRÈS grande puisque vous avez besoin de tout l'espace “vide”, il pourrait donc être un problème pratique de la stocker.
Ensuite, c'était juste pour effectuer des recherches ennuyeuses après des bribes de texte que je m'attendais à trouver quelque part dans la soupe du contenu de la partition. Par exemple, pour trouver des fichiers .tex, j'ai lancé
grep --binary-files=text -1000 "subsection" < backup_image.ext3 > latexfiles
qui a imprimé un grand contexte autour de l'expression “subsection” et a enregistré la sortie dans un fichier pour qu'on puisse y effectuer une recherche manuelle. J'ai imprimé un contexte si large car la recherche de l'image prenait tellement de temps que je préfère ne pas le faire plus de fois que nécessaire.
La commande strings a également été utile pour supprimer les binaires de la sortie, mais si je me souviens bien, elle a également supprimé tous les saut de ligne, ce qui pourrait être un 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 quelque chose 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 brève (et inadéquate) : Ext3/4 supprime les “marqueurs” qui indiquent au système d'exploitation 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ù ils commencent et où ils finissent sur le disque, et parfois même ils sont fragmentés à plusieurs endroits. D'autres systèmes de fichiers se contentent de mettre le statut des fichiers à “supprimé”, mais conservent les données de localisation. Il n'est alors pas plus difficile de supprimer un fichier que de regarder les pointeurs de fichiers avec ce drapeau (ils devraient toujours être disponibles si l'activité n'a pas été trop importante), et d'espérer ensuite que leur contenu n'a pas été écrasé.
Quel est le mieux ? La rhétorique, à mon avis. Une sauvegarde fréquente est la réponse à tous ces problèmes. Des données importantes sans un système de sauvegarde automatisé sont un accident en attente, IMHO.
Anecdote personnelle obligatoire : J'allais supprimer 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 a fait en
rm -r foo\ foo *
J'ai appuyé sur Enter et je me suis assis là en regardant la commande, ce 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’”. Très vite, j'ai ressenti des frissons et j'ai appuyé sur Ctrl+c de manière douce et très contrôlée. ~La moitié de mon ~ a été supprimée, mais j'ai réussi à récupérer tout ce qui avait de la valeur grâce au grepping décrit ci-dessus et à quelques sauvegardes plus ou moins actuelles. J'avais sur le disque des données de mesure très précieuses (lecture : longue) et très récentes qui avaient été perdues, mais j'avais fait quatre sauvegardes. L'une d'entre elles a disparu ici, une autre à cause d'une panne de système à l'école, une autre était corrompue, et au début je n'ai pas pu trouver la quatrième, car je l'avais mise par erreur dans le mauvais dossier :-D . Si rm -r n'était pas resté coincé sur un fichier protégé en écriture, le quatrième aurait été mangé puisque ce dossier a été monté via sshfs dans mon ~. Je fais beaucoup plus attention à ce genre de choses depuis.
La seule réponse correcte est : restaurez votre fichier à partir d'une sauvegarde. Tout le monde doit avoir une sauvegarde. Pour les fichiers vraiment importants, vous devez avoir deux sauvegardes. Vous n'en avez pas ? Et bien, dommage, voici une leçon apprise ( Désolé de paraître dur, mais je suis dans le stockage de données, et les gens ne font pas de sauvegarde avant d'avoir perdu des données importantes, c'est un fait acquis. Donc oui, vous avez l'air stupide, mais presque tout le monde l'est aussi ).
OK, vous n'avez pas de sauvegarde. vous devez arrêter d'utiliser le système de fichiers qui contenait le fichier DROIT MAINTENANT. Toute activité d'écriture peut définitivement aspirer les données du fichier qui peut (seulement peut) rester sur le disque.
si vous avez fait l'erreur tragique d'utiliser une seule partition à la fois comme système de fichiers racine et /home, cela signifie que vous doit démarrer à partir d'un autre périphérique. **Sachez que
si votre fichier est d'un format commun (fichier Word, JPG, etc.), utilisez Photorec . Photorec peut récupérer la plupart des formats de fichiers courants.
Vous pouvez essayer la méthode “ext3 undelete” proposée précédemment, mais vous devez être à l'aise avec la ligne de commande, comprendre les rouages de base de linux, etc.
Si votre fichier est d'un format spécial, pas de chance. J'ai un jour écrit un programme Perl pour scanner un lecteur à la recherche de certains fichiers spéciaux, et il fonctionnait plutôt bien ; mais vous devrez connaître un peu de programmation pour faire cela, et être assez à l'aise avec linux aussi.
Si c'est la norme rm , j'espère que vous avez une sauvegarde. La procédure de récupération d'un fichier supprimé serait différente pour chaque système de fichiers, si tant est qu'elle puisse être effectuée. Linux n'a pas de “corbeille” intégrée ; une fois que vous avez supprimé un fichier, il est pratiquement disparu.
Quelle que soit la manière dont vous le faites, vous voudrez débrancher l'ordinateur – dès que possible, car continuer à faire tourner l'ordinateur (même pour l'arrêter) provoque des écritures sur le disque et augmente les chances que certains blocs précédemment occupés par le fichier soient écrasés. Une fois que vous avez fait cela, soit vous le mettez dans un autre ordinateur, soit vous redémarrez un live CD (en veillant à ne pas monter le disque à moins que vous ne le montiez en lecture seule), soit vous retirez le disque dur et vous l'apportez à un spécialiste de la récupération des données.
Ne vous attendez pas à grand-chose. Si quelque chose a été écrit sur les données “supprimées”, vous le perdrez.
J'ai fait un peu de récupération et les meilleurs outils que j'ai trouvés étaient souvent conçus pour certains formats. Par exemple, “photorec” m'a permis de récupérer des dizaines de milliers de jpegs. Recuva m'a également aidé auparavant et pourrait être votre meilleur choix. (C'est gratuit, ne vous faites pas piéger pour payer par leurs publicités)
À la fin de la journée, si ce que vous avez perdu est important, retirez le disque dur et arrêtez d'y écrire. Utilisez tous les logiciels de récupération que vous pouvez trouver jusqu'à ce que vous récupériez vos données ou que cela ne vaille plus la peine. Si c'est vraiment important, envoyez-le à des professionnels à un prix élevé.
Si vous avez déjà eu de la chance avec un outil, essayez-le à nouveau vu que vous le connaissez bien. En fin de compte, ils ne devraient pas écrire sur le disque et vous pouvez donc utiliser le logiciel jusqu'à ce que vous en trouviez un qui fonctionne.
Si vous avez une application ouverte qui est en train de lire le fichier, comme VLC ou LibreOffice, alors cette formidable réponse de L&U.SO m'a aidé à sortir de ce pétrin. Voici une méthode alternative pour faire de même.
L'idée générale est de trouver le lien dans /proc/PID/fd/DESCRIPTOR_NUMBER et de le recopier à son emplacement d'origine. Utilisez ps aux | grep APP_NAME pour trouver le PID et ensuite ls -la /proc/PID/fd/ pour trouver le DESCRIPTEUR approprié.
Si elle n'est pas écrasée par d'autres utilisateurs, vous avez de la chance. J'ai accidentellement supprimé mon fichier source cpp et utilisé un outil appelé foremost , qui m'a aidé à restaurer les débris cpp 60G du disque. Finalement, j'ai récupéré mon fichier en assemblant ces débris morceau par morceau. Je pense qu'il scanne certains modèles pour un type de fichier spécifique et traverse tous les inodes du disque pour récupérer les fichiers ! Essayez-le !
La “bonne” réponse est de supposer qu'il n'y a pas de méthode de récupération fiable, et de restaurer à partir de sauvegardes ou d'un système cloné ou de réinstaller.
TestDisk est un excellent outil, et il y a d'autres moyens de pouvoir récupérer certaines données du disque physique en fonction du système de fichiers et de la date de suppression, mais le temps et la douleur impliqués peuvent être tout simplement trop importants, alors GARDEZ LES SAUVEGARDE (et vérifiez également qu'elles sont valides et restaurables) !
Voici un excellent document pour vous. Vous y trouverez une foule de conseils pratiques.
BTW, il y a deux groupes de personnes :
Félicitations, vous venez de vous promouvoir dans le groupe 2 ;-)
Si vous avez accidentellement supprimé le fichier de Linux, vous pouvez utiliser cette commande :
find /root -name "search text" -type f -exec mv {} "/home" \;
à la place de search text vous pouvez mettre le nom du fichier et préciser le répertoire où vous voulez le restaurer à la place de /home.
Vous pouvez essayer ce scénario. Il fonctionne bien et est destiné à remplacer le rm et l'im qui l'utilisent beaucoup maintenant. https://github. com/nateshmbhat/safe-rm
rmJ'ai eu le même problème la semaine dernière et j'ai essayé beaucoup de programmes, comme debugfs, photorec, ext3grep et extundelete. ext3grep était le meilleur programme pour récupérer des fichiers. La sintax est très facile :
ext3grep image.img --restore-all
ou :
ext3grep /dev/sda3 --restore-all --after date -d '2015-01-01 00:00:00' '+%s' --before `date -d ‘2015-01-02 00:00:00’ ‘+%s’
Cette vidéo montre est un mini tutoriel qui peut vous aider.