Prerušený reťazec snímok virtuálneho počítača (.VMDK / .VHDX / .QCOW2) a záchrana disku¶

Keď sa produkčný virtuálny stroj (VM) na VMware ESXi / Workstation, Microsoft Hyper-V, Proxmox VE / QEMU-KVM alebo Oracle VirtualBox náhle odmietne zapnúť po zlyhaní úlohy zálohovania, v úložisku údajov sa minie miesto na disku (0 bytes free), alebo sa správca dotkne súboru snímky, jediné kliknutie v panike môže vymazať mesiace alebo roky aktuálnych obchodných údajov. Snímky virtuálneho počítača nie sú úplné nezávislé zálohy; sú krehké Copy-on-Write (CoW) delta rozlišovacie reťazce (*-000001-delta.vmdk, *.avhdxalebo záložný súbor .qcow2 overlays), kde každý jeden blok zapísaný od vytvorenia snímky žije výlučne v podriadených delta súboroch, zatiaľ čo pôvodný základný disk je v minulosti zmrazený.

Ak vidíte chyby ako napr "The parent virtual disk has been modified since the child was created (Parent CID does not match)" vo VMware, "Cannot boot: The chain of virtual hard disks is broken" v Hyper-V, príp "Could not open backing file: L1/L2 table corrupted" in QEMU/Proxmox, re-pointing the VM Directly at the Base Disk (flat.vmdk alebo základňu .vhdx) and booting it up is fatal. Doing so boots the server as it existed 6 months ago when the first snapshot was created, instantly invalidating the cryptographic parent-child GUID/CID link and rendering every delta snapshot since that date orphaned and unmergeable.

This guide provides step-by-step non-destructive snapshot chain reconstruction, descriptor-file header repair, and out-of-band guest file extraction protocols based on VMware by Broadcom Knowledge Base Articles (KB 1007969 / 316578 and KB 1002511), Microsoft Hyper-V Merge-VHD a Set-VHD engineering specifications, QEMU qemu-img a libguestfs (guestmount) forensic standards, and NIST Special Publication 800-86.

Urobte to teraz¶

If a virtual machine refuses to start or throws a broken snapshot chain / corrupted virtual disk error:

1. NEVER edit the VM settings to boot directly from the Base Disk (Server.vmdk alebo Server.vhdx) when delta snapshots (-000001.vmdk alebo .avhdx) exist in the folder. The moment a guest operating system boots directly off the base parent disk for even 2 seconds, the guest OS writes boot timestamps and NTFS/ext4 journal updates into the base disk, modifying the parent disk's Content ID (CID) in VMware or Linkage GUID / Timestamp in Hyper-V. That single boot breaks the entire chain of child snapshots that depend on the base disk staying bit-for-bit frozen. If your server room is experiencing an active fire, cooling failure, or physical hazard, evacuate and call your local emergency number (911 in the United States and Canada, 112 across the European Union, 999 in the United Kingdom) or check tiesňové čísla.
2. NEVER delete .avhdx, -delta.vmdk, alebo -sesparse.vmdk files in Windows Explorer or the ESXi Datastore Browser to "free up disk space." Unlike normal temporary files, .avhdx a -delta.vmdk files ARE your current live hard drive. If a snapshot was created 8 months ago by a stuck Veeam/CommVault backup job and left running, 100 percent of every database transaction, invoice, and file created during the last 8 months is stored inside those .avhdx alebo -delta.vmdk files. Deleting them deletes all data created since the snapshot started.
3. Copy or clone all .vmdk, .vhdx/.avhdx, alebo .qcow2 files to an external / secondary storage volume BEFORE running any merge, commit, or repair command. Merging a snapshot chain writes all delta blocks backward into the parent disk in-place. If a merge fails halfway through due to a bad disk sector or datastore full error, both the parent and child disks are corrupted unless you took a raw file copy first.
4. If the hypervisor failed because the host Datastore / Volume hit 100% Full (No space left on device), NEVER try to "Delete / Consolidate Snapshots" until you add free space or clone to a larger datastore. Consolidating a multi-snapshot chain requires temporary scratch space equal to the size of the largest delta disk. Attempting to consolidate on a 99% full datastore will crash the hypervisor mid-commit.
5. Namapujte presný reťazec závislosti rodič -> dieťa pomocou kontrolných príkazov iba na čítanie (vmkfstools -e, Get-VHD, alebo qemu-img info --backing-chain) predtým, než sa dotknete jedného bajtu. Každá hlavička súboru so snímkou ​​explicitne pomenúva presný nadradený názov súboru a nadradené kryptografické ID, od ktorého sa očakáva, že bude priamo nad ním.

