Récupérer des fichiers effacés - Linux Magazine France No 3

Combien de fois avez-vous malencontreusement effacé un fichier ? Habituellement une fois suffit, ensuite on vérifie à deux fois avant d-utiliser rm. Le problème est que, dans de rares occasions, on ne possède pas de copie de secours du fichier et que celui-ci est d-une importance vitale. Grâce au système de fichiers Ext2, il est possible de récupérer tout ou partie des données effacées.

Récupérer un fichier effacé doit être considéré comme un ultime recours. Aucun système de fichiers ni aucun utilitaire ne vous garantie une plus grande sécurité que la méthode classique. Celle-ci est très simple et se résume à une seul affirmation : FAITES DES SAUVEGARDES !

Il est toujours préférable de passer 10 minutes à copier des fichiers que 2 jours à tenter de les récupérer (peut être en partie).

Lorsqu-un fichier est écrit sur un disque, le système alloue des blocs en fonction de la taille du fichier. Une fois le fichier effacé du disque, ces blocs sont à nouveau disponibles et le système peut à nouveau les allouer à un autre fichier. Le problème principal sous Linux est le fait qu-il soit multitâches et multi-utilisateurs. En effet, pour peu que le système soit fortement utilisé, à peine les bloc sont-ils libérés qu-ils sont à nouveau alloués à un autre fichier. Conclusion, plus le système est occupé moins vous avez de chance de retrouver vos données. Sur un système mono-utilisateur et si l-activité du disque était faible au moment et après l-effacement, vous retrouverez au minimum 80% des données. Bien sûr, dans le cas d-un fichier binaire ou d-une image compressée, 80% n-est pas suffisant, mais comprenez bien qu-il s-agit là d-un minimum.

Il existe deux méthodes pour retrouver "ses petits". La première consiste à modifier le système de fichiers de manière à intimer au système l-ordre de retirer l-indicateur "supprimé". Dans le meilleur des cas, les données réappara"trons à leur place toutes seules. Une autre technique consiste à retrouver les données sur le périphérique et à les réécrire dans un autre fichier. Cette manière de procéder est beaucoup plus lente mais permet une récupération plus sûre des données. Voici les étapes nécessaires à la récupération :

Il fortement déconseillé de bricoler un système de fichiers monté. De plus, plus vite le système de fichiers sera démonté, plus vous aurez de chance de retrouver 100% des données. Si le système de fichiers contient des utilitaires nécessaires au fonctionnement du système remontez-le en lecture seule. Exemple : si le système de fichiers est monté dans /toto faites : mount -o ro,remount /usr. Si c-est dans la partition racine que des données doivent être récupérées, ajoutez le paramètre -n pour éviter une opération d-écriture dans /etc/mtab.

Si la tentative de montage ou de démontage échoue en vous retournant "ressource busy", c-est qu-un processus utilise la ressource. Utilisez l-utilitaire fuser -v -m suivie du point de montage pour conna"tre le ou les processus incriminés. Utilisez alors fuser -k -TERM -v -m suivie du point de montage. Ceci devrait envoyer le signal SIGTERM au processus pour qu-il se termine. Si, dans un cas extrême, les processus ne répondent pas, utilisez les options -k -v -m pour envoyer un signal SIGKILL.

Pour la suite des opérations, vous devez avoir à votre disposition une partition de secours afin d-y recopier les données récupérées. Dans une installation traditionnel, l-arborescence de Linux doit être composée de plusieurs partitions montées en des points différents. Dans la réalité, tout le monde le conseille, mais personne ne le fait. Si comme nous, vous ne suivez pas les conseils, vous pouvez utiliser une partition DOS. Une autre solution consiste à utiliser un ramdisk si votre noyau le supporte. Pour cela tapez :

Note : si vous utilisez kerneld, ne démontez pas le ramdisk tant que les fichiers n-ont pas été recopiés sur un support non volatile comme un disque dur ou une disquette. Dans le cas contraire, kerneld estimera qu-il peut décharger le module et les données sur le ramdisk seront perdues.

