EDIT
Il semblerait que partclone permette aussi de créer le fichier domaine, sur plusieurs systèmes de fichiers, avec la syntaxe :
sudo partclone.FSTYPE -s /dev/sdX_1 -D --offset_domain=1048576 -o ./domain.log
L’option -s (sdX_1) précise la source, c’est-à-dire la partition à cartographier (par ex sdb1 ou loop0p1),
-D précise que nous souhaitons créer un fichier de domaine,
l’offset calculé de la même manière qu’expliqué plus loin dans l’article (et utile seulement si on dumpe le disque entier),
-o nomme le fichier de sortie.
A noter que le fichier créé est par défaut non lisible par les non-root. De plus; le fichier de domaine n’intégrera pas (contrairement à ddrutility) les zones à lire pour identifier correctement la table de partition et les débuts/fins de partitions.
———
Cet article se penche sur l’utilisation de ddrutility pour créer un fichier de carte de domaine à utiliser avec ddrescue, afin de focaliser ce dernier sur les secteurs qui contiennent effectivement des données. Dans cet exemple, je ne parle que du ntfs.
L’ensemble d’utilitaires ddrutility peut être installé depuis les dépôts Debian à partir de Buster, ou bien compilé depuis la source disponible ici.
L’utilitaire qui nous intéresse : ddru_ntfsbitmap qui va créer un fichier de domaine, c’est-à-dire une liste des secteurs à lire sur la partition ntfs (secteurs effectivement utilisés). Concrètement, ce fichier a le même format qu’un fichier mapfile de ddrescue, mais où les secteurs censés contenir des données sont déterminés grâce à l’analyse du MBR et de la MFT, et sont marqués comme “finished” (lus), bien que rien ne soit effectivement lu.
Ceci ne fonctionnera que si ddrescuelog est présent dans la release de ddrescue (à partir de la version 1.15, normalement)
Création du fichier de délimitation du domaine
Voici la syntaxe pour une partition seule :
sudo ddru_ntfsbitmap /dev/sdX1 ./domain_ntfs.log
Dans mon cas, j’ai l’habitude de dumper le disque en entier, y compris la table de partitions. Pour ceci, il faut calculer l’offset de la partition (en octets) avec des maths assez simples : multiplier le secteur de démarrage de la partition par la taille d’un secteur en octets. Pour ceci : sudo fdisk -lu /dev/sdX qui nous donne par exemple :
Disk /dev/sdX: 465,7 GiB, 500074283008 bytes, 976707584 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0004a183
Device Boot Start End Sectors Size Id Type
/dev/sdX1 2048 976707583 976705536 465,7G 7 HPFS/NTFS/exFAT
On voit que la partition démarre au secteur 2048, et que chaque secteur (logique) pèse 512 bytes (octets).
Dans le cas où les valeurs logique et physique sont différentes, il faut prendre la valeur logique.
On multiplie donc : 2048*512 = 1048576, puis on passe l’argument -i à ddrutility, ce qui donne la commande
sudo ddru_ntfsbitmap /dev/sdX ./domain_ntfs.log -i 1048576
Ceci va aller lire le secteur de boot de la partition ntfs, puis la section bitmap afin de déterminer quels sont les clusters sur lesquels des données sont stockées.
Selon la doc de ddrutility, si des secteurs du bitmap sont illisibles, alors ddrutility va les remplir avec le motif 0xFF (soit uniquement des 1), ce qui signifie que les secteurs en question sont utilisés pour stocker des données. Ainsi, en l’absence de certitude (grâce à la lecture correcte du bitmap) qu’un secteur est inutilisé, alors il sera extrait par ddrescue. On a ainsi le “risque” de lire des secteurs inutilisés, mais beaucoup moins de risque de sauter des secteurs sur lesquels des données sont effectivement stockées !
On obtient plusieurs fichiers en résultat :
-
__bootsec qui est un dump du secteur de boot de la partition (et est utilisé pour trouver l’emplacement de la MFT
-
__bootsec.log : la mapfile ddrescue utilisée pour l’extraction du secteur de boot
-
__mftshort : dump de la MFT
-
__mftshort.log : mapfile utilisée par ddrescue pour dumper la MFT
-
__bitmapfile : dump du fichier $BitMap de la partition
-
_partX__bitmapfile.log : fichier mapfile utilisé par ddrescue pour dumper le fichier $BitMap. Il est possible qu’il y en ait plusieurs si le fichier $BitMap est fragmenté
-
ntfsbitmap_rescue_report.log : résumé des différentes passes de ddru
-
domain_ntfs.log : le fichier à donner à ddrescue lors de la réelle tentative de récupération de données. Le nom dépend de la ligne de commande invoquée.
Utilisation de ce fichier avec ddrescue
Il faut impérativement penser à accorder la ligne de commande ddrescue avec celle utilisée par ddrutility pour obtenir le fichier domaine. Notamment déterminer si on dumpe une partition ou bien un disque entier. Dans mon cas, c’est un disque entier.
Une fois le fichier obtenu, on peut lancer la récupération de données avec ddrescue avec l’option -m, comme ceci :
sudo ddrescue -m ./domain_ntfs.log /dev/sdX ./disk_image.img mapfile.log
Si on souhaite suivre l’avancement en graphique avec ddrescueview, il est possible dans le menu de ce dernier d’ouvrir une mapfile de domaine (et séléctionner domain_ntfs.log). Ainsi, le secteurs hors domaine seront coloriés en grisé.
À noter qu’il est possible de combiner cette méthode avec ddrescue sans carte de domaine, en utilisant le même fichier source (disque défectueux), la même destination et la même mapfile. Après avoir laissé tourner ddrescue séquentiellement sur le disque, et une récupération extremement lente (quelques ko/s), j’ai repris l’avancement en cours en rajoutant l’argument de la carte de domaine. Il est également possible de reprendre le dump du disque sans carte de domaine une fois que tous les secteurs sur la carte de domaine ont été correctement récupérés (même si cela devrait théoriquement être inutile).
Analyse des secteurs défectueux pour connaître les fichiers affectés
Le disque dur sur lequel je travaillais m’a donné un taux de récupération supérieur à 99%, mais toutefois incomplet.
Pour connaître la liste des fichiers dont certains secteurs peuvent être manquants, ddrutility propose un autre utilitaire, ddru_ntfsfindbad.
Bien qu’il puisse fonctionner directement sur le disque, il est plutôt prévu pour être utilisé sur l’image résultant de la récupération avec ddrescue. En effet, à ce stade, l’image devrait être suffisamment complète pour ne pas avoir à refaire de lecture lente et incertaine sur le disque défaillant.
De la même manière que ddru_ntfsbitmap, cet utilitaire va avoir besoin de connaître l’offset de la partition, et de pouvoir lire la MFT ntfs (si cette dernière est endommagée, le processus risque d’être compliqué et infructueux…).
Pour ceci, je lance :
ddru_ntfsfindbad ./disk_image.img mapfile.log -i 1048576
Le fichier disk_image.img doit être précisément celui créé par ddrescue.
Le fichier mapfile.log doit aussi être celui utilisé par ddrescue.
L’offset (-i) doit être le même que celui determiné à l’étape ddru_ntfsbitmap (si seule la partition du disque défaillant est dumpée, alors il vaut 0 et n’a pas besoin d’être précisé).
Seront comptabilisés comme secteurs non lisibles au moins les secteurs “non-trimmed” et les secteurs “failed”, mais pas les “non-tried”.
L’outil va ensuite créer un fichier ntfsfindbad.log, qui contient la liste des fichiers/dossiers dont la récupération est incomplète, et qu’il suffit de lire pour obtenir les informations !
Notons enfin que l’outil est prévu pour lister les fichiers qui sont dans la corbeille (et qui seront clairement affiché comme présents dans le dossier “$RECYCLE.BIN”), mais PAS les fichiers supprimés (pour ceci, un outil du genre testdisk ou photorec est plus adapté).