aaronc@pobox.comrm * ~.
Et, trop tard, vous remarquez l'espace en trop.
Vous avez d�truit votre oeuvre ma�tresse !
Mais, heureusement, vous avez de l'aide � port�e de main.
Ce document pr�sente une discussion de la r�cup�ration
de fichiers supprim�s depuis le Second syst�me de fichiers
�tendu ext2fs.
Esp�rez, peut-�tre pourrez-vous distribuer
votre programme malgr� tout...
Ce mini-HOWTO tente de fournir un certain nombre de conseils dans le but de r�cup�rer des fichiers supprim�s depuis un syst�me de fichiers ext2fs. Il contient �galement une petite discussion sur les mani�res de commencer par �viter de supprimer des fichiers.
Mon but est naturellement d'en faire une r�f�rence utile
� tous ceux qui ont eu un, disons... accident avec rm ;
mais cependant je souhaite que les gens le lisent de toute fa�on.
On ne sait jamais : un jour, les renseignements donn�s ici
pourraient vous sauver la couenne.
La lecture de ce texte suppose un minimum de connaissances sur les syst�mes de fichiers Unix ; je me suis cependant efforc� de le rendre accessible � la plupart des utilisateurs de Linux. Si vous �tes un grand d�butant, je crains que la r�cup�ration de fichiers sous Linux exige certaines connaissances techniques, ainsi que de la pers�v�rance, au moins dans l'�tat actuel des choses.
Il vous sera impossible de r�cup�rer des fichiers supprim�s
depuis un syst�me de fichiers ext2 sans au moins un acc�s
en lecture au p�riph�rique (fichier sp�cial) sur lequel
le fichier �tait plac�. En g�n�ral, cela signifie que
vous devez �tre root, mais plusieurs distributions (comme
Debian GNU/Linux) disposent
d'un groupe disk dont les membres ont ces acc�s.
Vous aurez �galement besoin
de la commande debugfs, du paquetage e2fsprogs,
qui devrait avoir �t� install� par votre distribution.
Pourquoi ai-je �crit ceci ? Principalement par exp�rience
personnelle, souvenir du d�sastre d'un rm -r
particuli�rement insens� en tant que root.
J'ai supprim� 97 fichiers JPEG dont j'avais besoin et que
je ne pouvais certainement pas r�cup�rer par ailleurs.
Suivant quelques conseils (voir la section
Remerciements et bibliographie)
et en pers�v�rant beaucoup, j'ai r�cup�r� 91 fichiers intacts.
Je suis parvenu � en retrouver, au moins en partie, cinq autres
(suffisamment pour voir quelle �tait l'image repr�sent�e par chacun).
Une seule n'�tait pas affichable, et m�me pour celle-l�,
je suis certain de n'avoir pas perdu plus de 1024 octets
(mais h�las depuis le d�but du fichier ;
sachant que je ne connais rien du format de fichier JFIF
j'ai vraiment fait ce que j'ai pu).
Je discuterai plus bas du taux de r�cup�ration que vous pouvez esp�rer pour les fichiers supprim�s.
Les r�visions de ce document (en version anglaise, NdT) d�livr�es au public, ainsi que leurs dates de publication, sont les suivantes :
Quels sont les nouveaut�s de cette version ? Primo, la r�flexion dans l'exemple de la r�cup�ration de fichiers a �t� corrig�e. Merci � tous ceux qui m'ont �crit pour me signaler mon erreur ; cela m'apprendra, je l'esp�re, � faire plus attention en inventant des s�quences interactives.
Secundo, la discussion sur le mod�le de syst�me de fichier Unix a �t� r�crite afin d'�tre (esp�rons-le) plus compr�hensible. Je n'en �tais pas enti�rement satisfait de prime abord, et d'aucuns se sont plaints de son manque de clart�.
Tertio, le gros-tas-de-tar-gzip-uu-encod� de fsgrab
au milieu du fichier a �t� retir�. Le programme est d�sormais
disponible sur
ma page et sur
Metalab
(et ses miroirs).
Quarto, le document a �t� traduit en langage sgml, utilis� par le Linux Documentation Project. Ce langage peut �tre facilement converti en un grand nombre d'autres langages (y compris HTML et LaTeX) pour un affichage et une impression simples et pratiques. Cela a pour avantage une belle typographie, dans le cas d'une �dition papier ; de plus, le document contient des r�f�rences et des liens bien commodes si vous le consultez sur le Web.
Cette r�vision est plut�t une augmentation. Elle inclut principalement des modifications propos�es par des lecteurs, dont l'une est particuli�rement importante.
Le premier changement a �t� sugg�r� par Egil Kvaleberg
egil@kvaleberg.no,
qui a signal� la commande dump dans debugfs.
Merci encore, Egil.
Le second changement a �t� de signaler l'utilisation
de chattr pour �viter de supprimer des fichiers importants.
Merci � Herman Suijs
H.P.M.Suijs@kub.nl
de l'avoir signal�.
Le r�sum� a �t� revu. Des URLs ont �t� ajout�es, qui indiquent des organisations ou des logiciels. Ajoutez � cela quelques modifications mineures (dont des corrections de fautes de frappe, etc.).
Bien qu'il se soit �coul� 17 mois depuis la derni�re version, bien peu
de choses ont chang�. Cette version corrige quelques erreurs mineures (fautes
de frappe, URL incorrectes, etc -- principalement le non-lien vers l'Open Group),
et les quelques paragraphes qui �taient devenus atrocement d�mod�s, comme ceux
sur les versions de noyau et lde, ont �t� revus. Oh, et j'ai remplac�
`Sunsite' par `Metalab' partout.
Cette version sera probablement la derni�re avant la version 2.0, qui sera un vrai HOWTO, du moins je l'esp�re. J'ai travaill� sur des changements d'importance qui m�ritent l'incr�mentation du num�ro de version majeure.
La version officielle la plus r�cente de ce document devrait �tre disponible au format texte aupr�s du site du Linux Documentation Project (et ses miroirs). La derni�re version est �galement disponible sur ma page sous divers formats :
Il est vital de se rappeler que Linux n'est pas semblable � MS-DOS en mati�re de r�cup�ration de donn�es. Pour MS-DOS (et son b�tard Windows 95), il est g�n�ralement tr�s simple de r�cup�rer un fichier supprim� : le � syst�me d'exploitation � (il faut le dire vite) est m�me accompagn� d'un utilitaire qui automatise la proc�dure. Ce n'est pas le cas de Linux.
Donc... r�gle num�ro un (ou premi�re directive, si vous pr�f�rez) :
FAITES DES SAUVEGARDES
peu importe comment. Pensez � toutes vos donn�es. Peut-�tre, comme moi, conservez-vous plusieurs ann�es d'archives de messages, contacts, documents sur votre ordinateur. Pensez au chamboulement dans votre vie si vous �tiez victime d'une panne de disque catastrophique, ou -- pire encore ! -- si un cracker nettoyait votre disque sans vergogne. Ce n'est pas si improbable ; j'ai correspondu avec un bon nombre de gens plac�s dans une telle situation. J'exhorte les utilisateurs sens�s de Linux de sortir acheter un p�riph�rique de sauvegarde, de planifier leurs sauvegardes dans un emploi du temps digne de ce nom et de s'y conformer. En ce qui me concerne, je me sers d'un disque d�di� sur une deuxi�me machine, et r�guli�rement je fais un mirroir de mon r�pertoire personnel par le r�seau. Pour plus d'information sur la planification des sauvegardes, lisez Frisch (1995) (voir la section Bibliographie et remerciements).
En l'absence de sauvegardes, que faire (en fait, m�me en pr�sence de sauvegardes : dans le cas de donn�es importantes, la ceinture et les bretelles, ce n'est pas du luxe) ?
Essayez de donner aux fichiers importants les droits 440 (ou moins) :
ne pas vous laisser les droits en �criture provoque une demande de
confirmation explicite de rm avant la destruction
(mais si je veux supprimer r�cursivement un r�pertoire
avec rm -r, j'interromprai le programme d�s la premi�re ou
deuxi�me demande de confirmation pour relancer la commande avec
rm -rf).
Un bon truc, pour les fichiers importants, est de cr�er un lien
physique vers eux dans un r�pertoire cach�. J'ai entendu parler
d'un administrateur syst�me qui, p�riodiquement, supprimait
accidentellement /etc/passwd (et par l�-m�me
d�truisait � moiti� le syst�me). Un des rem�des fut de lancer
en tant que root quelque chose comme :
# mkdir /.backup
# ln /etc/passwd /.backup
Il est alors assez difficile de supprimer compl�tement le contenu du fichier : si vous dites
# rm /etc/passwd
alors
# ln /.backup/passwd /etc
permettra de le r�cup�rer. Naturellement, cela ne couvre pas le cas o� vous avez �cras� le contenu du fichier par un autre fichier, donc de toutes fa�ons gardez vos sauvegardes.
Dans un syst�me de fichiers ext2, il et possible d'utiliser les
attributs ext2 dans le but de prot�ger ses donn�es.
Ces attributs sont manipul�s � l'aide de la commande chattr.
Il y a un attribut � ajout seulement � (append-only) : il est possible
d'ajouter des donn�es � un fichier ayant cet attribut, mais
pas de le supprimer, et le contenu du fichier ne peut pas �tre �cras�.
Si un r�pertoire a cet attribut, tous les fichiers et r�pertoires
qu'il contient peuvent �tre normalement modifi�s, mais aucun fichier
ne peut �tre supprim�. Cet attribut peut �tre plac� en tapant
$ chattr +a FICHIER...
Il existe aussi un attribut � immuable � (immutable), qui ne peut �tre plac� ou retir� qu'en tant que root. Un fichier ou r�pertoire ayant cet attribut ne peut �tre ni modifi�, ni supprim�, ni renomm�, ni se faire ajouter un lien (physique). Il peut �tre plac� comme suit :
# chattr +i FICHIER...
Ext2fs fournit �galement l'attribut � r�cup�rable � (undeletable,
option +u de chattr). Si un fichier ayant cet attribut est
supprim�, mais pas r�ellemnt r�utilis�, il est d�plac� vers un
� endroit s�r � afin d'�tre supprim� plus tard.
H�las, cette fonctionnalit� n'est pas encore implant�e dans les
noyaux courants ; et bien que, par la pass�, il y ait eu un peu d'int�r�t
concernant une implantation �ventuelle, elle n'est pas (� ma connaissance)
disponible pour les noyaux actuels.
Certains d�fendent l'id�e de faire de rm un alias ou une fonction
du gestionnaire de commandes qui ex�cute en fait rm -i
(qui demande confirmation pour tous les fichiers � supprimer).
En effet, certaines versions de la distribution
Red Hat le font par d�faut
pour tous les utilisateurs, y compris root. En ce qui me concerne,
je ne supporte pas les logiciels incapables de tourner tous seuls,
je ne le fais donc pas. Par ailleurs, un jour ou l'autre,
vous ferez tourner le programme en mode mono-utilisateur, ou
utiliserez un gestionnaire de commandes diff�rent, ou simplement
une autre machine, o� votre fonction rm n'existera pas.
Si vous vous attendez � une confirmation, il est assez facile
d'oublier o� vous �tes et sp�cifier un peu trop de fichiers �
supprimer. De m�me, les divers scripts et programmes servant �
remplacer rm sont, � mon humble avis, tr�s dangereux.
Une solution un peu meilleure serait de commencer � utiliser
un paquetage qui manipulerait une destruction � recyclable �
en fournissant une commande qui ne s'appellerait pas rm.
Pour plus de d�tails, voir Peek et al (1993)
(voir la section
Bibliographie et remerciements).
Cette solution a cependant l'inconv�nient d'encourager les utilisateurs
� avoir une attitude nonchalante vis-�-vis de la destruction, au lieu de
l'attitude circonspecte qui est souvent n�cessaire sous Unix.
�a d�pend. Parmi les probl�mes concernant la r�cup�ration de fichiers dans un syst�me d'exploitation de haute qualit�, multi-t�ches et multi-utilisateurs comme Linux, il se trouve que vous ne savez jamais quand quelqu'un veut �crire sur le disque. Donc, quand le syst�me d'exploitation re�oit l'ordre de supprimer un fichier, il suppose libres les blocs utilis�s par ce fichier au moment d'allouer de nouveau de la place pour un nouveau fichier (c'est un exemple typique d'un principe g�n�ral d'Unix : le noyau et les outils associ�s supposent que les utilisateurs ne sont pas des idiots). En g�n�ral, plus votre machine est utilis�e, moins vous avez de chances de r�cup�rer vos fichiers avec succ�s.
De plus, la fragmentation du disque peut affecter la facilit� de r�cup�ration. Si la partition contenant les fichiers supprim�s est tr�s fragment�e, vous avez peu de chances de pouvoir lire un fichier entier.
Si votre machine, comme la mienne, est effectivement une station destin�e � un seul utilisateur, et que vous n'utilisiez pas intensivement le disque au moment fatal de la destruction, je m'attendrais � un taux de r�cup�ration du m�me ordre de grandeur que d�crit pr�c�demment. J'ai r�cup�r� presque 94 % des fichiers, intacts (et il s'agissait de fichiers binaires, notez bien). Si vous obtenez plus de 80 %, vous pouvez �tre plut�t content de vous.
La proc�dure consiste principalement en la recherche de donn�es dans le p�riph�rique de la partition en mode caract�re, et en le fait de la rendre � nouveau visible par le syst�me d'exploitation. Il y a principalement deux mani�res de le faire : la premi�re consiste � modifier le syst�me de fichier existant de telle fa�on que les inodes supprim�s aient leur indicateur � supprim� � retir�, et esp�rer que les donn�es retombent comme par magie � leur place. L'autre m�thode, plus s�re mais plus lente, est de rechercher o� se trouvent les donn�es dans la partition et de les �crire dans un nouveau fichier.
Vous devez suivre plusieurs �tapes avant de commencer votre tentative de r�cup�ration ; voir les sections D�monter le syst�me de fichiers, Pr�parer la modification directe des inodes et Pr�parer l'�criture � un autre endroit pour plus de d�tails. Pour d�couvrir comment r�cup�rer r�ellement vos fichiers, voir les sections Trouver les inodes supprim�s, Obtenir des d�tails sur les inodes, R�cup�rer des blocs de donn�es et Modifier les inodes directement.
Quelle que soit la m�thode que vous choisissiez, la premi�re �tape consiste � d�monter le syst�me de fichiers contenant les fichiers supprim�s. Je vous conseille fortement de r�fr�ner toute envie de bricoler un syst�me de fichiers mont�. Cette �tape doit �tre effectu�e le plus t�t possible, d�s que vous vous �tes rendu compte que les fichiers sont supprim�s.
La m�thode la plus simple est la suivante : en supposant que les
fichiers supprim�s soient dans la partition /usr, tapez :
# umount /usr
Vous pouvez cependant avoir besoin de garder certaines donn�es
disponibles dans /usr. Dans ce cas, remontez-le
en mode lecture seule :
# mount -o ro,remount /usr
Si les fichiers supprim�s �taient dans la partition racine, vous devrez
ajouter une option -n, afin d'emp�cher que l'op�ration
de montage ne d�clenche une �criture dans /etc/mtab :
# mount -n -o ro,remount /
Ind�pendamment de tout cela, il est possible qu'un autre processus
utilise � ce moment-l� ce syst�me de fichier (ce qui fera �chouer le
montage avec une erreur du genre resource busy). Il y a un
programme qui peut envoyer un signal � tout processus utilisant un
fichier ou point de montage donn� : c'est fuser. Pour la partition
/usr, essayez ceci :
# fuser -v -m /usr
Cela aura pour effet d'afficher la liste des processus concern�s. En admettant qu'aucun d'entre eux n'est vital, vous pouvez taper
# fuser -k -v -m /usr
afin d'envoyer � chaque processus un SIGKILL (qui le tuera
d'autorit�), ou, par exemple,
# fuser -k -TERM -v -m /usr
pour envoyer plut�t � chacun un SIGTERM (qui priera
le processus de terminer proprement).
Mon conseil ? Ne faites pas �a. Je ne pense vraiment pas qu'il soit raisonnable d'esp�rer un r�sultat en jouant avec un syst�me de fichiers � un si bas niveau. Du reste, vous ne pourrez r�cup�rer de fa�on fiable que les 12 premiers blocs de chaque fichier. Donc, si vous avez des fichiers longs � r�cup�rer, vous devrez de toute fa�on utiliser l'autre m�thode (mais lisez tout de m�me la section Cela va-t-il se simplifier dans l'avenir~? pour plus d'information).
Si vous sentez que vous devez le faire de cette mani�re, je vous conseille de copier les donn�es de la partition en mode caract�re dans une autre partition, puis monter le tout en utilisant le p�riph�rique boucle (loopback device) :
# cp /dev/hda5 /root/working
# mount -t ext2 -o loop /root/working /mnt
(Notez que les anciennes versions de mount peuvent avoir des probl�mes
pour faire cela. Si votre mount ne fonctionne pas, je vous recommande
fortement de vous procurer la derni�re version, ou tout au moins la version
2.7, car plusieurs versions plus anciennes ont de graves probl�mes de
s�curit�).
Le but de la manoeuvre est que, quand vous aurez enti�rement d�truit le syst�me de fichiers (ce que vous ferez tr�s probablement), il ne vous restera plus qu'� copier la partition dans l'autre sens et repartir � nouveau.
Vous devez vous assurer d'avoir quelque part une partition de secours.
Esp�rons-le, votre syst�me a plusieurs partitions : peut-�tre une
racine, une /usr, et une /home. Avec tout ce choix,
aucun probl�me : cr�ez simplement un nouveau r�pertoire dans l'une
d'entre elles.
Si vous n'avez qu'une partition racine dans laquelle vous fourrez tout, �a risque d'�tre un poil plus d�licat. Peut-�tre avez-vous une partition MS-DOS ou Windows que vous pourriez utiliser ? Ou vous avez le gestionnaire ramdisk dans votre noyau, peut-�tre en module ? Pour utiliser le ramdisk (en supposant que votre noyau soit plus r�cent que 1.3.48), tapez les commandes suivantes :
# dd if=/dev/zero of=/dev/ram0 bs=1k count=2048
# mke2fs -v -m 0 /dev/ram0 2048
# mount -t ext2 /dev/ram0 /mnt
Cela a pour effet de cr�er un volume ramdisk de 2 Mo,
et de le monter en /mnt.
Un petit mot d'avertissement : si vous utilisez kerneld (ou son
rempla�ant kmod avec les noyaux 2.2.x et les derniers 2.1.x) pour
charger et d�charger automatiquement les modules du noyau,
alors ne d�montez pas le ramdisk tant que vous n'avez pas copi�
tous les fichiers qu'il contient sur un support non volatile.
Une fois que vous l'aurez d�mont�, kerneld suppose qu'il peut
d�charger le module (apr�s la p�riode d'attente habituelle),
et, d�s qu'il l'a fait, la m�moire est r�utilis�e par d'autres
�l�ments du noyau, causant la perte irr�m�diable des heures de travail
que vous aurez pass�es � r�cup�rer soigneusement vos donn�es.
Si vous avez un lecteur Zip, Jaz, ou LS-120, ou quelque chose d'�quivalent, il s'agit probablement d'une bonne place pour une partition de secours. Sinon, il faudra faire avec les disquettes.
Une autre chose dont vous devriez avoir besoin est un programme
capable de lire les donn�es n�cessaires en plein milieu
du p�riph�rique contenant la partition. � la rigueur, dd
pourrait le faire, mais pour lire � partir de, disons, 600 Mo dans une
partition de 800 Mo, dd tient � lire les 600 premiers m�gaoctets,
quitte � les ignorer, et il va y passer un temps non n�gligeable, m�me sur
des disques rapides.
Pour �viter cela, j'ai �crit un programme qui peut se positionner
en plein milieu de la partition. Il s'appelle fsgrab ;
vous pouvez trouver le paquetage des sources sur
ma page,
ou sur
Metalab
(et ses miroirs). Si vous souhaitez utiliser cette m�thode, la suite
de ce mini-HOWTO suppose que vous avez fsgrab.
Si aucun des fichiers que vous voulez r�cup�rer n'occupe plus de
12 blocs (o� un bloc occupe habituellement un kilooctet),
alors vous n'aurez pas besoin de fsgrab.
Si vous avez besoin de fsgrab mais n'en voulez pas, il est
fort simple de traduire une ligne de commande avec fsgrab
en une avec dd. Si on a
fsgrab -c count -s skip device
alors la commande dd correpondante (et g�n�ralement beaucoup plus
lente) est
dd bs=1k if=device count=count skip=skip
Je dois vous avertir que, bien que fsgrab ait parfaitement
fonctionn� pour moi, je ne puis prendre aucune responsabilit� sur
son comportement. C'�tait vraiment une bidouille rapide et sale
pour arriver � mes fins. Pour plus de d�tails sur l'absence de
garantie, consultez la section No Warranty dans le fichier
COPYING inclus dans la distribution (li s'agit de la GPL, la licence
publique g�n�rale GNU).
L'�tape suivante consiste � demander au syst�me de fichiers
quels inodes ont �t� r�cemment lib�r�s. C'est une t�che que
vous pouvez accomplir avec debugfs. Lancez debugfs avec
le nom du p�riph�rique sur lequel le syst�me de fichiers r�side :
# debugfs /dev/hda5
Si vous souhaitez modifier les inodes directement, ajoutez une option
-w de mani�re � activer l'�criture sur le syst�me de fichiers :
# debugfs -w /dev/hda5
La commande debugfs permettant de trouver les inodes d�truits est
lsdel. Donc, tapez la commande suivante � l'invite :
debugfs: lsdel
Apr�s moult grincements et g�missements du disque, une longue liste
est envoy�e par un pipe � votre pager favori (la valeur de
$PAGER). Maintenant vous aurez envie d'en sauver une copie
autre part. Si vous avez less, vous pouvez taper -o suivi
du nom du fichier qui devra contenir le r�sultat. Sinon, vous devrez
vous arranger pour envoyer la sortie ailleurs. Essayez ceci :
debugfs: quit
# echo lsdel | debugfs /dev/hda5 > lsdel.out
Maintenant, d'apr�s la date et l'heure de la suppression, la taille, le type et les indications num�riques des permissions et propri�taire, vous devez deviner quelles inodes supprim�s vous voulez. Avec un peu de chance, vous les trouverez tout de suite parce c'est le gros paquet que vous avez supprim� il y a � peine cinq minutes. Sinon, prenez bien garde en allant p�cher dans la liste.
Je vous sugg�re, autant que possible, d'imprimer la liste des inodes que vous voulez r�cup�rer. Cela vous facilitera nettement la vie.
debugfs a une commande stat, qui imprime des d�tails
sur un inode. Utilisez la commande pour chacun des inodes de votre
liste � r�cup�rer. Par exemple, si vous �tes int�ress� par l'inode
num�ro 148003, essayez ceci :
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
Si vous avez de nombreux fichiers � r�cup�rer, vous souhaiterez
automatiser tout cela. En suposant que votre liste (d'apr�s lsdel)
d'inodes � r�cup�rer est dans lsdel.out, essayez ceci :
# cut -c1-6 lsdel.out | grep "[0-9]" | tr -d " " > inodes
Ce nouveau fichier inodes contient uniquement les num�ros des
inodes � r�cup�rer, � raison d'un par ligne. On le sauvegarde parce
qu'il va nous �tre s�rement tr�s utile par la suite. Il ne vous reste
plus qu'� taper :
# sed 's/^.*$/stat <\0>/' inodes | debugfs /dev/hda5 > stats
et stats contient la sortie de toutes les commandes stat.
Cette partie est soit tr�s facile, soit nettement moins, selon que les fichiers que vous essayez de r�cup�rer occupent moins ou plus de 12 blocs.
Si le fichier n'occupait pas plus de 12 blocs, alors les num�ros de
blocs o� sont situ�es toutes ses donn�es sont �crits
dans l'inode : vous pouvez les lire directement sur la sortie de
stat correspondant � l'inode. De surcro�t, debugfs a
une commande qui automatise cette t�che. Pour reprendre l'exemple pr�c�dent :
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
Ce fichier a six blocs. Puisqu'il est en-dessous de la limite des 12,
nous demandons � debugfs d'�crire le fichier dans un nouvel
endroit, comme par exemple /mnt/recovered.000 :
debugfs: dump <148003> /mnt/recovered.000
Bien s�r, on peut faire �a aussi avec fsgrab ; je le montre ici
en guise d'exemple d'utilisation :
# fsgrab -c 2 -s 594810 /dev/hda5 > /mnt/recovered.000
# fsgrab -c 4 -s 594814 /dev/hda5 >> /mnt/recovered.000
Que ce soit avec debugfs ou avec fsgrab, il y aura un peu
de d�chet � la fin de /mnt/recovered.000, mais ce n'est pas
tr�s important. Si vous voulez vous en d�barrasser, la m�thode la
plus simple est de prendre le champ Size de l'inode, et le
brancher sur l'option bs d'une ligne de commande dd.
# dd count=1 if=/mnt/recovered.000 of=/mnt/resized.000 bs=6065
Bien s�r, il est possible qu'un ou plusieurs blocs o� �tait �crit votre fichier aient �t� �cras�s. Si c'est le cas, pas de chance : le bloc est mort et enterr� (rendez-vous compte, si seulement vous aviez d�mont� plus t�t !).
Les probl�mes apparaissent lorsque le fichier tient sur plus de 12 blocs de donn�es. Ici, il vaut mieux en savoir un peu sur la mani�re dont sont structur�s les syst�mes de fichiers Unix. Les donn�es du fichier sont stock�es dans des unit�s appel�es � blocs �. Ces blocs peuvent �tre num�rot�s s�quentiellement. Un fichier a �galement un � inode �, o� sont plac�es des informations telles que propri�taire, permissions ou type. Comme les blocs, les inodes sont num�rot�s s�quentiellement, bien que la s�quence soit diff�rente. Une entr�e de r�pertoire consiste en un nom de fichier associ� � un num�ro d'inode.
Mais, si on en restait l�, le noyau ne saurait toujours pas trouver les donn�es correspondant � une entr�e de r�pertoire. Ainsi l'inode indique �galement l'endroit o� se trouvent les blocs de donn�es du fichier, comme suit :
Relisez bien tout �a : je sais que c'est compliqu�, mais c'est important, aussi.
Maintenant, l'implantation du noyau pour toutes les versions actuelles (2.0.36 inclue) efface malheureusement tous les blocs indirects (et doublement indirects, etc.) lors de la suppression d'un fichier. Alors, si votre fichier occupait plus de 12 blocs, vous n'�tes pas garanti de pouvoir retrouver les num�ros de tous les blocs dont vous avez besoin (sans parler de leur contenu).
La seule m�thode que j'aie pu trouver jusqu'ici consiste � supposer que le fichier n'est pas fragment� : s'il l'est, vous aurez des ennuis. En supposant que le fichier n'est pas fragment�, il y a plusieurs dispositions de blocs de donn�es, selon le nombre de blocs de donn�es utilis�s par le fichier :
les num�ros de bloc sont indiqu�s dans l'inode, comme d�crit pr�c�demment ;
apr�s les blocs directs, comptez un pour le bloc indirect, puis vous avez 256 blocs de donn�es ;
comme avant, il y a 12 blocs directs, un bloc indirect (inutile), et 256 blocs. Ils sont suivis d'un bloc doublement indirect (inutile), et 256 r�p�titions de : un bloc indirect (inutile) et 256 blocs de donn�es ;
la disposition des 65804 premiers blocs est identique � ce qui est d�crit di-dessus. Suivent un bloc triplement indirect (inutile) et 256 r�p�titions d'une s�quence � doublement indirect �. Chaque s�quence doublement indirecte consiste en un bloc doublement indirect (inutile), suivi de 256 r�p�titions de : un bloc indirect (inutile) et 256 blocs de donn�es.
Bien entendu, m�me si ces blocs sont suppos�s corrects, rien ne garantit que les donn�es qu'ils contiennent sont intactes. De plus, plus le fichier est long, moins vous avez de chances qu'il ait pu �tre �crit dans le syst�me de fichiers sans fragmentation raisonnable (sauf dans certaines circonstances particuli�res).
Notez que j'ai suppos� depuis le d�but que vos blocs occupaient la taille de 1024 octets, c'est-�-dire la valeur standard. Si vos blocs sont plus grands, une partie des nombres �crits plus haut doivent �tre chang�s. Typiquement, puisque chaque num�ro de bloc occupe 4 octets, le nombre de num�ros de bloc pouvant �tre plac�s dans chaque bloc indirect est taille_du_bloc/4. Donc, chaque fois que le nombre 256 appara�t dans la dicussion qui pr�c�de, remplacez-le par taille_du_bloc/4. Les limitations � nombre de blocs requis � devront �galement �tre modifi�es.
Examinons un exemple de r�cup�ration de fichier plus long.
debugfs: stat <1387>
Inode: 148004 Type: regular Mode: 0644 Flags: 0x0 Version: 1
User: 503 Group: 100 Size: 1851347
File ACL: 0 Directory ACL: 0
Links: 0 Blockcount: 3616
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:
8314 8315 8316 8317 8318 8319 8320 8321 8322 8323 8324 8325 8326 8583
TOTAL: 14
Il semble y avoir de bonnes chances pour que ce fichier ne soit pas fragment� : de fa�on �vidente, les 12 premiers blocs list�s dans l'inode (qui sont tous des blocs de donn�es) sont contigus. Nous pouvons donc commencer par r�cup�rer ces blocs :
# fsgrab -c 12 -s 8314 /dev/hda5 > /mnt/recovered.001
Maintenant, le bloc suivant list� dans l'inode, 8326, est un bloc indirect, que nous pouvons ignorer. Mais nous nous fions � notre intuition qu'il sera suivi de 256 blocs de donn�es (du num�ro 8327 au num�ro 8582).
# fsgrab -c 256 -s 8327 /dev/hda5 >> /mnt/recovered.001
Le dernier bloc list� dans l'inode est le 8583. Notez que �a ressemble toujours bien � un fichier contigu : le num�ro du dernier bloc que nous ayons �crit �tait le 8582, donc 8327 + 255. Ce bloc 8583 est un bloc doublement indirect, que nous pouvons ignorer. Il est suivi par jusqu'� 256 r�p�titions d'un bloc indirect (ignor�) suivi de 256 blocs de donn�es. Apr�s un petit calcul mental, on en d�duit les commandes suivantes. Remarquez qu'on saute le bloc doublement indirect 8583 et le bloc indirect 8584, qui suivent imm�diatement (esp�rons-le) et qu'on commence directement � lire les donn�es depuis le bloc 8585.
# fsgrab -c 256 -s 8585 /dev/hda5 >> /mnt/recovered.001
# fsgrab -c 256 -s 8842 /dev/hda5 >> /mnt/recovered.001
# fsgrab -c 256 -s 9099 /dev/hda5 >> /mnt/recovered.001
# fsgrab -c 256 -s 9356 /dev/hda5 >> /mnt/recovered.001
# fsgrab -c 256 -s 9613 /dev/hda5 >> /mnt/recovered.001
# fsgrab -c 256 -s 9870 /dev/hda5 >> /mnt/recovered.001
En rassemblant tout, on voit qu'on a �crit depuis le d�but 12 + (7 * 256) blocs, c'est-�-dire 1804. La commande � stat � nous a indiqu� pour l'inode un � blockcount � de 3616 ; mais ces blocs occupaient malheureusement 512 octets (un reliquat d'Unix), ce que nous voulons r�ellement est alors 3616/2 = 1808 blocs de 1024 octets. Cela signifie que nous avons seulement besoin de quatre blocs de plus. Le dernier bloc de donn�es �crit portait le num�ro 10125. De la m�me fa�on que depuis le d�but, on saute un bloc indirect (num�ro 10126) ; on peut alors �crire ces quatre derniers blocs.
# fsgrab -c 4 -s 10127 /dev/hda5 >> /mnt/recovered.001
Et maintenant, avec un peu de chance, le fichier complet a �t� r�cup�r� avec succ�s.
Cette m�thode est apparemment beaucoup plus facile. Cependant, comme soulign� plus haut, elle ne peut pas venir � bout de fichiers occupant plus de 12 blocs.
Pour chaque inode que vous voulez r�cup�rer, vous devez mettre � 1
le nombre de liens, et � 0 la date de suppression.
Cela peut �tre fait gr�ce � la commande mi (modifier
inode) de debugfs. Voici un exemple de sortie concernant
la modification de l'inode 148003 :
debugfs: mi <148003>
Mode [0100644]
User ID [503]
Group ID [100]
Size [6065]
Creation time [833201524]
Modification time [832708049]
Access time [826012887]
Deletion time [833201524] 0
Link count [0] 1
Block count [12]
File flags [0x0]
Reserved1 [0]
File acl [0]
Directory acl [0]
Fragment address [0]
Fragment number [0]
Fragment size [0]
Direct Block #0 [594810]
Direct Block #1 [594811]
Direct Block #2 [594814]
Direct Block #3 [594815]
Direct Block #4 [594816]
Direct Block #5 [594817]
Direct Block #6 [0]
Direct Block #7 [0]
Direct Block #8 [0]
Direct Block #9 [0]
Direct Block #10 [0]
Direct Block #11 [0]
Indirect Block [0]
Double Indirect Block [0]
Triple Indirect Block [0]
C'est-�-dire que je mets � 0 la date de suppression et le nombre de liens � 1, puis j'envoie juste un retour chariot pour chacun des autres champs. D'accord, ce n'est pas tr�s souple si vous avez beaucoup de fichiers � r�cup�rer, mais je pense que vous pourrez faire face. Si vous vouliez du velours, il fallait utiliser un � syst�me d'exploitation � graphique avec une jolie � corbeille �.
� propos, le texte de sortie de mi indique un champ
� cr�ation � (creation time). Il est totalement mensonger
(ou en tout cas trompeur) ! En fait, sur un
syst�me de fichiers Unix, vous ne pouvez pas d�terminer quand un
fichier a �t� cr��. Le champ st_ctime d'une struct stat
fait r�f�rence � la date de modification de l'inode (inode change
time), c'est-�-dire la derni�re fois qu'un quelconque des d�tails
de l'inode a �t� chang�. Si finit la lessons d'huy.
Notez que les versions plus r�centes de debugfs que celle
que j'utilise n'incluent probablement pas certains des champs de
la liste donn�e plus haut (typiquement Reserved1 et
des champs sur les fragments).
Une fois que vous aurez modifi� les inodes, vous pourrez quitter
debugfs et taper :
# e2fsck -f /dev/hda5
L'id�e est que chacun des fichiers supprim�s a �t� litt�ralement
� d�-supprim� �, mais qu'aucun d'entre eux n'appara�t en entr�e
de r�pertoire. Le programme e2fsck peut le d�tecter, et
ajoutera une entr�e dans le r�pertoire /lost+found
du syst�me de fichiers (Donc, si la partition est normalement
mont�e dans /usr, les fichiers vont appara�tre dans
/usr/lost+found). Tout ce qui reste � faire est de
redonner son nom � chaque fichier d'apr�s son contenu, et le
remettre � sa place dans l'arborescence du syst�me de fichiers.
Quand vous lancerez e2fsck, vous obtiendrez des messages
d'information, ainsi que des questions � propos des probl�mes
� r�parer. R�pondez oui (yes) partout o� vous voyez
`summary information' ou � chaque r�f�rence aux inodes que
vous avez modifi�s. Tout le reste vous regarde, bien qu'il soit
en g�n�ral une bonne id�e de r�pondre oui � toutes les questions.
Lorsque e2fsck a termin�, vous pouvez remonter le syst�me
de fichiers.
En fait, il y a un autre moyen que de demander � e2fsck de
laisser les fichiers dans /lost+found : vous pouvez utiliser
debugfs pour cr�er un lien vers l'inode dans le syst�me de
fichiers. Utilisez la commande link de debugfs quand
vous avez fini de modifier l'inode.
debugfs: link <148003> toto.txt
Ceci cr�e un fichier appel� toto.txt dans ce que debugfs
suppose �tre le r�pertoire courant ; toto.txt sera votre
fichier. Vous aurez quand m�me besoin de lancer e2fsck
pour corriger le `summary information', le nombre de blocs, etc.
Oui. En fait, je pense que c'est d�j� le cas. Bien qu'au moment o� ces lignes sont �crites (2 f�vrier 1999), les noyaux stables actuels (la s�rie 2.0.x) effacent les blocs indirects, ce n'est plus le cas des noyaux de d�veloppement 2.1.x, ni des noyaux stables 2.2.x, dont le 2.2.1 qui vient d'�tre diffus� ; nous allons voir appara�tre des distributions � base de noyaux 2.2.x d'ici un ou deux mois.
Une fois cette limitation retir�e des noyaux stables, bon nombre de mes
objections au fait de modifier les inodes � la main dispara�tront.
Il sera �galement possible
d'utiliser la commande dump de debugfs sur des fichiers
longs, et d'utiliser d'autres outils de r�cup�ration.
En fait, il y en a. H�las, je crains qu'ils souffrent du m�me probl�me que la technique de modification manuelle des inodes : les blocs indirects sont irr�cup�rables. Cependant, selon la probabilit� que cela ne soit plus un probl�me d'ici peu, �a vaut s�rement le coup de chercher ces programmes maintenant.
J'ai �crit un utilitaire nomm� e2recover, qui est essentiellement un
enrobage Perl � fsgrab. Il fait un effort raisonnable pour g�rer les
blocs indirects effac�s, et semble tr�s bien fonctionner en l'absence de
fragmentation. Il en profite pour remettre les permissions (et, quand c'est
possible, le propri�taire) des fichiers r�cup�r�s, et s'assure m�me que les
fichiers r�cup�r�s soient � la bonne taille.
J'ai initialement �crit e2recover pour la toute proche mise � jour de ce
Howto ; malheureusement cela signifie que tous les renseignements utiles
sur e2recover sont aussi pr�vus pour cette mise � jour. En attendant, il
devrait s'av�rer quand m�me utile d�s maintenant ; vous pouvez le t�l�charger
depuis
ma page, et
prochainement sur Metalab.
Scott D. Heavner est l'auteur de lde, (`Linux Disk Editor'). lde peut
servir aussi bien d'�diteur binaire de disque, que d'un �quivalent de
debugfs pour les syst�mes ext2 et minix, et m�me pour les syst�mes xia
(bien que le support xia ne soit plus disponible dans les noyaux 2.1.x et
2.2.x). Il dispose de fonctionnalit�s pour faciliter la r�cup�ration, comme
le parcours de la liste des blocs, et la recherche dans le contenu du disque.
Il poss�de �galement une documentation sur
les concepts de base des syst�mes de fichiers particuli�rement utile,
ainsi qu'un document expliquant comment l'utiliser afin de
r�cup�rer des fichiers supprim�s.
La version 2.4 de lde est disponible sur
Metalab et ses mirroirs, et sur
la page de son auteur.
Une autre possibilit� est fournie par le GNU
Midnight Commander, mc. C'est un gestionnaire de fichiers
en plein �cran, inspir� autant que je le sache d'un certain
programme MS-DOS couramment d�sign� sous le nom de � nc �.
mc supporte la souris dans la console Linux et dans un xterm,
et fournit des syst�mes de fichiers virtuels qui permettent des
trucs du genre de se d�placer dans une archive Tar. Parmi ses
syst�mes de fichiers virtuels, il en est un concernant la
r�cup�ration sous Ext2. Tout �a semble tr�s commode � manipuler,
mais je dois avouer que que je ne l'ai jamais utilis� moi-m�me
-- je pr�f�re les bonnes vieilles commandes shell.
Apparemment il faut configurer le programme avec l'option
--with-ext2undel ; vous aurez �galement besoin des
biblioth�ques de d�veloppement et des fichiers d'en-t�te
(include) qui viennent avec le paquetage e2fsprogs.
La version fournie par
Debian GNU/Linux est ainsi compil� ; c'est peut-�tre le cas pour
d'autres distributions. Une fois que le programme est compil�, vous
pouvez y taper cd undel:/dev/hda5/, et obtenir, sous forme
de contenu de r�pertoire, le catalogue des fichiers supprim�s.
Comme la plupart des outils actuels de r�cup�ration, il g�re tr�s mal les blocs
indirects effac�s -- la plupart du temps il ne r�cup�re que les 12 premiers
Ko des gros fichiers.
La derni�re version peut �tre r�cup�r�e depuis le site ftp officiel.
J'ai l'intention de produire des mises � jour r�guli�res de ce document, tant que j'aurai � la fois suffisamment de temps pour le faire et quelque chose d'int�ressant � dire. Ceci signifie que je suis avide de commentaires de la part de mes lecteurs. Ma r�daction peut-elle �tre plus claire ? Pouvez-vous penser � quelque chose qui pourrait rendre l'affaire plus simple ? Existe-t-il un nouvel outil qui puisse faire tout cela automatiquement ?
Quoi qu'il en soit : si vous avez quoi que ce soit � dire, � propos
de ce document ou des outils fsgrab et e2recover, envoyez-moi
un mot � :
Si j'ai vu plus loin que d'autres, c'est parce que j'�tais hiss� sur des �paules de g�ants (Isaac Newton)
Une grande partie de ce mini-Howto est d�riv�e d'un article
post� sur le groupe de news
comp.os.linux.misc
par Robin Glover
swrglovr@met.rdg.ac.uk.
Je voudrais remercier Robin de m'avoir gracieusement autoris� � reprendre ses id�es dans ce mini-Howto.
Je voudrais �galement profiter de l'occasion pour remercier une fois de plus toutes les personnes qui m'ont contact� � propos de ce Howto. Ce sont les remerciements chaleureux que l'on re�oit qui justifient la peine que l'on se donne.
Quelques r�f�rences bibliographiques :
Toutes les marques d�pos�es sont la propri�t� de leurs auteurs respectifs. Sp�cifiquement :
Ce document est Copyright � 1997, 1999 Aaron Crane
aaronc@pobox.com.
Il peut �tre librement et enti�rement redistribu� � condition d'y
inclure toujours la totalit� de cette note de copyright, mais ne
peut pas �tre modifi� sans l'autorisation, soit de son auteur,
soit du coordinateur du Linux Documentation Project.
Une d�rogation est cependant accord�e dans le cas de la copie de
courts extraits sans modification pour des revues ou une citation ;
dans ces circonstances, les sections peuvent �tre reproduites
accompagn�es d'une citation appropri�e mais sans cette note de copyright.
L'auteur demande, mais n'exige pas, que des parties souhaitant vendre des copies de ce document, sur un medium lisible par un ordinateur ou par un humain, informent de leurs intentions, soit l'auteur, soit le coordinateur des HOWTO Linux.
Le coordinateur des HOWTO Linux est actuellement Tim Bynum
linux-howto@metalab.unc.edu.