¿Hay alguna manera de arreglar una base de datos LDM corrupta?

TL; DR:

¿Existen herramientas / enfoques para diagnosticar y reparar estructuras de metadatos de LDM ( Logical Disk Manager ) sin recrear desde cero?

Descripción completa:

Tengo dos unidades SSD configuradas con GPT + LDM (disco dinámico) en un estado que parece implicar una base de datos LDM corrupta .

El problema es que todo funciona bien, excepto por un comportamiento extraño cuando se usa diskparto Disk Management Snap-In.

La estructura GPT parece estar intacta:

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/sde3y /dev/sdf1funciona bien en una matriz mdraid. /dev/sde4y /dev/sdf2son parte de un volumen reflejado de Windows. /dev/sdf3es una partición de recuperación de Windows. Al arrancar en Windows, normalmente puedo usar el sistema y acceder al volumen del sistema duplicado. Sin embargo, la Disk Management Snap-Inlocura: ingrese la descripción de la imagen aquí

Las unidades físicas reales están presentes sin información alguna. Sin embargo, todos los volúmenes individuales se pueden ver y funcionan correctamente a pesar de las xmarcas: SYSTEM (C:)está haciendo un buen trabajo volviendo a sincronizar después de todo esto, se puede acceder y actualmente se está utilizando como volumen del sistema.

diskpart confirma esta situación: ingrese la descripción de la imagen aquí

Las unidades físicas no se pueden ver al enumerar, pero se pueden seleccionar de todos modos e investigar más a fondo. Todos los volúmenes reales se muestran como deberían: ingrese la descripción de la imagen aquí

pero cuando se examinan más a fondo, parecen provenir de algunos discos inexistentes: ingrese la descripción de la imagen aquí

Virtual Disk Service error: The disk's extent information is corrupted. parece indicar de manera bastante detallada que el estado actual de los metadatos de LDM ya no se ajusta a algún estándar de Microsoft.

¿Hay alguna manera de investigar esto más a fondo y potencialmente solucionar este problema sin recrear todo el esquema de partición del disco desde cero? Parece que no hay mucho que uno pueda usar para diagnosticar problemas de LDM. Intentaré adjuntar un volcado de base de datos a su debido tiempo.

Estoy buscando especialmente algunos consejos sobre qué buscar al analizar la base de datos LDM .

— Karol J. Piczak
fuente

Supongo que no tiene Microsoft System Center Data Protection Manager, ¿verdad? Todo mi google parece referirse a uno de sus scripts de PowerShell.

— Katherine Villyard

Desafortunadamente no, este servicio no está disponible en este caso (estación de trabajo separada típica). Mis búsquedas tampoco revelaron mucho, presumiblemente debido a la naturaleza semi-propietaria del estándar LDM. Creo que no se puede hacer mucho en este caso, pero pensé que publicar aquí, aunque sea una posibilidad remota, es mi último recurso. Por el momento, estoy feliz de que, a pesar de esta base de datos mal formada, todos los volúmenes sean reconocidos por el sistema y estén disponibles para el uso normal. Espero que siga así hasta que se encuentre una solución más permanente (o el problema deje de existir junto con alguna actualización de hardware).

— Karol J. Piczak

Veo que su unidad de arranque tiene un estado de Rebuild. Una vez que se complete, vea si el error desaparece. Además ... ¿probaste un chkdsken el disco afectado para ver si encuentra algo?

— Nathan C

No es una respuesta ... sino un consejo ... si el contenido es importante para usted, haga una copia de seguridad mientras pueda y reconstruya las unidades desde cero. Para los datos críticos, cualquier intento de reparación no vale la pena e injustificable cuando sucede lo peor

— a.atlam

Su problema y el mío son casi los mismos: puedo ver las unidades en la administración de discos, pero ninguna de las particiones era ejecutable, en mi explorador de Windows las letras de las unidades habían desaparecido. en mi caso, la parte del disco muestra todo correctamente, y el siguiente método resolvió mi problema.

Retire el disco duro físico problemático, conectado a otra máquina en ejecución, y ejecute chkdsk con / f / x / c / r, o solo / r y / f. Luego vuelva a conectar, también actualice su controlador de disco duro.

Gracias

— VL Thlan
fuente