flowchart TD
    A["VM odmieta zaviesť systém: Prerušený reťazec snímok, nesúlad rodičovského CID alebo poškodený VMDK/VHDX/QCOW2"] --> B["STOP: NEZAVÁDZAJTE priamo základný disk a NEODSTRAŇUJTE žiadne súbory -delta.vmdk alebo .avhdx"]
    B --> C["Krok 1: Skontrolujte úložisko dát hostiteľa / voľné miesto na zväzku (`df -h` / `zoznam úložných súborových systémov esxcli`)"]
    C --> D["Krok 2: Pred úpravou skopírujte všetky základné a snímky na sekundárny záložný disk NAS/SAN/USB"]
    D --> E{"Ktorý hypervízor / formát virtuálneho disku je ovplyvnený?"}
    E -->|"1. VMware ESXi / Workstation (.vmdk / -flat.vmdk / -delta.vmdk / -sesparse.vmdk)"| F["Skontrolujte textové deskriptory (`cat *.vmdk`) a kontrolný reťazec (`vmkfstools -e Server-000002.vmdk`)"]
    F --> G{"Čo je chyba VMware VMDK?"}
    G -->|"Nesúlad CID rodiča (`parentCID .= CID rodiča`)"| H["Upravte podradený textový deskriptor `.vmdk` tak, aby sa `parentCID` zhodovalo s `CID` rodiča, ALEBO klonujte aktívny listový disk do nového konsolidovaného VMDK (`vmkfstools -i`)"]
    G -->|"Chýba 1-kB textový deskriptor `.vmdk` (existuje len veľký `-flat.vmdk`)"| I["Vypočítajte presnú veľkosť bajtu / 512 sektorov a znova vytvorte deskriptor `.vmdk` s obyčajným textom pomocou `vmkfstools -c`"]
    E -->|"2. Microsoft Hyper-V (reťazec .vhdx a .avhdx)"| J["Skontrolujte reťazec od najnovšieho `.avhdx` vyššie: `Get-VHD -Path *.avhdx | Vyberte Cesta, ParentPath`"]
    J --> K["Relink broken parent pointer (`Set-VHD -Path child.avhdx -ParentPath parent.vhdx -IgnoreIdMismatch`) or offline merge (`Merge-VHD`)"]
    E -->|"3. Proxmox / KVM / QEMU (.qcow2) or VirtualBox (.vdi)"| L["Check `qemu-img info --backing-chain`; repair refcount/L2 tables (`qemu-img check -r all`) or rebase (`qemu-img rebase -u`)"]
    H --> M["Out-of-Band File Rescue Fallback: Mount any chain directly in Read-Only mode via `guestmount --ro` or `7-Zip` / `UFS Explorer`"]
    I --> M
    K --> M
    L --> M

Pochopenie toho, ako vlastne fungujú reťazce snímok virtuálnych strojov¶

Či už používate VMware ESXi, Microsoft Hyper-V, Proxmox/KVM alebo VirtualBox, každý hypervízor implementuje snímky pomocou presne tej istej základnej architektúry: jednosmerne prepojený zoznam rodičovských diskov iba na čítanie a delta diskov s podriadeným listom na čítanie a zápis.

[Base Disk: Server.vmdk / Server.vhdx]  <-- Frozen Read-Only at Snapshot 1 (e.g., Jan 1)
         ^
         | (Points to Parent Path + Parent CID/GUID: 1234abcd)
[Snapshot 1: Server-000001.vmdk / Server_A.avhdx]  <-- Frozen Read-Only at Snapshot 2 (e.g., June 1)
         ^
         | (Points to Parent Path + Parent CID/GUID: 5678ef01)
[Snapshot 2 (Active Leaf): Server-000002.vmdk / Server_B.avhdx]  <-- Active Read/Write Today (Oct 31)

