XCP-ng VHD Recovery: Recover VM Data from Corrupted VHD Files

XCP‑ng Recover VM: Fast Recovery Decision Matrix

When a virtual machine fails in XCP‑ng, the right recovery path depends on where the failure occurred — backup availability, metadata integrity, SR accessibility, or VHD corruption. Use the following decision matrix to quickly choose the safest option:

👉 Rule of thumb:

• Always start with backups if available.
• Move to metadata restore or SR reconnect if the issue is logical.
• Escalate to VHD recovery or storage‑level workflows only when higher layers fail.

This structured approach minimizes downtime and reduces the risk of permanent data loss in XCP‑ng environments.

XCP‑ng VDI Recovery: How Virtual Disks, VHD Files, and Metadata Connect

To understand recovery in XCP‑ng, it’s essential to know how the core storage objects relate to each other:

• VDI (Virtual Disk Image) → This is the logical disk object inside XCP‑ng. Each VM is linked to one or more VDIs, which represent its virtual hard drives.
• VHD (Virtual Hard Disk) → On file‑based SRs (like EXT4), the VDI is stored as a VHD file. These files can form snapshot chains, and corruption often occurs when merges or exports fail.
• SR (Storage Repository) → The SR is the container that holds all VDIs and their associated VHD files. It can be file‑based (EXT4) or block‑based (LVM).
• Pool Metadata → This maps the relationships between VMs, VDIs, SRs, networks, and hosts. If metadata is lost or corrupted, the VM may appear missing even though its VHDs still exist.

👉 In recovery workflows, you may need to rebuild metadata, reconnect SRs, or extract VHDs directly. Understanding how these objects connect ensures you target the right layer — whether fixing VM configuration, repairing SR metadata, or reconstructing VHD chains.

XCP‑ng Storage Recovery: Local SR, NFS, iSCSI, and RAID Cases

Storage recovery in XCP‑ng depends heavily on the backend type. Each storage repository (SR) has unique risks and workflows.

Local SR Recovery

Local SRs typically use LVM over physical disks.

• Failures often involve disk corruption or damaged LVM metadata.
• Overwritten blocks from failed snapshots or VM writes can complicate recovery.
• Best practice: clone the disk first, then attempt metadata repair or VHD extraction.

NFS SR Recovery

NFS‑based SRs store VHD files directly on a NAS.

• Common issues: deleted VHDs, broken snapshot chains, or accidental formatting.
• Recovery paths include NAS snapshots, recycle bins, or filesystem‑level undelete tools.
• Always mount NFS shares read‑only before scanning for lost files.

iSCSI or Fibre Channel SR Recovery

Block‑based SRs on SANs (iSCSI/FC) present different challenges.

• Use LUN cloning to create safe images before scanning.
• Perform read‑only scans to avoid overwriting metadata.
• If the storage array supports snapshots, leverage them for rollback and recovery.

RAID‑Backed SR Recovery

RAID arrays add complexity when disks fail.

• Risks include failed members, bad rebuild attempts, controller loss, or parity corruption.
• Always perform sector‑level imaging of each disk before reconstruction.
• Rebuild arrays only after imaging and verifying disk order.
• If parity damage is severe, escalate to professional recovery services.

👉 Each backend requires a tailored approach: local SRs demand careful LVM handling, NFS relies on file recovery, SANs depend on LUN imaging, and RAID needs forensic reconstruction.

✅ Quick takeaway:

• Local SR → focus on cloning the disk and extracting VDI data.
• NFS SR → leverage NAS snapshots or file‑level recovery.
• iSCSI SR → clone the LUN and perform read‑only scans.
• RAID SR → rebuild the RAID image first, then proceed with VM recovery.

XCP‑ng Corrupted VHD: Signs, Causes, and Recovery Options

When a VHD file becomes corrupted in XCP‑ng, the VM may fail to boot or lose access to its virtual disks. Recognizing the symptoms early helps prevent further damage:

• VM will not boot or hangs during startup
• Missing disk entries in Xen Orchestra or xe CLI
• Failed snapshot creation or merge operations
• Guest partitions unreadable or reporting filesystem errors
• I/O errors in logs or during VM operations
• Damaged VHD chain with broken parent/child links
• Failed export or import of VM images

Common Causes of Corrupted VHD Files

• Power loss during active write operations
• Host crash or abrupt shutdown of XCP‑ng
• Storage disconnects on NFS or iSCSI backends
• Bad sectors on physical disks
• Failed snapshot merge leaving orphaned differencing disks
• NAS failure or network interruption during VHD access
• RAID degradation or controller malfunction corrupting parity and metadata

Safe Recovery Workflow for Corrupted VHD

To maximize recovery chances, follow a controlled workflow:

1. 1. Clone the source disks → Create byte‑level images of affected drives before attempting repair.
2. 2. Scan the VHD files → Use recovery software to detect partitions and validate VHD chain integrity.
3. 3. Mount read‑only → Never mount damaged VHDs in write mode; use read‑only access for inspection.
4. 4. Inspect partitions → Check guest OS partitions for consistency and identify recoverable data.
5. 5. Export files → Copy validated documents, databases, and system files to safe storage.
6. 6. Rebuild the VM shell → Create a new VM in XCP‑ng and attach recovered VDI/VHD files.

👉 This workflow ensures that recovery is performed safely, without overwriting critical structures, and provides a clear path from detection to restoration.

Virtual Machine File Recovery: Where DiskInternals VMFS Recovery™ Fits

DiskInternals VMFS Recovery™ is purpose‑built for VMware environments, designed to handle VMFS datastores and VMDK virtual disks. It provides a strong example of specialized virtual machine file recovery with features such as:

• Read‑only scanning to protect original data integrity.
• Preview before export, allowing verification of recoverable files.
• RAID support, reconstructing arrays before scanning VMFS volumes.
• Remote recovery over SSH without shutting down hosts.
• Virtual disk handling, including snapshots, templates, and large VMDK files.

While VMFS Recovery™ is specific to VMware, the recovery logic applies directly to XCP‑ng:

1. 1. Protect the source — never write to damaged disks; work from clones.
2. 2. Recover the virtual disk — scan VHD/VDI files or SRs for usable data.
3. 3. Validate guest data — confirm partitions, files, and databases are intact.
4. 4. Rebuild the VM shell — create a new VM in XCP‑ng and attach recovered disks.

👉 The takeaway: VMFS Recovery™ illustrates how specialized tools approach virtual machine file recovery. In XCP‑ng, the same disciplined workflow — protect, recover, validate, rebuild — ensures safe restoration of VMs after corruption or deletion.

⚠️ Common Mistakes That Destroy XCP‑ng Recovery Chances

🛑 Creating New VMs on the Same SR

Launching new VMs on the affected SR overwrites disk sectors that may still contain recoverable data. Once overwritten, those blocks are gone forever, eliminating the chance of restoring deleted or corrupted VHDs.

🛠️ Running Repair Commands Before Imaging

Commands like xe sr-repair or filesystem fixes can alter or destroy metadata structures. Without a forensic image, you only get one shot — and a failed repair can make recovery impossible. Always clone the disks first to preserve the original state.

🔄 Reinitializing the SR During Host Reinstall

Reinitialization wipes SR headers and metadata, erasing the logical map between VDIs and VHD files. Even if raw data remains, recovery becomes far more complex because the structure is lost. Avoid reinitializing; instead, use SR introduce or metadata restore.

💾 Mounting Damaged Storage Read‑Write

Mounting a corrupted SR in write mode risks overwriting partition tables, snapshot chains, and filesystem metadata. Always mount read‑only and work from clones to prevent irreversible corruption.

📉 Assuming Metadata Restore Recovers Deleted Disk Data

Metadata restore only rebuilds VM definitions and SR mappings. It does not resurrect deleted VHD files. If the disk data is gone, metadata alone cannot bring it back — you’ll need VHD recovery or storage‑level scanning.

👉 The golden rule: Preserve first, recover second. Acting too quickly with destructive commands or writes is the fastest way to lose data permanently.