Unix / Linux restaurer / récupérer les fichiers supprimés

124

Existe-t-il une commande permettant de récupérer / annuler la suppression des fichiers supprimés rm?

$ rm -rf /path/to/myfile

Comment puis-je récupérer myfile? S'il existe un tel outil, comment puis-je l'utiliser?

pylover
la source
1
cyberciti.biz/tips/… peut vous aider. En outre, c'est mieux dans Stack Exchange .
fedorqui
1. Ce serait mieux pour Unix et Linux 2. Des sauvegardes?
1
Avant de faire quoi que ce soit, montez le système de fichiers en lecture seule pour vous assurer que les données ne sont pas écrasées. Consultez également ce message: superuser.com/questions/170857/ext4-undelete-utilities .
1
@ EvanTeitelman vous voulez dire que remonter en lecture seule est mieux que d'essayer de récupérer le fichier alors qu'il est démonté? btw, midnightcommander (mc), suggère umounting datarecoverypros.com/recover-linux-midnightcommander.html
Aquarius Power Le
1
La meilleure solution consiste à penser à l’avenir et à utiliser un outil de contrôle des révisions.
ctrl-alt-delor

Réponses:

66

Le lien que quelqu'un a fourni dans les commentaires est probablement votre meilleure chance.

Linux debugfs Hack: Undelete Files

Cette description, bien que semblant un peu intimidante, est en fait assez simple à suivre. En général, les étapes sont les suivantes:

  1. Utiliser debugfs pour afficher un journal de système de fichiers

    $ debugfs -w /dev/mapper/wks01-root
    
  2. À l'invite de débogage

    debugfs: lsdel
    
  3. Échantillon 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.
    
  4. Exécuter la commande dans debugfs

    debugfs: logdump -i <7536655>
    
  5. 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.
    
  6. Avec les inodes ci-dessus, lancez 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 recovered.file.001.

Autres options

Si ce qui précède ne vous convient pas, j’ai utilisé des outils tels que la photorecrécupération de fichiers dans le passé, mais il s’agit uniquement de fichiers image. J'ai beaucoup écrit sur cette méthode sur mon blog dans cet article intitulé:

Comment récupérer des fichiers JPEG et mov corrompus à partir de la carte SDD d'un appareil photo numérique sur Fedora / CentOS / RHEL .

slm
la source
11
J'ai essayé avec debugfs -w /dev/sdb2mais lsdelsais:0 deleted inodes found.
rubo77
5
l’utilisation extundeleteest plus facile pour ext3 / 4 et mènerait probablement aux mêmes résultats.
Maître
1
cela a fonctionné pour récupérer un fichier, mais j'ai reçu @ y U T6 * e 0 v' T 0 <#selinuxsystem_u: object_r: rpm_var_lib_t: s0 } y U T6 ..... essayer de conv = ascii, conv = ibm et conv = ebcdic donne le même problème
codyc4321 Le
2
lsdel: Le système de fichiers n'est pas ouvert, comment le résoudre?
Amitābha
3
Je comprends /dev/mapper/wks01-root: No such file or directory while opening filesystemD'où viens-tu cela /dev/mapper/wks01-root?
Marko Avlijaš
29

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+ resuopour redémarrer + remonter en lecture seule, puis avec un live-cd, utilisez greppour rechercher sur le disque dur:

grep -a -C 500 'known pattern' /dev/sda | tee /tmp/recover

puis éditez /tmp/recoverpour ne conserver que ce qui était auparavant dans vos fichiers.

Hé, si avec la philosophie Unix tout est fichier, il est temps d'en profiter, non?

Gilles Quenot
la source
5
Votre grepsolution de base est très intelligente et a fonctionné pour moi, même avec le système de fichiers toujours monté. Merci!
wchargin
Je ne comprends pas comment la solution grep a fonctionné pour vous, elle ne génère que des données binaires. Comment est-ce utile?
w00t
2
@ w00t Bien sûr, il "seulement" crache des données binaires. Mais parfois, ces données binaires contiennent les bits ASCII correspondant au fichier que je cherche. Je suppose que je ne comprends pas la question?
wchargin
@ w00t l'astuce consiste à utiliser un modèle de recherche très spécifique à ce fichier. La commande grep prend les 500 lignes avant et après chaque ligne correspondante, elle restera donc chargée de nombreuses données non pertinentes, mais avec un éditeur de texte capable de gérer cela (par exemple, Vim), il est facile de faire la part des choses. les mauvaises choses. Vous pouvez également filtrer toutes les lignes avec des caractères non imprimables en les passant à travers une autre commande grep:grep -av "[^[:print:]]"
CJStuart
La grepsolution a fonctionné pour moi avec une modification: je l' ai fait sudo grep --line-buffered -ab "$PATTERN" /dev/sda1 | tee lineset a obtenu des décalages d'octets (comme 123123123:line\n456456456:another\n...), puis a fait n=1000; sudo dd of=before if=/dev/sda1 ibs=1 skip=$[123123123-$n] count=$net n=1000; sudo dd of=after if=/dev/sda1 ibs=1 skip=123123123 count=$navec différentes nvaleurs.
Kirill Bulygin
21

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

/dev/sdXNest la partition contenant le fichier perdu (à vérifier en mountcas de doute).

Cela a pris un peu de temps, mais cela a fonctionné lorsque j'ai accidentellement supprimé un code source que je n'avais pas encore engagé!