• Keď chce VM dnes zapísať nový blok, zapíše LEN do spodného listového súboru (Snapshot 2).
• Keď chce VM dnes prečítať blok, hypervízor to skontroluje Snapshot 2 najprv. Ak bol tento blok upravený od 1. júna, číta ho od Snapshot 2. Ak nie, hľadá sa v reťazci Snapshot 1. If it wasn't modified there either, it reads the original block from the Base Disk.
• Why chains break: Every child snapshot stores two strict pointers in its header: (1) The file path of its immediate parent, and (2) A 32-bit Content ID (CID in VMware) or 128-bit Linkage GUID (ParentUniqueId in Hyper-V) that gets regenerated every time a parent disk is opened for writing. If anyone moves a file, renames a folder, or briefly mounts the parent disk in read-write mode, the parent's CID / GUID zmeny a hypervízor okamžite odmietne pripojiť podriadenú snímku, aby zabránil poškodeniu tichého bloku.

Stopa 1: Záchrana VMware ESXi & Workstation .vmdk snapshot reťaze¶

Vo VMware ESXi sa jeden virtuálny disk v skutočnosti skladá z dvoch samostatných súborov pre základný disk a dvoch samostatných súborov pre každú snímku: 1. Malý (-500-bajtový) súbor deskriptora obyčajného textu (Server.vmdk a Server-000001.vmdk) ktorá drží CID, parentCID, geometriu disku a presný názov súboru binárneho rozsahu. (Poznámka: Webové grafické používateľské rozhranie prehliadača ESXi Datastore Browser skryje spárované -flat.vmdk a -sesparse.vmdk binárne súbory a zobrazuje iba jednu zlúčenú ikonu, na zobrazenie skutočných súborov MUSÍTE použiť reláciu terminálu SSH na hostiteľovi ESXi). 2. Binárny multigigabajtový súbor dátového rozsahu (Server-flat.vmdk pre základný disk a Server-000001-sesparse.vmdk alebo Server-000001-delta.vmdk pre každú snímku).

Scenár 1A: Oprava "The parent virtual disk has been modified since the child was created (Parent CID mismatch)"¶

1. SSH do hostiteľa ESXi a prejdite do adresára úložiska údajov virtuálneho počítača:

   cd /vmfs/volumes/<Datastore_Name>/<VM_Folder_Name>/
   ls -la *.vmdk
   

2. Vytlačte CID, parentCID, a parentFileNameHint cez všetky textové deskriptory .vmdk súbory naraz: (Dôležité: Len spustiť cat alebo grep na malom 500-bajtovom textovom deskriptore .vmdk súbory, NIE na multi-gigabajt -flat.vmdk alebo -sesparse.vmdk súbory).

   grep -E "CID|parentFileNameHint|Extent description" -A 2 Server.vmdk Server-00000*.vmdk
   

3. Porovnaj CID každého rodiča proti parentCID svojho bezprostredného dieťaťa: Pozrite sa na výstup:

   Server.vmdk:           CID=1a2b3c4d
                          parentCID=ffffffff   (ffffffff means this is the root Base Disk)
   
   Server-000001.vmdk:    CID=99887766
                          parentCID=55443322   <-- ERROR: Should equal Server.vmdk's CID (1a2b3c4d)
                          parentFileNameHint="Server.vmdk"
   
   Server-000002.vmdk:    CID=aabbccdd
                          parentCID=99887766   <-- OK: Matches Server-000001.vmdk's CID (99887766)
                          parentFileNameHint="Server-000001.vmdk"
   

4. ** Opravte poškodené parentCID v detskom deskriptore a overte pomocou vmkfstools -e:**
5. Najprv si zálohujte súbory textových deskriptorov (cp Server-000001.vmdk Server-000001.vmdk.bak).
6. Otvorte Server-000001.vmdk v vi a zmeniť parentCID=55443322 do parentCID=1a2b3c4d (zhoda Server.vmdkaktuálny CID).
7. Otestujte integritu reťaze z najnovšej (najvyššie očíslovanej) snímky pomocou vmkfstools -e:

   vmkfstools -e Server-000002.vmdk
   

8. Ak je reťaz neporušená, výstup ESXi: Disk chain is consistent.
9. NEDESTRUKTÍVNA KONSOLIDÁCIA (vmkfstools -i Klon mimo miesto):
10. Ak Server.vmdk bol mierne upravený predtým, ako ste ho opravili parentCID,nekonsolidujte na mieste cez svoju jedinú kópiu. Namiesto toho bod vmkfstools -i na najnovšej snímke listu (Server-000002.vmdk) a naklonujte celý reťazec do úplne nového, jediného splošteného VMDK na dátovom úložisku s voľným priestorom:

    vmkfstools -i Server-000002.vmdk /vmfs/volumes/<Target_Datastore>/Server_Rescue/Server_Merged.vmdk -d thin
    

