Restaurer un volume quelque peu cassé sur le disque en place?

Après une panne de courant, mon ordinateur portable ne parvient pas à démarrer. J'ai étudié la question avec un tas d'utilitaires de disque et de CD live. Les données sont intactes et j'en ai fait une copie de sauvegarde. Néanmoins, j'aimerais rétablir le fonctionnement du disque, y compris le démarrage bien sûr, avec le moins d'efforts possible. Je sais que de nombreux experts suggèrent de recréer de nouvelles partitions, de restaurer le système d’exploitation et de réinstaller les logiciels. C'est difficilement faisable dans mon cas (je n'ai même pas tous les kits de distribution). C'est pourquoi j'aimerais modifier la table de partition corrompue sur place, et j'ai besoin d'un conseil sur la partie qui pose problème.

Le disque contient 2 volumes: l'un est la partition principale et l'autre est un lecteur logique dans une partition étendue.

Lorsque je démarre l'ordinateur portable à partir d'un live CD, Windows voit les deux lecteurs, mais le lecteur logique de la partition étendue est inaccessible.

diskpartLa commande de list volumemontre que l'indicateur de volume fs est RAW au lieu de NTFS. Ce qui est étrange, c’est que les utilitaires de disque que j’ai utilisés pour restaurer des données (y compris DMDE ) voient ce volume sous le format NTFS et en lisent les données sans problème.

Voici la sortie de diskpart:

Et voici ce que DMDE montre:

La question est de savoir quels octets bruts et comment dois-je éditer dans le tableau (par exemple, je peux utiliser DMDE pour l'édition directe sur disque) afin de rendre le volume correct NTFS accessible à partir de Windows?

Je ne sais pas quels autres détails peuvent être importants et je suis prêt à les fournir sur demande.

Mettre à jour

La seule réponse réelle parmi celles qui sont liées suggère d'utiliser TestDisk. Tout d’abord, je dois dire que cet utilitaire est très difficile en ce qui concerne le système d’exploitation - il ne s’exécute sur aucun CD live basé sur WinPE que j’ai essayé. Finalement, j'ai réussi à l'exécuter sur un CD live Win7 à part entière. Voici ce que cela montre (veuillez noter NTFS dans le volume logique de la partition étendue):

et (notez bien FAT32 cette fois):

Je dois récupérer le plus gros volume d'ici. Il est affiché en tant que FAT32 sous TestDisk (DMDE affiché NTFS). PCette commande ne produit pas de liste lisible de fichiers pour ce volume. J'ai essayé la Tcommande pour changer le type en NTFS, mais cela n'a pas résolu le problème: Pindique toujours un déchet ("le système de fichiers peut être endommagé"). Pourtant, je vois le système de fichiers complet sous DMDE et l’enregistre à l’aide de l’utilitaire r.saver.

J'ai effectué une recherche plus approfondie:

et trouvé:

Le volume NTFS supprimé est le lecteur avec mes données. Ensuite, j'ai changé son de "D" en "L" et ai écrit les modifications sur le disque et redémarrez.

Le lecteur est toujours inaccessible, mais maintenant si je lance DMDE, il se plaint que les enregistrements MBR nécessitent un disque d'au moins 625153410 LBA (320 Go), mais le disque est de 625142448 LBA (320 Go).

D'après mon expérience, TestDisk est incapable de faire le travail dans mon cas ou j'ai besoin d'instructions plus détaillées sur ce qu'il faut corriger exactement à l'aide de TestDisk.

Merci d'avance.

^{Comme petite remarque, je dois dire que TestDisk est un buggy: j’ai fait une sauvegarde de la table de partition en utilisant la commande correspondante de TestDisk, puis j’ai modifié la table et l’a écrit sur le disque; a ensuite découvert que les modifications ne permettaient pas de résoudre le problème et a décidé de revenir aux modifications apportées par la sauvegarde. Par conséquent, la table de partition que je me suis trouvée était complètement différente et incorrecte. La seule chose qui m'a sauvé d'un fiasco, c'est que j'ai effectué une autre sauvegarde à l'aide de dmde, qui a restauré la structure comme prévu.}

Le problème est résolu (avec le soutien de certains gourous techniques partageant leurs connaissances dans les médias sociaux), et je poste les détails les plus importants comme réponse.

Dès le début, je ne comprenais pas que le drapeau RAW était égal à 0 écrit physiquement dans la partition correspondante. Le fait est que 0 signifie un enregistrement de partition vide, c'est-à-dire qu'il n'y a aucune partition, alors que RAW est un indicateur logique spécial indiquant certains problèmes de partition. Ainsi, diskpartle "message" dans ce cas était que, bien que la partition "inaccessible" soit logiquement "saine", son disque dur sous-jacent peut contenir certains défauts.

À l'ère des disques durs SMART, les défauts sont consignés en interne sur chaque disque et peuvent être corrigés (s'ils ne sont pas fatals).

Donc, j'ai d'abord utilisé HDDScan pour lire les informations SMART. Voici ce que j'ai eu:

Veuillez noter que le nombre d'erreurs en attente est 3. Ces erreurs doivent être corrigées.

À cette fin, il convient de déterminer quels secteurs produisent exactement ces erreurs, en particulier d’analyser la surface du disque pour rechercher les erreurs de lecture. Dans mon cas, l’ utilitaire Victoria a été utilisé (l’interface utilisateur de l’utilitaire est en anglais, mais le site est malheureusement en russe).

En conséquence, j'ai eu les 3 adresses de bloc avec les secteurs endommagés.

Ensuite, l’une des méthodes de réparation des blocs doit être appliquée (la méthode spécifique peut varier selon le fabricant du disque dur). Dans mon cas, il suffisait d'essayer d'écrire des données dans les blocs endommagés. Le disque SMART est suffisamment intelligent pour remapper les blocs endommagés sur un autre espace réservé en cas d'échec de l'opération d'écriture. La méthode la plus simple pour exécuter la commande write est de copier une région de blocs sur elle-même. Vous pouvez utiliser votre outil préféré pour cela, j’ai utilisé dmde ( Tools -> Copy sectors). Dans la mesure où les blocs défectueux étaient localisés les uns à côté des autres dans mon cas, j’ai exécuté la commande de copie une seule fois: le bloc de départ de SourceetDestinationétait identique (un peu avant le premier secteur défectueux) et le nombre de secteurs à copier était suffisamment grand pour couvrir la région avec les 3 blocs défectueux. Puisqu'il s'agit d'une copie sur lui-même, les blocs valides ne sont pas modifiés. Les mauvais blocs sont remplis de zéros. Leurs données d'origine sont de toute façon perdues. Si les blocs défectueux ne contiennent pas de données critiques, le disque restauré peut probablement bien exécuter tous les programmes.

Après l'exécution de la commande de copie, j'ai vérifié les informations SMART une fois de plus et je me suis assuré que le nombre d'erreurs est égal à 0. Si ce n'était pas le cas, quelque chose s'est mal passé et doit être examiné de manière approfondie.

La dernière chose à faire est d'exécuter chkdsk d: /F(où dest votre lettre de lecteur) pour corriger les erreurs logiques dans la partition restaurée physiquement.

Après tout cela, j’ai réussi à récupérer la partition problématique de NTFS (le drapeau RAW a disparu et elle est à nouveau répertoriée en tant que NTFS), sur place et presque sans perte de données - au moins, Windows s’amorce comme auparavant.