Gibt es eine Möglichkeit, eine beschädigte LDM-Datenbank zu reparieren?

TL; DR:

Gibt es Tools / Ansätze zum Diagnostizieren und Reparieren von LDM- Metadatenstrukturen ( Logical Disk Manager ) , ohne diese von Grund auf neu zu erstellen?

Gesamte Beschreibung:

Ich habe zwei SSD-Laufwerke mit GPT + LDM (dynamischer Datenträger) in einem Zustand eingerichtet, der eine beschädigte LDM-Datenbank impliziert .

Das Problem ist, dass alles gut funktioniert, bis auf ein seltsames Verhalten bei der Verwendung von diskpartoder Disk Management Snap-In.

Die GPT-Struktur scheint intakt zu sein:

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/sde3und gut /dev/sdf1funktionieren in einem mdraid Array. /dev/sde4und /dev/sdf2sind Teil eines Windows-gespiegelten Volumes. /dev/sdf3ist eine Windows-Wiederherstellungspartition. Beim Booten von Windows kann ich normalerweise das System verwenden und auf das gespiegelte Systemvolume zugreifen. Das wird jedoch Disk Management Snap-Inverrückt: Bildbeschreibung hier eingeben

Die tatsächlichen physischen Laufwerke sind ohne jegliche Informationen vorhanden. Nichtsdestotrotz sind alle einzelnen Volumes sichtbar und funktionieren trotz der xMarkierungen einwandfrei. SYSTEM (C:)Wenn nach alledem eine erneute Synchronisierung durchgeführt wird, kann auf sie zugegriffen werden und sie wird derzeit als Systemvolume verwendet.

diskpart bestätigt diese Situation: Bildbeschreibung hier eingeben

Physische Laufwerke werden bei der Auflistung nicht angezeigt, können aber trotzdem ausgewählt und weiter untersucht werden. Alle tatsächlichen Volumes werden so angezeigt, wie sie sollten: Bildbeschreibung hier eingeben

Bei genauerer Betrachtung scheinen sie jedoch von einigen nicht vorhandenen Datenträgern zu stammen: Bildbeschreibung hier eingeben

Virtual Disk Service error: The disk's extent information is corrupted. scheint ziemlich wörtlich darauf hinzudeuten, dass der aktuelle Status der LDM-Metadaten nicht mehr mit einem Microsoft-Standard übereinstimmt.

Gibt es eine Möglichkeit, dies weiter zu untersuchen und dieses Problem möglicherweise zu beheben, ohne das gesamte Festplattenpartitionsschema von Grund auf neu zu erstellen? Es scheint, dass man nicht viel zur Diagnose von LDM-Problemen verwenden kann. Ich werde versuchen, einen Datenbank-Dump zu bekommen gegebener Zeit anzufügen.

Insbesondere suche ich nach Hinweisen, worauf bei der Analyse der LDM-Datenbank zu achten ist .

— Karol J. Piczak
quelle

Ich vermute nicht, dass Sie Microsoft System Center Data Protection Manager haben, oder? Mein ganzes Googeln scheint sich auf eines ihrer PowerShell-Skripte zu beziehen.

— Katherine Villyard

Leider ist in diesem Fall kein solcher Dienst verfügbar (typische separate Workstation). Meine Recherchen ergaben auch nicht viel, vermutlich aufgrund des semi-proprietären Charakters des LDM-Standards. Ich denke, dass in diesem Fall nicht viel getan werden kann, aber ich dachte, dass das Posten hier, obwohl ein langer Schuss, mein letzter Ausweg ist. Derzeit bin ich froh, dass trotz dieser fehlerhaften Datenbank alle Volumes vom System erkannt werden und für den normalen Gebrauch verfügbar sind. Ich hoffe, dass dies so bleibt, bis eine dauerhaftere Lösung gefunden wird (oder das Problem zusammen mit einem Hardware-Upgrade nicht mehr besteht).

— Karol J. Piczak

Ich sehe, Ihr Boot-Laufwerk hat einen Status von Rebuild. Überprüfen Sie, ob der Fehler behoben ist. Also ... haben Sie versucht, chkdskauf der betroffenen Festplatte eine zu finden, wenn es etwas findet?

— Nathan C

Keine Antwort ... sondern eher ein Rat ... Wenn der Inhalt für Sie wichtig ist, sichern Sie, solange Sie können, und erstellen Sie die Laufwerke von Grund auf neu. Bei kritischen Daten lohnen sich Korrekturversuche nicht und sind im

— schlimmsten Fall

Ihr Problem und mein Problem fast dasselbe: Ich kann Laufwerke in der Datenträgerverwaltung sehen, aber keine der Partitionen war ausführbar, in meinem Windows Explorer waren die Laufwerksbuchstaben verschwunden. In meinem Fall zeigt disk-part alles korrekt an, und die folgende Methode hat mein Problem behoben.

Entfernen Sie die problematische physische Festplatte, die an einen anderen laufenden Computer angeschlossen ist, und führen Sie chkdsk mit / f / x / c / r oder nur / r und / f aus. Aktualisieren Sie anschließend Ihren Festplattentreiber.

Vielen Dank

— VL Thlan
quelle