Pour lire les blocs qui étaient utilisés par votre ou vos fichiers perdus, il sera nécessaire d-utiliser un programme capable de se rendre à l-emplacement sur le disque de manière rapide. L-utilitaire dd permet d-accéder à n-importe quel bloc. Le seul problème est le fait qu-il travail en accès séquentiel, c-a-d que pour accéder au 12 455 400 ième octet il devra lire chaque octet précédent. L-auteur du Undeletion-mini-HOWTO a créé un utilitaire bien plus pratique appelé fsgrab (http://pobox.com/~aaronc/tech/fsgrab-1.0.tar.gz). Il permet d-accéder plus rapidement au données que la commande dd. Les explications qui suivent tiennent compte du fait que vous possédez l-utilitaire fsgrab.

Comme nous venons de le voir, lorsqu-un fichier est effacé le système libère les inodes occupés. La technique consiste donc à demander au système quels sont les inodes qui ont été libérés récemment. Pour cela, on utilise la commande lsdel de l-utilitaire debugfs et nous renvoyons la sortie dans un fichier.

Exemple : pour récupérer la liste des inodes libérés sur /dev/hda3 et l-enregistrer dans le fichier liste.txt on tape :

Dans cette liste, les inodes sont affichées avec la date et heure de suppression, leur taille, les permissions et propriétaire en numérique. Avec un peu de chance, vous les retrouverez facilement si vous avez réagit suffisamment vite.

Ces fichiers courts ont tous leurs données référencées dans le même inode et la procédure est simple. Voici un exemple tiré du Undeletion-mini-HOWTO. Une fois avoir repéré l-inode fra"chement effacé on utilise la commande stat de debugfs pour obtenir les statistiques :

Total des blocs : 6, les données peuvent donc être récupérées par cette méthode. Il suffit alors d-invoquer la commande dumb de debugfs pour envoyer les données dans un fichiers sur la partition de secours :

Le fichier recovered.000 ici créé dans le répertoire /mnt contiendra à la fin des données incorrectes. Pour corriger le problème, il vous faudra utiliser la commande dd pour ajuster la taille du fichier à celle des blocs.

Les problèmes de récupération de données arrivent avec les fichiers de plus de 12 blocs. Pour comprendre la raison du problème, voici comment le système gère les données importantes sur le disque.

ð Les numéros des 12 premiers blocs sont inscrits directement dans l-inode : il s-agit des blocs directs.

ð L-inode contient le numéro d-un bloc supplémentaire : le bloc indirect. Celui-ci contient 256 numéros de blocs de données.

ð L-inode contient le numéro d-un bloc doublement indirect. Il contient les numéros de blocs indirectes qui contiennent les numéro de blocs de données.

ð L-inode contient le numéro d-un bloc triplement indirect. Il contient les numéros de 256 blocs doublement indirects qui contiennent les numéros de blocs indirects qui eux-mêmes contiennent les numéros des blocs de données (ouf !).

Si cela ne vous parait pas très clair, c-est normal. Nous avons du relire à plusieurs reprises ces même lignes pour comprendre.

De ce fait, un fichier qui occupait plus de 12 blocs voit ses données éparpillées sur le disque. Il devient très difficile de récupérer les informations nécessaires pour reconstituer le fichier dans l-ordre original. Une méthode existe et est définie dans le Undeletion-mini-HOWTO.

Nous ne le dirons jamais assez : la seule manière sûre de récupérer vos données après avoir supprimé des fichiers, est d-utiliser vos sauvegardes. Les méthodes décrites ici sont complexes et laborieuses. Evitez-vous au maximum ces désagréments :

© Copyright 2000 Diamond Editions/Linux magazine France - Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; A copy of the license is included in the section entitled "GNU Free Documentation License"

Récupération des fichiers effacés