11. vmkfstools -i číta každý blok z Server-000002.vmdk dole cez Server-000001.vmdk a Server-flat.vmdk v prísnom režime iba na čítanie a zapisuje čistý záznam bez snímok Server_Merged.vmdk bez toho, aby ste sa dotkli pôvodných súborov.

Scenár 1B: Obnovenie chýbajúcich alebo odstránených 500-bajtov .vmdk textový deskriptor kedy Server-flat.vmdk je stále neporušený¶

Niekedy sa vymaže správca alebo poškodený skript Server.vmdk (alebo sa poškodí 0 bytes), čo spôsobí, že prehliadač Datastore Browser prestane zobrazovať virtuálny disk, aj keď má obrovský 500-gigabajt Server-flat.vmdk súbor obsahujúci 100 percent vašich skutočných údajov sa stále nachádza priamo tam v SSH (ls -la *-flat.vmdk).

Chýbajúci obyčajný text môžete vytvoriť znova Server.vmdk súbor deskriptora za 60 sekúnd bez straty jediného bajtu údajov vo vnútri Server-flat.vmdk:

# 1. Check the exact byte size of your existing Server-flat.vmdk:
ls -l Server-flat.vmdk
# Example output: -rw------- 1 root root 107374182400 Oct 31 12:00 Server-flat.vmdk  (Exactly 107,374,182,400 bytes)

# 2. Create a temporary dummy VMDK of that EXACT byte size in /tmp or the datastore:
vmkfstools -c 107374182400 -d thin temp_dummy.vmdk

# 3. Delete the dummy binary file (temp_dummy-flat.vmdk) and rename the 500-byte descriptor to Server.vmdk:
rm -f temp_dummy-flat.vmdk
mv temp_dummy.vmdk Server.vmdk

# 4. Edit Server.vmdk in 'vi' and change the filename inside quotes from "temp_dummy-flat.vmdk" to "Server-flat.vmdk":
sed -i 's/temp_dummy-flat.vmdk/Server-flat.vmdk/g' Server.vmdk
# (Also delete the line 'ddb.thinProvisioned = "1"' if the original disk was thick-provisioned)

Scenario 1C: Unlocking a .vmdk uzamknutý zaveseným hostiteľom ESXi alebo zlyhaným záložným serverom proxy (Cannot open the disk: Failed to lock the file)¶

Ak sa VM odmietne zapnúť pomocou Failed to lock the file alebo Cannot open disk: Resource busy, iný hostiteľ ESXi v klastri (alebo zariadenie Veeam/backup HotAdd, ktoré zlyhalo počas zálohovania) stále drží uzamknutie súboru SCSI / VMFS -flat.vmdk alebo -sesparse.vmdk: 1. Skontrolujte, či havarovaný záložný proxy virtuálny počítač stále obsahuje vaše produkčné virtuálne počítače .vmdk pripojené k jeho virtuálnemu radiču SCSI: Upravte nastavenia svojich virtuálnych počítačov proxy Veeam/CommVault a odstráňte všetky zastarané pripojené produkčné disky (vyberte možnosť „Odstrániť z virtuálneho počítača“, NIKDY „Odstrániť súbory z úložiska údajov“). 2. Nájdite, ktorá MAC adresa hostiteľa ESXi a svetový proces obsahuje zámok VMFS:

vmfsfilelockinfo -p /vmfs/volumes/<Datastore>/<VM_Folder>/Server-flat.vmdk

Track 2: Rescuing Microsoft Hyper-V .vhdx a .avhdx snapshot reťaze¶

V Microsoft Hyper-V každý kontrolný bod (snímka) vytvára odlišný virtuálny pevný disk s príponou .avhdx (príp .avhd na staršom formáte VHD) priradený dlhý názov súboru GUID, napr ProdSQL_A1B2C3D4-E5F6-7890-ABCD-1234567890AB.avhdx.

Krok 1: Mapujte presne chronologicky .avhdx strom rodič-dieťa v PowerShell¶

Pred zlúčením alebo opätovným prepojením čohokoľvek v Hyper-V Manager otvorte okno Elevated Administrator PowerShell na hostiteľovi Hyper-V, prejdite do priečinka obsahujúceho vaše .vhdx a .avhdx súbory a spustite tento jednoduchý riadok, aby ste zobrazili presný reťazec rodič-dieťa od najnovšieho po najstarší:

# Inspect every .vhdx and .avhdx in the directory, sorted by LastWriteTime:
Get-ChildItem -Filter "*.*vhd*" | ForEach-Object {
    Get-VHD -Path $_.FullName -ErrorAction SilentlyContinue |
    Select-Object Path, ParentPath, VhdType, FileSize, Size
} | Format-List

Pozrite sa na Path a ParentPath poliach. Odhalia presné poradie reťaze: - ProdSQL.vhdx -> ParentPath: (blank) (Root Base Disk, Oldest) - ProdSQL_1111.avhdx -> ParentPath: D:\VMs\ProdSQL.vhdx (Child 1) - ProdSQL_2222.avhdx -> ParentPath: D:\VMs\ProdSQL_1111.avhdx (Child 2) - ProdSQL_3333.avhdx -> ParentPath: D:\VMs\ProdSQL_2222.avhdx (Newest Active Leaf Disk)

Step 2: Fixing "The chain of virtual hard disks is broken" alebo "Differencing disk parent ID mismatch" (Set-VHD -IgnoreIdMismatch)¶

What if someone moved the VM folder from C:\VMs\ do E:\VMs\, or accidentally booted ProdSQL.vhdx for 5 seconds, causing ProdSQL_1111.avhdx to fail with: The chain of virtual hard disks is broken. The system cannot locate the parent virtual hard disk for the differencing disk alebo There is a mismatch in the virtual disk identifiers?

Použite oficiálnu rutinu cmdlet Hyper-V PowerShell Set-VHD s -IgnoreIdMismatch príznak (najskôr po zálohovaní súborov):

# Relink a child .avhdx to its parent .vhdx/.avhdx (adding -IgnoreIdMismatch if the parent timestamp/GUID shifted):
Set-VHD -Path "E:\VMs\ProdSQL_1111.avhdx" -ParentPath "E:\VMs\ProdSQL.vhdx" -IgnoreIdMismatch

Krok 3: Manuálne zlúčenie osiroteného .avhdx reťaz od NAJNOVŠÍCH po NAJSTARŠIE (Merge-VHD)¶

Keď záložný agent opustí 15 siroty .avhdx súbory vo vašom priečinku, ktoré sa už nezobrazujú v strome kontrolných bodov GUI Hyper-V Manager, musíte ich zlúčiť ručne v prostredí PowerShell, keď je VM vypnutý.

Spustite tieto presné príkazy PowerShell na pracovnej kópii priečinka:

# Step 1: Merge Child 3 (Newest) into Child 2:
Merge-VHD -Path "E:\VMs\ProdSQL_3333.avhdx" -DestinationPath "E:\VMs\ProdSQL_2222.avhdx"

# Step 2: Merge Child 2 into Child 1:
Merge-VHD -Path "E:\VMs\ProdSQL_2222.avhdx" -DestinationPath "E:\VMs\ProdSQL_1111.avhdx"

# Step 3: Merge Child 1 into the Base .vhdx:
Merge-VHD -Path "E:\VMs\ProdSQL_1111.avhdx" -DestinationPath "E:\VMs\ProdSQL.vhdx"

Skladba 3: Záchrana Proxmox VE / QEMU / KVM .qcow2 a VirtualBox .vdi reťaze¶

1. Kontrola a oprava poškodených QCOW2 L1/L2 Cluster & Refcount Tables (qemu-img check)¶

Keď hostiteľ Linux KVM alebo Proxmox utrpí náhly výpadok napájania bez vyrovnávacej pamäte zálohovanej batériou, a .qcow2 virtuálny disk sa často nepodarí spustiť qcow2: Marking image as corrupt: L2 table offset unaligned alebo Refcount block corrupted. 1. ** Najprv skopírujte súbor .qcow2 súbor (cp vm-100-disk-0.qcow2 vm-100-disk-0.qcow2.bak).** 2. Audit podporného reťazca a zoznamu interných snímok:

qemu-img info --backing-chain vm-100-disk-0.qcow2
qemu-img snapshot -l vm-100-disk-0.qcow2

qemu-img check -r all vm-100-disk-0.qcow2

2. Oprava poškodenej cesty k záložnému súboru QCOW2 (qemu-img rebase -u)¶