William Becker
la source
4
Très utile pour les programmeurs!. généralement, nous avons toujours perdu nos propres codes.
survol du
1
parlez-moi, j'ai accidentellement couru rm data/*.json python myFile.pyau lieu derm data/*.json && python myFile.py
William Becker Le
2
Merci, mon pote, tu viens de m'aider à récupérer un fichier texte, j'ai passé 2 heures à écrire la nuit. PS /dev/sdXNest pour le système de fichiers, non? J'ai trouvé le mien avecdf -T | awk '{print $1,$2,$NF}' | grep "^/dev"
Alex
Je ne vois que le binaire du fichier. Y a-t-il un moyen de le convertir au format normal?
Silgon
grep: conflicting matchers specified
Felwithe
10

Bien que cette question soit résolue et âgée de quelques années, je souhaite 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/sdXet 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, puis les copier dans un autre emplacement de votre système de fichiers.

S. Wilhelm
la source
Il ne voit pas mon / dev / nvme0n1p2
h22 le
6

J'ai eu le même problème la semaine dernière et j'ai essayé beaucoup de programmes, tels que 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.

Juan
la source
6

Une alternative peut être utiliser delau lieu de rmpour 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 faites aucun prisonnier»: -}

Framstag
la source
1
Pas une réponse comme vous l'avez déjà dit, mais merci d'avoir introduit la del commande.
survol
5

connecter le lecteur via une interface externe

  1. monter
  2. umount /dev/{sd*}
  3. extundelete --restore-all /dev/{sd*}
  4. les résultats vont au dossier personnel sur le lecteur de démarrage
  5. points bonus: écrivez une interface graphique pour cela

Voir ce lien pour plus d’informations: restaurer un fichier qui vient d’être supprimé sur ext4 avec extundelete .

GRZ
la source
2
Downvoters, veuillez expliquer pourquoi vous pensez qu'extundelete n'est pas une bonne option?
webminal.org
2
Agréable! Merci d'avoir posté. Extundelete est un nouvel outil pour moi. Je l'ai utilisé aujourd'hui et l'ai trouvé extrêmement utile. Beaucoup plus utile OMI que la réponse acceptée. Les seules choses que je voudrais ajouter à cette réponse pour l’améliorer légèrement sont (1) de réitérer les instructions de certaines autres réponses selon lesquelles il faut éteindre l’ordinateur affecté dès que l’on réalise que les fichiers ont été supprimés par erreur, et (2) démarrez à partir d’un liveCD ou d’un système d’exploitation liveUSB comme Kali Linux, qui inclut l’utilitaire extundelete (j’ai constaté que de nombreux autres LiveCD tels que Debian Jessie n’incluent pas cet utilitaire sur leur support d’installation).
Osteoboon
4

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 avec ufs-explorer et photorec

(1) = Pas de source ouverte, pas libre

(2) = Pas de source ouverte, libre

(3) = Open source et gratuit

(4) = avoir le support ntfs

(5) = avoir une structure de répertoire

intika
la source
1

Je ne suis pas d'accord sur le fait que c'est impossible, mais très très difficile, et je ne l'ai jamais fait non plus avec Linux:

Lorsque des fichiers sont supprimés, ils ne le sont pas réellement. Ce qui se passe, c’est que l’espace qu’ils occupaient sur le disque dur est en quelque sorte réinitialisé. Ainsi, si l’ordinateur tente d’écrire des données, rien ne se plaint. En règle générale, les données de votre disque dur que vous pensiez avoir supprimées peuvent être disponibles presque un an plus tard. Ou du moins, c'est mon expérience sur une machine Windows. Je ne sais pas si cela fonctionne de la même manière depuis une ligne de commande sous Linux, mais vous auriez probablement besoin d'un Live CD séparé pour ouvrir la partition de cette manière, et rien ne garantit également que les fichiers sont toujours présents. J'ai fait cela plusieurs fois sur Windows XP à l'aide de Zero Assumption Recovery. Je suis sûr qu'il existe un outil similaire si vous regardez suffisamment fort.

Roguebantha
la source
Selon la situation, cela peut être impossible à 100%. Cela peut ou peut ne pas fonctionner, mais vous n'avez JAMAIS de garantie.
Klutt
0

Lorsque vous supprimez un fichier, le nombre de liens dans la table inode de ce fichier est réduit de un. Sous Unix, lorsque le nombre de liens passe à 0, les blocs de données de ce fichier sont marqués comme étant libres et, en règle générale, les références à ces blocs de données sont perdues. Je viens de découvrir, à partir du commentaire de @ fedorqui, qu'il pourrait exister un moyen d'accéder à ces blocs, mais que cela ne s'applique qu'au système de fichiers ext3.

Une façon de préserver les fichiers consiste à écrire une fonction qui vous permettra de déplacer les fichiers dans une corbeille (disons $HOME/.trash) et de récupérer les fichiers nécessaires à partir de celle-ci. Cette fonction peut être associée à rm. Vous pouvez planifier un travail cron pour supprimer les fichiers qui se trouvent dans la corbeille depuis un certain nombre de jours.

unxnut
la source
0

Cela pourrait sauver le trouble pour certains d'entre vous.
Si vous avez déjà utilisé gedit pour éditer ce fichier, une copie de ce fichier sera créée par défaut.
Par exemple, supposons que nous ayons supprimé accidentellement "myfile.txt".
Dans le dossier qui contenait le fichier que vous venez de supprimer l' utilisation de ces commandes et vous récupérez la copie à partir de là:
ls | grep 'myfile.txt~'
Avec un peu de chance , vous trouverez, puis:
cp 'myfile.txt~' 'myfile.txt'
j'avoir récupéré un fichier juste en utilisant maintenant cette méthode. Bonne chance!

ntt
la source