Existe-t-il une commande pour récupérer/restaurer les fichiers supprimés par rm
?
$ rm -rf /path/to/myfile
Comment puis-je récupérer myfile
? S'il existe un tel outil, comment puis-je l'utiliser?
Le lien que quelqu'un a fourni dans les commentaires est probablement votre meilleure chance.
Linux debugfs Hack: Undelete Files
Cet article, bien que semblant un peu intimidant, est en fait assez simple à suivre. En général, les étapes sont les suivantes:
Utilisez debugfs pour afficher un journal des systèmes de fichiers
$ debugfs -w /dev/mapper/wks01-root
À l'invite debugfs
debugfs: lsdel
Exemple de sortie
Inode Owner Mode Size Blocks Time deleted
23601299 0 120777 3 1/ 1 Tue Mar 13 16:17:30 2012
7536655 0 120777 3 1/ 1 Tue May 1 06:21:22 2012
2 deleted inodes found.
Exécutez la commande dans debugfs
debugfs: logdump -i <7536655>
Déterminer l'inode des fichiers
...
...
....
output truncated
Fast_link_dest: bin
Blocks: (0+1): 7235938
FS block 7536642 logged at sequence 38402086, journal block 26711
(inode block for inode 7536655):
Inode: 7536655 Type: symlink Mode: 0777 Flags: 0x0 Generation: 3532221116
User: 0 Group: 0 Size: 3
File ACL: 0 Directory ACL: 0
Links: 0 Blockcount: 0
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x4f9fc732 -- Tue May 1 06:21:22 2012
atime: 0x4f9fc730 -- Tue May 1 06:21:20 2012
mtime: 0x4f9fc72f -- Tue May 1 06:21:19 2012
dtime: 0x4f9fc732 -- Tue May 1 06:21:22 2012
Fast_link_dest: bin
Blocks: (0+1): 7235938
No magic number at block 28053: end of journal.
Avec les informations d'inode ci-dessus, exécutez les commandes suivantes
# dd if=/dev/mapper/wks01-root of=recovered.file.001 bs=4096 count=1 skip=7235938
# file recovered.file.001
file: ASCII text, with very long lines
Les fichiers ont été récupérés dans recovered.file.001
.
Si ce qui précède n'est pas pour vous, j'ai utilisé des outils tels que photorec
pour récupérer des fichiers dans le passé, mais il est destiné uniquement aux fichiers image. J'ai beaucoup écrit sur cette méthode sur mon blog dans cet article intitulé:
Avec un peu de chance, je peux parfois récupérer des fichiers supprimés avec ce script ou la solution suivante dans la réponse:
#!/bin/bash
if [[ ! $1 ]]; then
echo -e "Usage:\n\n\t$0 'file name'"
exit 1
fi
f=$(ls 2>/dev/null -l /proc/*/fd/* | fgrep "$1 (deleted" | awk '{print $9}')
if [[ $f ]]; then
echo "fd $f found..."
cp -v "$f" "$1"
else
echo >&2 "No fd found..."
exit 2
fi
Il existe une autre astuce utile: si vous connaissez un modèle dans vos fichiers supprimés, tapez alt+sys+resuo pour redémarrer + remonter en lecture seule, puis avec un live-cd, utilisez grep
pour rechercher dans le disque dur:
grep -a -C 500 'known pattern' /dev/sda | tee /tmp/recover
puis éditez /tmp/recover
pour ne conserver que vos fichiers antérieurs.
Hé, si avec la philosophie Unix, tout est fichier, il est temps d'en profiter, non?
Ce qui a fonctionné pour moi a été donné par Arch (s'applique uniquement aux fichiers texte):
grep -a -C 200 -F 'Unique string in text file' /dev/sdXN
où /dev/sdXN
est la partition contenant le fichier perdu (vérifiez avec mount
en cas de doute).
Prend un peu de temps, mais a fonctionné quand j'ai accidentellement supprimé du code source que je n'avais pas encore commis!
Bien que cette question soit résolue et vieille de quelques années, je veux mentionner l'utilitaire testdisk .
Comment récupérer des fichiers avec testdisk est bien expliqué dans ce tutoriel . Pour récupérer des fichiers, exécutez testdisk /dev/sdX
et sélectionnez votre type de table de partition. Après cela, sélectionnez [ Advanced ] Filesystem Utils
, puis choisissez votre partition et sélectionnez [Undelete]
. Vous pouvez maintenant parcourir et sélectionner les fichiers supprimés et les copier vers un autre emplacement de votre système de fichiers.
J'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 syntaxe est très simple:
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 est un mini tutoriel qui peut vous aider.
Une alternative peut utiliser del
au lieu de rm
pour supprimer:
http://fex.belwue.de/fstools/del.html
del
a une fonction de suppression et fonctionne avec n'importe quel système de fichiers.
Bien sûr, ce n'est pas une solution si vous avez déjà supprimé vos fichiers avec "ne pas faire de prisonniers" rm: -}
Outils de récupération - Ligne de commande:
Outils de récupération - Gui:
Infos:
Dans mon expérience personnelle, je récupère mes données en utilisant ufs-Explorer et photorec
(1) = Pas open source, pas gratuit
(2) = Pas open source, gratuit
(3) = Open source et gratuit
(4) = Avoir le support ntfs
(5) = Avoir une fonction de structure de répertoire
connecter le lecteur via une interface externe
umount /dev/{sd*}
extundelete --restore-all /dev/{sd*}
Voir ce lien pour plus d'informations: annuler la suppression d'un fichier juste supprimé sur ext4 avec extundelete .
Je ne suis pas d'accord pour dire que c'est impossible, juste très très difficile, et je ne l'ai jamais fait non plus sur Linux:
Lorsque des fichiers sont supprimés, ils ne sont pas réellement supprimés. Ce qui se passe, c'est que l'espace qu'ils occupaient sur le disque dur est en quelque sorte réinitialisé, de sorte que si l'ordinateur essaie d'y écrire des données, rien ne se plaint. Généralement, les données sur votre disque dur que vous pensiez avoir supprimées peuvent y être présentes presque un an plus tard. Ou du moins, c'est mon expérience sur une machine Windows. Que cela fonctionne ou non de la même manière à partir d'une ligne de commande sous Linux, je ne suis pas sûr, mais vous auriez probablement besoin d'un Live CD séparé pour ouvrir la partition comme ça, et il n'y a également aucune garantie que les fichiers sont toujours là. Je l'ai fait plusieurs fois sur Windows XP en utilisant Zero Assumption Recovery. Je suis sûr qu'il existe un outil similaire si vous regardez bien.
Cela pourrait vous éviter des ennuis.
Si vous avez déjà utilisé gedit pour modifier ce fichier, par défaut une copie de ce fichier sera créée.
Supposons par exemple que nous avons accidentellement supprimé "monfichier.txt".
Dans le dossier qui contenait le fichier que vous venez de supprimer, utilisez ces commandes et vous en récupérerez la copie:ls | grep 'myfile.txt~'
Avec un peu de chance, vous le trouverez et ensuite:cp 'myfile.txt~' 'myfile.txt'
Je viens de récupérer un fichier en utilisant cette méthode. Bonne chance!
Lorsque vous supprimez un fichier, le nombre de liens dans la table d'inode de ce fichier est diminué de un. Sous Unix, lorsque le nombre de liens tombe à 0, les blocs de données de ce fichier sont marqués comme libres et généralement, les références à ces blocs de données sont perdues. Je viens de découvrir à partir du commentaire de @ fedorqui qu'il peut y avoir un moyen d'accéder à ces blocs, mais cela ne s'applique qu'au système de fichiers ext3.
Une façon de conserver les fichiers sera d'écrire une fonction qui vous permettra de déplacer les fichiers dans une zone de corbeille (disons $HOME/.trash
) et récupérer les fichiers nécessaires à partir de là. Cette fonction peut être aliasée en rm
. Vous pouvez planifier un travail cron pour supprimer les fichiers qui se trouvaient dans la zone de la corbeille depuis un certain nombre de jours.