Ak externý snímok QCOW2 (overlay.qcow2) sa nepodarilo otvoriť, pretože jeho nadradený podporný súbor (base.qcow2) bol presunutý do nového adresára alebo úložnej oblasti, aktualizujte ukazovateľ záložného súboru v nebezpečnom (-u, iba hlavička) režim bez prepisovania dátových blokov:

qemu-img rebase -u -b /new/path/to/base.qcow2 -F qcow2 overlay.qcow2

3. Sploštenie krehkého reťazca QCOW2 alebo VMDK alebo VHDX do úplne nového samostatného obrazu (qemu-img convert)¶

Jedným z najuniverzálnejších nástrojov na záchranu virtuálnych strojov je qemu-img convert (ktorý natívne znie .qcow2, .vmdk, .vhdx, .vhd, a .vdi). Keď ukážeš qemu-img convert na najnovšej snímke listu platného reťazca načíta celú hierarchiu rodič-dieťa v prísnom režime iba na čítanie a zapíše úplne nový, samostatný virtuálny disk bez snímok na vaše záchranné úložisko:

# Non-destructively flatten an entire QCOW2, VMDK, or VHDX chain into a single clean image:
qemu-img convert -p -O qcow2 top_snapshot_leaf.qcow2 /mnt/rescue_storage/flattened_clean.qcow2

Stopa 4: Záchrana súboru mimo pásma (Extrahovanie súborov, keď sa VM stále nespustí)¶

Čo ak sa hosťujúci operačný systém vo virtuálnom disku nedá zaviesť alebo je stredný snímok v reťazci čiastočne poškodený a potrebujete vytiahnuť databázy SQL (.mdf/.ldf), súbory QuickBooks, /var/lib/mysql, alebo firemné dokumenty v priebehu nasledujúcich 30 minút?

Na extrahovanie súborov na virtuálnom pevnom disku nepotrebujete zavádzať virtuálny počítač. Použite ktorýkoľvek z týchto troch nedeštruktívnych nástrojov na mimopásmovú montáž:

Metóda 1: Namontujte ľubovoľný .vmdk, .vhdx, .qcow2, alebo .vdi v režime iba na čítanie v systéme Linux libguestfs (guestmount / qemu-nbd)¶

Inštalovať libguestfs-tools (sudo apt install libguestfs-tools qemu-utils na Ubuntu/Debian/Proxmox) a pripojte najnovšiu snímku listu v prísnom režime iba na čítanie (--ro):

# Option A: Using guestmount (Automatically detects internal guest LVM/partitions and mounts read-only):
sudo mkdir -p /mnt/vm_rescue
sudo guestmount -a /path/to/Newest_Leaf_Snapshot.vmdk -i --ro /mnt/vm_rescue
# (If guest OS partitions fail auto-inspection due to dirty NTFS journal, list partitions with 'virt-filesystems -a disk.vmdk -l'
# and mount the specific partition directly with '-m /dev/sda2 --ro -o norecover')

# Option B: Attaching the virtual disk chain as a Read-Only Network Block Device (/dev/nbd0):
sudo modprobe nbd max_part=16
sudo qemu-nbd --read-only --connect=/dev/nbd0 /path/to/Newest_Leaf_Snapshot.qcow2
sudo partprobe /dev/nbd0
lsblk /dev/nbd0
# Now mount /dev/nbd0p2 read-only (with -o ro,norecover for NTFS or -o ro,noload for ext4):
sudo mount -o ro,norecover /dev/nbd0p2 /mnt/vm_rescue

Metóda 2: Okamžitá extrakcia iba na čítanie v systéme Windows pomocou 7-Zip alebo Disk Management -> Attach VHD (Read-Only)¶

• Pomocou 7-Zip (funguje na .vmdk, .vhdx, .vhd, .qcow2, a .vdi): Kliknite pravým tlačidlom myši na samostatnú alebo sploštenú .vmdk, .vhdx, alebo .qcow2 súbor v systéme Windows a vyberte 7-Zip -> Open Archive. 7-Zip natívne analyzuje tabuľky oddielov GPT/MBR a súborové systémy NTFS/ext4 na virtuálnych diskoch v režime 100% iba na čítanie, čo vám umožňuje presúvať zložky hosťa priamo na plochu v priebehu niekoľkých sekúnd.
• Pomocou správy diskov systému Windows (pre .vhdx / .avhdx): Otvorené diskmgmt.msc -> Akcia -> Pripojiť VHD -> Prejdite na najnovší list .avhdx (príp .vhdx), ZAčiarknite políčko [X] Read-only (KRITICKÉ: Nikdy nezabudnite zaškrtnúť Iba na čítanie, inak systém Windows upraví hlavičku disku) a kliknite na OK. Jednotky C: a D: vášho VM sa okamžite objavia v Prieskumníkovi súborov Windows.

