ReFS Volume Directory Structure Corruption (Event ID 133) – Wie unkorrumpierte VM-Images per refsutil salvage extrahieren?

Question

Moin zusammen,

unsere Hyper-V-Host-Cluster spucken aktuell sprichwörtlich am laufenden Band ReFS Event ID 133 (File System Check) in das Event Log. Das Ganze betrifft ein kritisches Backup-Volume für unsere VMs.

Den Event-Logs nach zu urteilen haben wir es mit korrumpierten Metadata-Allocations zu tun (Checksum Errors, ReFS kann die Metadatenstrukturen der Allocations nicht mehr auflösen). Das Volume wird zwar teilweise noch gemountet, wirft aber bei Lesezugriffen I/O-Errors.

Da chkdsk bei ReFS bekanntlich wenig bringt bzw. nicht greift, wollen wir das Volume über refsutil salvage abgreifen, um die noch intakten VHDX/VM-Images wegzusichern.

Wie fahrt ihr hier die Best Practice bezüglich der Phases?

• Nutzt ihr direkt den Automatic Mode (-QA / -FA) oder fahrt ihr bei größeren Volumes (mehrere TB) erst manuelle Steps gefahren (-QS / -FS für den Scan und danach -C für die Copy-Phase), um den Overkill bei den Temp-Logs auf der Working Directory zu vermeiden?
• Gibt es Fallstricke bezüglich Dismount/Locking (-x), während der Hyper-V VMM oder Backup-Agents noch irgendwo den Handle blockieren?

Hat jemand von euch mit dem Salvage-Feature auf degraded ReFS-Volumes Erfahrungen im Prod-Umfeld sammeln können?

Answer 1

Hallo,

bei ReFS-Volumes mit Event ID 133 und korrupten Metadata-Allocations ist der Einsatz von refsutil salvage tatsächlich der einzige praktikable Weg, da chkdsk auf ReFS nicht greift. Die Best Practice hängt stark von der Größe des Volumes und der Lastsituation ab.

Für große Volumes im TB-Bereich empfiehlt es sich, nicht direkt mit den automatischen Modi -QA oder -FA zu starten. Diese erzeugen sehr umfangreiche Logdateien und können die Working Directory schnell überlasten. Besser ist es, zunächst mit -QS (Quick Scan) oder -FS (Full Scan) die Struktur zu prüfen und die Ergebnisse zu validieren. Anschließend kann man gezielt mit -C (Copy Phase) die noch intakten Objekte sichern. So behält man die Kontrolle über die Loggröße und kann den Prozess besser steuern.

Bezüglich Dismount/Locking: refsutil benötigt exklusiven Zugriff auf das Volume. Wenn Hyper-V VMM oder Backup-Agents noch Handles offenhalten, schlägt der Salvage-Vorgang fehl. Deshalb sollte das Volume vorher sauber dismounted werden (mountvol /p oder über Disk Management), und sicherstellen, dass keine Dienste mehr darauf zugreifen. Der Parameter -x erzwingt das Locking, aber wenn noch Handles aktiv sind, kommt es zu Fehlern. Daher unbedingt vorher alle VM- und Backup-Jobs stoppen.

Fallstricke in der Praxis: Salvage arbeitet blockweise, d. h. beschädigte Metadaten führen dazu, dass ganze Objektketten verloren gehen. Erfahrungsgemäß lassen sich VHDX-Dateien oft noch konsistent herausziehen, solange die Metadatenblöcke nicht vollständig zerstört sind. Bei produktiven Umgebungen ist es ratsam, die Salvage-Ergebnisse zunächst auf ein isoliertes Recovery-Volume zu kopieren und dort die Integrität der VMs zu prüfen, bevor man sie zurück in den Cluster bringt.

Kurz gesagt: Scan-Phase manuell fahren, Copy-Phase gezielt starten, Volume vorher vollständig dismounten, und mit ausreichend Platz für die Working Directory arbeiten. Automatik-Modi sind nur bei kleineren Volumes sinnvoll, da sie sonst zu viel Overhead erzeugen.

Ich hoffe, du hast hier etwas Nützliches gefunden. Wenn es dir hilft, mehr Einblick in das Problem zu bekommen, freue ich mich über eine akzeptierte Antwort. Solltest du weitere Fragen haben, hinterlasse gerne eine Nachricht. Einen schönen Tag!

HP.