web-dev-qa-db-fra.com

Les fichiers remplacés peuvent-ils être récupérés?

Je ne parle pas de récupérationfichiers supprimés , mais fichiers écrasés . À savoir par les méthodes suivantes:

# move
mv new_file old_file

# copy
cp new_file old_file

# edit
vi existing_file
> D
> i new_content
> :x

Est-il possible de récupérer quoi que ce soit si l'une des trois actions ci-dessus est effectuée en supposant qu'aucun programme spécial n'est installé sur la machine Linux?

data-recoveryext4
45
Question Overflow

La réponse est "probablement oui, mais cela dépend du type de système de fichiers et du timing".

Aucun de ces trois exemples n'écrasera les blocs de données physiques de old_file ou existing_file, sauf par hasard.

  • mv new_file old_file. Cela dissociera old_file. S'il existe des liens physiques supplémentaires vers old_file, les blocs resteront inchangés dans ces liens restants. Sinon, les blocs seront généralement (cela dépend du type de système de fichiers) placés sur une liste libre. Ensuite, si mv nécessite une copie (contrairement au déplacement des entrées de répertoire), de nouveaux blocs seront alloués lors de l'écriture de mv.

    Ces blocs nouvellement alloués peuvent ou non être les mêmes que ceux qui viennent d'être libérés . Sur les systèmes de fichiers comme UFS , les blocs sont alloués, si possible, à partir du même groupe de cylindres que le répertoire dans lequel le fichier a été créé. Il y a donc une chance que la dissociation d'un fichier à partir d'un répertoire et la création d'un fichier dans ce même répertoire réutilisera (et écrasera) certains des mêmes blocs qui viennent d'être libérés. C'est pourquoi le conseil standard aux personnes qui suppriment accidentellement un fichier est de ne pas écrire de nouvelles données dans les fichiers de leur arborescence de répertoires (et de préférence pas dans l'ensemble du système de fichiers) jusqu'à ce que quelqu'un puisse tenter la récupération de fichiers.

  • cp new_file old_file Fera ce qui suit (vous pouvez utiliser strace pour voir les appels système):

    open ("old_file", O_WRONLY | O_TRUNC) = 4

    Le drapeau O_TRUNC entraînera la libération de tous les blocs de données, tout comme mv l'a fait ci-dessus. Et comme ci-dessus, ils seront généralement ajoutés à une liste gratuite et peuvent ou non être réutilisés par les écritures suivantes effectuées par la commande cp.

  • vi existing_file. Si vi est en réalité vim, la commande :x Effectue les opérations suivantes:

    unlink ("existing_file ~") = -1 ENOENT (Aucun fichier ou répertoire de ce type)
    renommer ("fichier_existant", "fichier_existant ~") = 0
    ouvert ("fichier_existant", O_WRONLY | O_CREAT | O_TRUNC, 0664) = 3

    Donc, il ne supprime même pas les anciennes données; les données sont conservées dans un fichier de sauvegarde.

    Sur FreeBSD, vi fait open("existing_file",O_WRONLY|O_CREAT|O_TRUNC, 0664), qui aura la même sémantique que cp, ci-dessus.

Vous pouvez récupérer tout ou partie des données sans programmes spéciaux; tout ce dont vous avez besoin est grep et dd, et l'accès au périphérique brut.

Pour les petits fichiers texte, la commande unique grep dans la réponse de @Steven D dans la question à laquelle vous avez lié est la manière la plus simple:

grep -i -a -B100 -A100 'text in the deleted file' /dev/sda1

Mais pour les fichiers plus volumineux qui peuvent être dans plusieurs blocs non contigus, je fais ceci:

grep -a -b "text in the deleted file" /dev/sda1
13813610612:this is some text in the deleted file

qui vous donnera le décalage en octets de la ligne correspondante. Suivez ceci avec une série de commandes dd, en commençant par

dd if=/dev/sda1 count=1 skip=$(expr 13813610612 / 512)

Vous souhaitez également lire certains blocs avant et après ce bloc. Sur UFS, les blocs de fichiers font généralement 8 Ko et sont généralement alloués de manière assez contiguë, les blocs d'un seul fichier étant entrelacés alternativement avec des blocs de 8 Ko provenant d'autres fichiers ou d'espace libre. La queue d'un fichier sur UFS contient jusqu'à 7 fragments de 1 Ko, qui peuvent être contigus ou non.

Bien sûr, sur les systèmes de fichiers qui compressent ou chiffrent les données, la récupération peut ne pas être aussi simple.

Il existe en fait très peu d'utilitaires sous Unix qui écraseront les blocs de données d'un fichier existant. Un qui me vient à l'esprit est dd conv=notrunc. Un autre est shred.

65
Mark Plotnick

Je vais dire non (avec un astérisque géant).

Pensez à la façon dont les données sont déposées sur un disque. Vous avez des blocs qui contiennent des données et pointent vers le bloc suivant (s'il y en a un).

Lorsque vous écrasez des données, vous modifiez le contenu du bloc (et si vous étendez le fichier tout le marqueur de fin). Donc rien ne devrait pouvoir être récupéré (voir ci-dessous).

Si vous raccourcissez le fichier, vous perdez les anciens blocs et ils seront bientôt recyclés. Si vous êtes un programmeur, pensez à une liste chaînée où vous "perdez" la moitié de votre liste sans effectuer de suppression/suppression. Ces données sont toujours là, mais bonne chance pour les trouver.

Quelque chose qui pourrait être intéressant à penser est la fragmentation.

La fragmentation se produit lorsque vous avez des "trous" de données non contiguës sur votre disque. Cela peut être dû à la modification des fichiers de telle sorte que vous les étendez ou les raccourcissez et qu'ils ne tiennent plus à leur emplacement d'origine sur le disque.

Dans le cas où un fichier dépasse sa taille d'origine (il doit se déplacer à ce stade), selon votre système de fichiers, vous pouvez copier l'intégralité du fichier vers un nouvel emplacement où les anciennes données seraient toujours là (mais marquées comme libres) ou vous venez de changer l'ancien pointeur de fin et de le faire pointer vers un nouvel emplacement (cela entraînera un thrashing).

Bref, vos données sont probablement perdues (sans passer par un processus médico-légal extrême où vous les regardez au microscope); cependant, il est possible qu'elle soit toujours là.

6
SailorCire

Assurez-vous que vous disposez de suffisamment d'espace disque dans/var/tmp ou dans un emplacement important.

Essayer

 grep -i -a -B100 -A100 'a string unique to your file' /dev/sda1 |
 strings > /var/tmp/my-recovered-file

où/dev/sda1 serait votre disque sur votre système.

Ensuite, recherchez mon fichier récupéré pour votre chaîne.

Il pourrait être principalement là, si vous le trouvez, vérifiez les espaces de ligne manquants, les crochets, les symboles système, etc.

Utilisez un mot de recherche de votre fichier qui est assez peu précis ou une chaîne qui réduira la quantité de données dans le fichier. Si vous recherchez un mot tel que "echo", vous récupérerez des charges de chaînes car le système contiendra beaucoup de fichiers contenant l'écho de Word.

3
AndyM

TL; DR - Si le fichier écrasé est toujours maintenu ouvert par un processus en cours, alors ce billet de blog peut enregistrer votre bacon:

https://www.linux.com/news/bring-back-deleted-files-lsof/

Dans ce document, il parle de fichiers supprimés , mais j'ai eu de la chance avec même un fichier qui a été écrasé par rsync. Et je parle d'un fichier de 60 Go écrasé par un fichier de 4 Mo, et j'ai pu récupérer l'original car, heureusement, je n'avais pas arrêté le processus en cours qui le maintenait ouvert.

0
fulv

J'avais écrasé un fichier texte (VQ1.txt) avec 12 heures de données de test :( Une notion selon laquelle unix enregistre la version précédente du fichier au format text.txt ~, m'a fait regarder dans le dossier contenant le fichier écrasé avec $ -ll Full la liste montrait VQ1.txt ~ qui avait mes données "perdues"!

$ cat VQ1.txt~  
Start time at: Thu Apr  2 18:07:23 PDT 2015
User, KW: 12hrFA_OEM_HelloVoiceQ
Test Case: 
Detection:  1, 1, 04-03 01:07:00.673 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  2, 1, 04-03 01:09:04.813 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  3, 1, 04-03 04:09:26.023 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  4, 1, 04-03 04:11:29.893 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  5, 1, 04-03 07:12:27.013 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  6, 1, 04-03 07:14:30.803 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  7, 1, 04-03 08:37:13.113 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  8, 1, 04-03 10:21:23.533 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  9, 1, 04-03 10:23:27.733 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  10, 1, 04-03 13:23:47.893 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1
Detection:  11, 1, 04-03 13:25:52.203 D/MultiKeywordBdctReceiver( 1743): vs status 258 : 2 : 1

12hrFA_OEM_HelloVoiceQ,  
KW detect count: 11
0
catsat