Récupération des fichiers effacés

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.

PRUDENCE EST MERE DE SURETE

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).

THEORIE ET ESPERANCES

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.

RECUPERATION

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 :

Démontage du système de fichiers

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.

Préparatifs à la récupération

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 :

dd if=/dev/zero of=/dev/ram0 bs=1k count=2048

Ceci créera un ramdisk de 2 Mo

mke2fs -v -m 0 /dev/ram0 2048

Pour formater le ramdisk

mount -t ext2 /dev/ram0 /mnt

Pour finalement monter le ramdisk dans le répertoire /mnt.

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.

Recherche des blocs

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 :

echo lsdel | debugfs /dev/hda3 > liste.txt

Un conseil : imprimez cette liste.

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.

Récupération des données d-un fichier de moins de 12 blocs

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 :

debugfs: stat <148003>

Inode: 148003 Type: regular Mode: 0644 Flags: 0x0 Version: 1

User: 503 Group: 100 Size: 6065

File ACL: 0 Directory ACL: 0

Links: 0 Blockcount: 12

Fragment: Address: 0 Number: 0 Size: 0

ctime: 0x31a9a574 - Mon May 27 13:52:04 1996

atime: 0x31a21dd1 - Tue May 21 20:47:29 1996

mtime: 0x313bf4d7 - Tue Mar 5 08:01:27 1996

dtime: 0x31a9a574 - Mon May 27 13:52:04 1996

BLOCKS:

594810 594811 594814 594815 594816 594817

TOTAL: 6

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 :

debugfs: dump <148003> /mnt/recovered.000

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.

Exemple :

dd count=1 if=/mnt/recovered.000 of=/mnt/resized.000 bs=6065

Le fichier resized.000 obtenu doit, cette fois ci, être correcte.

LE CAS PARTICULIER

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.

CONCLUSION

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 :

FAITES DES SAUVEGARDES ! n


© 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"