Metóda 3: Rekonštrukcia vážne poškodených reťazí s UFS Explorer Professional Recovery¶

Ak bol nadradený disk v reťazci VMDK alebo VHDX náhodne spustený a upravený, alebo ak poškodenie dátového úložiska VMFS/NTFS skartovalo časť -sesparse.vmdk alebo .avhdx súbor, takže ho nástroje hypervízora odmietnu, UFS Explorer Professional Recovery (alebo R-Studio Technician) vám umožňuje manuálne zostaviť nespracovaný základný disk a každý podriadený delta obraz do vlastného Virtual Delta Stack v softvérovej RAM, čím sa obíde hypervízor CID/GUID kontroly hlavičky na vyrezanie a extrahovanie neporušených súborov hostí.

Stopa 5: Obnova osamoteného konfiguračného súboru virtuálneho počítača (.vmx, .xml, alebo <vmid>.conf)¶

Niekedy samotný reťazec virtuálneho pevného disku (*.vmdk, *.vhdx, alebo *.qcow2) je na úložnom poli 100 percent nedotknutý, ale malý konfiguračný súbor, ktorý definuje rozloženie hardvéru virtuálneho počítača (.vmx vo VMware ESXi, <GUID>.vmcx / .xml v Hyper-V, príp /etc/pve/qemu-server/<vmid>.conf v Proxmox VE) je poškodený, náhodne odstránený alebo vynulovaný počas zlyhania hostiteľa.

Ak znovu vytvoríte náhradný shell VM s nesprávnym režimom radiča virtuálneho úložiska alebo firmvéru, hosťujúci operačný systém okamžite zlyhá pri zavádzaní INACCESSIBLE_BOOT_DEVICE (Windows) alebo vstúpte do a dracut / initramfs núdzový shell (Linux). Pred pripojením zachráneného virtuálneho disku prispôsobte tieto štyri nastavenia hardvéru vašej pôvodnej konfigurácii hosťa:

Často kladené otázky¶

Zdroje skontrolované¶

• VMware by Broadcom Technical Knowledge Base: KB 1007969 / 316578 (Riešenie chýb „Rodičovský virtuálny disk bol zmenený od vytvorenia potomka“ CID Mismatch Error), KB 1002511 (Obnovenie chýbajúceho deskriptora disku virtuálneho počítača .vmdk Súbor) a KB 10051 (Porozumenie snímkam virtuálneho počítača v ESXi).
• Microsoft Learn / Windows Server Technická dokumentácia Hyper-V: Hyper-V PowerShell Reference for Get-VHD, Set-VHD -IgnoreIdMismatch, a Merge-VHD Offline rozdielová konsolidácia diskov.
• Projekt QEMU a dokumentácia k virtualizácii Red Hat Enterprise Linux: Oficiálna qemu-img Manuál (info --backing-chain, check -r all, rebase -u, convert) a libguestfs (guestmount --ro) Kontrola virtuálneho disku len na čítanie.
• Technická dokumentácia Oracle VirtualBox: VBoxManage showmediuminfo a clonemedium Rozdiel v architektúre obrázkov.
• National Institute of Standards and Technology (NIST, Spojené štáty americké): Špeciálna publikácia NIST 800-86: Sprievodca integráciou forenzných techník do reakcie na incidenty (Virtual Machine Image Preservation).

Súvisiaci sprievodcovia¶

• Zhoršené pole NAS a RAID, zlyhanie viacerých diskov a obnovenie ZFS/Btrfs
• NVMe alebo SSD náhle prejde do režimu len na čítanie alebo zmizne z BIOSu
• Porucha pevného disku a núdzová obnova dát
• Zlyhanie zavádzania systému Linux a oprava GRUB
• Modrá obrazovka systému Windows (BSOD) a oprava zavádzania
• Počítačové zálohy: stratégia 3-2-1 a obnova po havárii
• Globálne tiesňové čísla