Existe-t-il un moyen de réparer une base de données LDM corrompue?

TL; DR:

Existe-t-il des outils / approches pour diagnostiquer et réparer les structures de métadonnées LDM ( Logical Disk Manager ) sans recréer à partir de zéro?

Description complète:

J'ai deux disques SSD configurés avec GPT + LDM (disque dynamique) dans un état qui semble impliquer une base de données LDM corrompue .

Le problème est que tout fonctionne bien, à l'exception d'un comportement étrange lors de l'utilisation diskpartou du Disk Management Snap-In.

La structure GPT semble être intacte:

GNU Parted 2.3
Using /dev/sde
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print                                                            
Model: ATA SanDisk SDSSDP12 (scsi)
Disk /dev/sde: 128GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name                          Flags
 1      17.4kB  1066kB  1049kB               LDM metadata partition
 2      1066kB  134MB   133MB                Microsoft reserved partition  msftres
 3      134MB   47.3GB  47.2GB  ext4         LDM data partition            raid
 4      47.3GB  128GB   80.5GB  ntfs         LDM data partition
 5      128GB   128GB   234MB                LDM data partition

(parted) sel /dev/sdf                                                     
Using /dev/sdf
(parted) print                                                            
Model: ATA SanDisk SDSSDP12 (scsi)
Disk /dev/sdf: 128GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name                          Flags
 1      17.4kB  47.2GB  47.2GB  ext4         LDM data partition            raid
 2      47.2GB  128GB   80.5GB  ntfs         LDM data partition
 3      128GB   128GB   367MB   ntfs         LDM data partition
 4      128GB   128GB   1049kB               LDM metadata partition
 5      128GB   128GB   335kB                Microsoft reserved partition  msftres

/dev/sde3et /dev/sdf1fonctionne très bien dans un tableau mdraid. /dev/sde4et /dev/sdf2font partie d'un volume en miroir Windows. /dev/sdf3est une partition de récupération Windows. Lors du démarrage sous Windows, je peux normalement utiliser le système et accéder au volume système en miroir. Cependant, cela Disk Management Snap-Indevient fou: entrez la description de l'image ici

Les disques physiques réels sont présents sans aucune information. Néanmoins, tous les volumes individuels peuvent être vus, et fonctionnent correctement malgré les xmarques - SYSTEM (C:)fait un bon travail de resynchronisation après tout cela, il est accessible et est actuellement utilisé comme volume système.

diskpart confirme cette situation: entrez la description de l'image ici

Les disques physiques ne peuvent pas être vus lors de l'inscription, mais peuvent être sélectionnés de toute façon et examinés plus avant. Tous les volumes réels s'affichent comme ils le devraient: entrez la description de l'image ici

mais lorsqu'ils sont examinés de manière plus approfondie, ils semblent provenir de disques inexistants: entrez la description de l'image ici

Virtual Disk Service error: The disk's extent information is corrupted. semble indiquer de façon assez verbale que l'état actuel des métadonnées LDM n'est plus conforme à certaines normes Microsoft.

Existe-t-il un moyen d'enquêter davantage et de résoudre éventuellement ce problème sans recréer l'intégralité du schéma de partitionnement de disque? Il semble qu'il n'y ait pas grand-chose à utiliser pour diagnostiquer les problèmes LDM. J'essaierai d'obtenir un vidage de la base de données en temps voulu.

Je suis particulièrement à la recherche de conseils sur ce qu'il faut rechercher lors de l'analyse de la base de données LDM .

— Karol J. Piczak
source

Je suppose que vous n'avez pas Microsoft System Center Data Protection Manager, n'est-ce pas? Tout mon googler semble se référer à l'un de leurs scripts PowerShell.

— Katherine Villyard

Malheureusement non, aucun service de ce type n'est disponible dans ce cas (poste de travail séparé typique). Mes recherches n'ont pas révélé grand-chose non plus, probablement en raison de la nature semi-exclusive de la norme LDM. Je pense que peu de choses peuvent être faites dans ce cas, mais je pensais que poster ici, bien que de loin, était mon dernier recours. Pour l'instant, je suis heureux qu'en dépit de cette base de données mal formée, tous les volumes soient reconnus par le système et soient disponibles pour une utilisation normale. J'espère que cela restera ainsi jusqu'à ce qu'une solution plus permanente soit trouvée (ou que le problème cesse d'exister avec une mise à niveau matérielle).

— Karol J. Piczak

Je vois que votre lecteur de démarrage a le statut Rebuild. Une fois terminé, voyez si l'erreur disparaît. Aussi ... avez-vous essayé un chkdsksur le disque affecté pour voir s'il trouve quelque chose?

— Nathan C

Pas une réponse ... mais plutôt un conseil ... si le contenu est important pour vous, sauvegardez pendant que vous le pouvez et reconstruisez les disques à partir de zéro. Pour les données critiques, toute tentative de correction n'en vaut pas la peine et injustifiable lorsque le pire se produit

— a.atlam

Votre problème et mon problème sont presque les mêmes: je peux voir les lecteurs dans la gestion des disques, mais aucune des partitions n'était exécutable, dans mon explorateur Windows, les lettres des lecteurs avaient disparu. dans mon cas, la partie disque montre tout correctement et la méthode suivante a résolu mon problème.

Veuillez retirer le disque dur physique problématique, attaché à une autre machine en cours d'exécution, et exécuter chkdsk avec / f / x / c / r, ou uniquement / r et / f. Rattachez ensuite, mettez également à jour votre pilote de disque dur.

Merci

— VL Thlan
source