Прекинут ланац снимака виртуелне машине (.ВМДК / .ВХДКС / .КЦОВ2) и спасавање диска¶

Када производна виртуелна машина (ВМ) на ВМваре ЕСКСи / Воркстатион, Мицрософт Хипер-В, Прокмок ВЕ / КЕМУ-КВМ или Орацле ВиртуалБок изненада одбије да се укључи након што задатак резервне копије не успе, складишту података понестаје простора на диску (0 bytes free), или администратор додирне датотеку снимка, један панични клик може да избрише месеце или године активних пословних података. Снимци виртуелне машине нису потпуно независне резервне копије; они су крхки Цопи-он-Врите (ЦоВ) делта диференцирајући ланци (*-000001-delta.vmdk, *.avhdx, или бацкинг-филе .qcow2 преклапања) где сваки појединачни блок написан од када је снимак направљен живи искључиво унутар подређених делта датотека, док оригинални основни диск стоји замрзнут у прошлости.

Ако видите грешке попут "The parent virtual disk has been modified since the child was created (Parent CID does not match)" у ВМваре-у, "Cannot boot: The chain of virtual hard disks is broken" у Хипер-В, или "Could not open backing file: L1/L2 table corrupted" у КЕМУ/Прокмок-у, поновно усмеравање ВМ-а директно на основни диск (flat.vmdk или база .vhdx) и његово покретање је фатално. На тај начин покрећете сервер какав је постојао пре 6 месеци када је направљен први снимак, одмах поништавајући криптографску везу родитељ-дете ГУИД/ЦИД и приказујући сваки делта снимак од тог датума као сироче и немогућ за спајање.

Овај водич пружа корак по корак недеструктивну реконструкцију ланца снимака, поправку заглавља датотеке дескриптора и протоколе за екстракцију гостујућих датотека ван опсега засноване на чланцима базе знања ВМваре би Броадцом (КБ 1007969 / 316578 и КБ 1002511), Мицрософт Хипер-11 Merge-VHD и Set-VHD инжењерске спецификације, КЕМУ qemu-img и libguestfs (guestmount) форензички стандарди и НИСТ посебна публикација 800-86.

Уради ово сада¶

Ако виртуелна машина одбије да се покрене или испостави покварени ланац снимака / грешку оштећеног виртуелног диска:

1. НИКАД не уређујте подешавања ВМ-а да бисте се покренули директно са основног диска (Server.vmdk или Server.vhdx) када делта снимци (-000001.vmdk или .avhdx) постоје у фасцикли. У тренутку када се гостујући оперативни систем покрене директно са основног родитељског диска чак и на 2 секунде, гостујући ОС уписује временске ознаке покретања и ажурирања НТФС/ект4 дневника на основни диск, мењајући ИД садржаја (ИД) родитељског диска (CID) у ВМваре-у или Линкаге ГУИД / Тиместамп у Хипер-В. То појединачно покретање разбија цео ланац дечијих снимака који зависе од тога да основни диск остаје замрзнут бит за бит. Ако у вашој серверској соби постоји активан пожар, квар хлађења или физичка опасност, евакуишите се и позовите локални број за хитне случајеве (911 у Сједињеним Државама и Канади, 112 широм Европске уније, 999 у Уједињеном Краљевству) или проверите бројеви за хитне случајеве.
2. НИКАД не бриши .avhdx, -delta.vmdk, или -sesparse.vmdk датотеке у Виндовс Екплорер-у или ЕСКСи Датасторе претраживачу да "ослободе простор на диску." За разлику од нормалних привремених датотека, .avhdx и -delta.vmdk датотеке ЈЕСУ ваш тренутни чврсти диск уживо. Ако је снимак направљен пре 8 месеци од стране заглављеног Вееам/ЦоммВаулт задатка за прављење резервних копија и оставио га да ради, 100 процената сваке трансакције базе података, фактуре и датотеке креиране током последњих 8 месеци се чува у тим .avhdx или -delta.vmdk датотеке. Њихово брисање брише све податке креиране од почетка снимања.
3. ** Копирајте или клонирајте све .vmdk, .vhdx/.avhdx, или .qcow2 датотеке у екстерни/секундарни меморијски волумен ПРЕ него што покренете било коју команду за стапање, урезивање или поправку.** Спајањем ланца снимака све делта блокове уписује уназад на родитељски диск на месту. Ако спајање не успе на пола пута због лошег сектора диска или пуне грешке у складишту података, и родитељски и подређени диск су оштећени осим ако прво нисте направили сирову копију датотеке.
4. Ако хипервизор није успео јер је складиште података / запремина домаћина достигао 100% пун (No space left on device), НИКАДА не покушавајте да „избришете/консолидујете снимке“ док не додате слободан простор или клонирате у већу складиште података. Консолидовање ланца више снимака захтева привремени простор за гребање једнак величини највећег делта диска. Покушај консолидације на 99% пуном складишту података ће срушити хипервизор усред урезивања.
5. Мапирајте тачан ланац зависности Родитељ -> Дете користећи команде за инспекцију само за читање (vmkfstools -e, Get-VHD, или qemu-img info --backing-chain) пре него што додирне један бајт. Свако заглавље датотеке снимка експлицитно именује тачно име надређене датотеке и надређени криптографски ИД за које очекује да се налазе директно изнад њега.

flowchart TD
    A["ВМ одбија да се покрене: прекинут ланац снимака, неподударање родитељског ЦИД-а или оштећени ВМДК/ВХДКС/КЦОВ2"] --> B["СТОП: НЕМОЈТЕ директно покретати основни диск и НЕМОЈТЕ брисати ниједну -делта.вмдк или .авхдк датотеке"]
    B --> C["Корак 1: Проверите Хост Датасторе / Волуме Фрее Спаце (`дф -х` / `ескцли списак фајл система за складиштење`)"]
    C --> D["Корак 2: Копирајте све датотеке базе и снимака на секундарни резервни НАС/САН/УСБ диск пре модификације"]
    D --> E{"На који хипервизор/виртуелни формат диска утиче?"}
    E -->|"1. ВМваре ЕСКСи / Воркстатион (.вмдк / -флат.вмдк / -делта.вмдк / -сеспарсе.вмдк)"| F["Прегледајте дескрипторе текста (`цат *.вмдк`) и проверите ланац (`вмкфстоолс -е Сервер-000002.вмдк`)"]
    F --> G{"Шта је грешка ВМваре ВМДК?"}
    G -->|"Неподударање ЦИД-а родитеља (`парентЦИД .= ЦИД родитеља`)"| H["Уредите подређени текстуални дескриптор `.вмдк` тако да `парентЦИД` одговара родитељском `ЦИД-у`, ИЛИ клонирајте активни лист диска у нови консолидовани ВМДК (`вмкфстоолс -и`)"]
    G -->|"Missing 1-KB text descriptor `.vmdk` (Only huge `-flat.vmdk` exists)"| I["Израчунајте тачну величину бајтова / 512 сектора и поново креирајте дескриптор `.вмдк` у обичном тексту помоћу `вмкфстоолс -ц`"]
    E -->|"2. Мицрософт Хипер-В (ланац .вхдк и .авхдк)"| J["Прегледајте ланац од најновијег `.авхдк` навише: `Гет-ВХД -Патх *.авхдк | Изаберите Патх,ПарентПатх`"]
    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

Understanding how virtual machine snapshot chains actually work¶

Whether you run VMware ESXi, Microsoft Hyper-V, Proxmox/KVM, or VirtualBox, every hypervisor implements snapshots using the exact same fundamental architecture: a unidirectional linked list of Read-Only Parent Disks and a Read-Write Child Leaf Delta Disk.

[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)

• When the VM wants to write a new block today, it writes ONLY to the bottom leaf file (Snapshot 2).
• When the VM wants to read a block today, the hypervisor checks Snapshot 2 first. If that block was modified since June 1, it reads it from Snapshot 2. If not, it looks up the chain to 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 changes, and the hypervisor immediately refuses to mount the child snapshot to prevent silent block corruption.

Песма 1: Спашавање ВМваре ЕСКСи & Воркстатион .vmdk снапсхот ланци¶

У ВМваре ЕСКСи, један виртуелни диск се заправо састоји од две одвојене датотеке за основни диск и две засебне датотеке за сваки снимак: 1. Мала (-500-бајта) дескрипторска датотека са чистим текстом (Server.vmdk и Server-000001.vmdk) који држи CID, parentCID, геометрију диска и тачно име датотеке бинарног екстента. (Напомена: ГУИ веб прегледача ЕСКСи Датасторе сакрива упарене -flat.vmdk и -sesparse.vmdk бинарне датотеке и приказује само једну спојену икону, МОРАТЕ да користите ССХ терминалску сесију на ЕСКСи хосту да бисте видели праве датотеке). 2. Датотека бинарних података са више гигабајта (Server-flat.vmdk за основни диск, и Server-000001-sesparse.vmdk или Server-000001-delta.vmdk за сваки снимак).

Сценарио 1А: Поправљање "The parent virtual disk has been modified since the child was created (Parent CID mismatch)"¶

1. ССХ у ЕСКСи хост и идите до директоријума складишта података ВМ:

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

2. Одштампајте CID, parentCID, и parentFileNameHint преко целог дескриптора текста .vmdk датотеке одједном: (Важно: само трчите cat или grep на малом текстуалном дескриптору од 500 бајта .vmdk датотеке, НЕ на више гигабајта -flat.vmdk или -sesparse.vmdk датотеке).

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

3. Упореди CID сваког родитеља против parentCID његовог непосредног детета: Погледајте излаз:

   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. Поправите покварене parentCID у дескриптору детета и проверите са vmkfstools -e:
5. Прво направите резервну копију датотека дескриптора текста (cp Server-000001.vmdk Server-000001.vmdk.bak).
6. Отвори Server-000001.vmdk ин vi и промене parentCID=55443322 да parentCID=1a2b3c4d (подударање Server.vmdk'с цуррент CID).
7. Тестирајте интегритет ланца из најновијег (највећег) снимка помоћу vmkfstools -e:

   vmkfstools -e Server-000002.vmdk
   

8. Ако је ланац нетакнут, ЕСКСи излази: Disk chain is consistent.
9. НЕДЕРУКТИВНА КОНСОЛИДАЦИЈА (vmkfstools -i Out-of-Place Clone):
10. Ако Server.vmdk was modified slightly before you fixed the parentCID, немојте консолидовати на месту на својој јединој копији. Уместо тога, тачка vmkfstools -i at the newest leaf snapshot (Server-000002.vmdk) and clone the entire chain into a brand-new, single flattened VMDK on a datastore with free space:

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

11. vmkfstools -i чита сваки блок из Server-000002.vmdk down through Server-000001.vmdk и Server-flat.vmdk in strict Read-Only Mode and writes out a clean, snapshot-free Server_Merged.vmdk without touching your original files.

Scenario 1B: Recreating a missing or deleted 500-byte .vmdk дескриптор текста када Server-flat.vmdk је још увек нетакнут¶

Понекад администратор или покварена скрипта брише Server.vmdk (или се поквари 0 bytes), што узрокује да Датасторе претраживач престане да приказује виртуелни диск, иако масивних 500 гигабајта Server-flat.vmdk датотека која садржи 100 процената ваших стварних података још увек се налази тамо у ССХ (ls -la *-flat.vmdk).

Можете поново креирати обичан текст који недостаје Server.vmdk дескриптор датотеку за 60 секунди без губитка ни једног бајта података унутра 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)

Сценарио 1Ц: Откључавање а .vmdk закључан од окаченог ЕСКСи хоста или срушеног проксија за резервну копију (Cannot open the disk: Failed to lock the file)¶

Ако ВМ одбије да се укључи са Failed to lock the file или Cannot open disk: Resource busy, други ЕСКСи хост у кластеру (или Вееам/бацкуп ХотАдд уређај који се срушио током прављења резервне копије) и даље држи закључавање СЦСИ / ВМФС датотеке укључено -flat.vmdk или -sesparse.vmdk: 1. Проверите да ли срушени резервни прокси ВМ још увек има ваше производне ВМ .vmdk прикључен на виртуелни СЦСИ контролер: Измените подешавања својих Вееам/ЦоммВаулт проки ВМ-ова и уклоните све застареле прикачене производне дискове (изаберите „Уклони са виртуелне машине“, НИКАДА „Избриши датотеке из складишта података“). 2. Find which ESXi host MAC address and world process holds the VMFS lock:

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

Track 2: Rescuing Microsoft Hyper-V .vhdx и .avhdx снапсхот ланци¶

У Мицрософт Хипер-В, свака контролна тачка (снимак) ствара различит виртуелни чврсти диск са екстензијом .avhdx (или .avhd на старијем ВХД формату) доделио дуго ГУИД име датотеке као ProdSQL_A1B2C3D4-E5F6-7890-ABCD-1234567890AB.avhdx.

Корак 1: Мапирајте тачно хронолошки .avhdx стабло родитељ-дијете у ПоверСхелл-у¶

Пре спајања или поновног повезивања било чега у Хипер-В Манагер-у, отворите прозор ПоверСхелл са повишеним администратором на Хипер-В хосту, идите до фасцикле која садржи ваш .vhdx и .avhdx датотеке и покрените овај једноструки ред да бисте приказали тачан ланац родитељ-дете од најновијег до најстаријег:

# 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

Погледај на Path и ParentPath поља. Они ће открити тачан редослед ланца: - ProdSQL.vhdx -> ParentPath: (blank) (Коренски основни диск, најстарији) - ProdSQL_1111.avhdx -> ParentPath: D:\VMs\ProdSQL.vhdx (Дете 1) - ProdSQL_2222.avhdx -> ParentPath: D:\VMs\ProdSQL_1111.avhdx (Дете 2) - ProdSQL_3333.avhdx -> ParentPath: D:\VMs\ProdSQL_2222.avhdx (Најновији активни лист диск)

Корак 2: Поправљање "The chain of virtual hard disks is broken" или "Differencing disk parent ID mismatch" (Set-VHD -IgnoreIdMismatch)¶

Шта ако је неко преместио ВМ фолдер из C:\VMs\ да E:\VMs\, или случајно покренут ProdSQL.vhdx за 5 секунди, узрокујући ProdSQL_1111.avhdx да не успе са: The chain of virtual hard disks is broken. The system cannot locate the parent virtual hard disk for the differencing disk или There is a mismatch in the virtual disk identifiers?

Користите званичну Хипер-В ПоверСхелл цмдлет Set-VHD са -IgnoreIdMismatch заставица (након што прво направите резервну копију датотека):

# 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

Корак 3: Ручно спајање сирочета .avhdx ланац од НАЈНОВИЈЕГ до НАЈСТАРИЈЕГ (Merge-VHD)¶

Када резервни агент остави 15 сирочета .avhdx датотеке у вашој фасцикли које се више не појављују унутар стабла „Цхецкпоинтс“ ГУИ Хипер-В Манагер-а, морате их ручно спојити у ПоверСхелл-у док је ВМ ИСКЉУЧЕН.

Покрените ове тачне ПоверСхелл команде на радној копији фасцикле:

# 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"

Трака 3: Спашавање Прокмок ВЕ / КЕМУ / КВМ .qcow2 и ВиртуалБок .vdi ланцима¶

1. Провера и поправка оштећених КЦОВ2 Л1/Л2 кластера и табела за рефцоунт (qemu-img check)¶

Када Линук КВМ или Прокмок хост доживи изненадни прекид напајања без кеш меморије са батеријом, .qcow2 виртуелни диск често не успева да се покрене са qcow2: Marking image as corrupt: L2 table offset unaligned или Refcount block corrupted. 1. Прва копија .qcow2 фајл (cp vm-100-disk-0.qcow2 vm-100-disk-0.qcow2.bak). 2. Ревизија пратећег ланца и интерне листе снимака:

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. Поправљање неисправне путање КЦОВ2 позадинске датотеке (qemu-img rebase -u)¶

Ако спољни КЦОВ2 снимак (overlay.qcow2) не успева да се отвори јер је његова надређена позадинска датотека (base.qcow2) је премештена у нови директоријум или спремиште за складиштење, ажурирајте показивач пратеће датотеке у небезбедно (-u, само заглавље) режим без поновног писања блокова података:

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

3. Поравнавање крхког КЦОВ2 или ВМДК или ВХДКС ланца у потпуно нову самосталну слику (qemu-img convert)¶

Један од најсвестранијих алата у спашавању виртуелних машина је qemu-img convert (који изворно гласи .qcow2, .vmdk, .vhdx, .vhd, и .vdi). Када покажете qemu-img convert на најновијем снимку листа важећег ланца, он чита целу хијерархију родитељ-дете у стриктном режиму само за читање и исписује потпуно нови, самостални виртуелни диск без снимака у вашу спасилачку меморију:

# 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

Трака 4: Спасавање датотека ван опсега (Извлачење датотека када се ВМ и даље не покреће)¶

Шта ако се оперативни систем за госте унутар виртуелног диска не може покренути или је средњи снимак у ланцу делимично оштећен и морате да извучете СКЛ базе података (.mdf/.ldf), КуицкБоокс датотеке, /var/lib/mysql, или документи компаније у наредних 30 минута?

Не морате да покрећете виртуелну машину да бисте издвојили датотеке унутар њеног виртуелног чврстог диска. Користите било који од ова три недеструктивна алата за монтирање ван опсега:

Метод 1: Монтирајте било који .vmdk, .vhdx, .qcow2, или .vdi у режиму само за читање на Линук-у користећи libguestfs (guestmount / qemu-nbd)¶

Инсталирај libguestfs-tools (sudo apt install libguestfs-tools qemu-utils on Ubuntu/Debian/Proxmox) and mount the newest leaf snapshot in strict Read-Only Mode (--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

Метод 2: Тренутна екстракција само за читање на Виндовс користећи 7-Zip или Disk Management -> Attach VHD (Read-Only)¶

• Коришћење 7-Зип-а (ради на .vmdk, .vhdx, .vhd, .qcow2, и .vdi): Right-click a standalone or flattened .vmdk, .vhdx, или .qcow2 датотеку на Виндовс-у и изаберите 7-Зип -> Отвори архиву. 7-Зип изворно анализира ГПТ/МБР партиционе табеле и НТФС/ект4 системе датотека унутар виртуелних дискова у 100% режиму само за читање, омогућавајући вам да превучете и испустите фасцикле за госте директно на радну површину за неколико секунди.
• Using Windows Disk Management (For .vhdx / .avhdx): Open diskmgmt.msc -> Action -> Attach VHD -> Browse to the newest leaf .avhdx (или .vhdx), CHECK THE BOX FOR [X] Read-only (КРИТИЧНО: Никада не заборавите да означите Само за читање, иначе ће Виндовс изменити заглавље диска) и кликните на ОК. Ц: и Д: дискови вашег ВМ-а се одмах појављују у Виндовс Филе Екплорер-у.

Метод 3: Реконструкција тешко оштећених ланаца са UFS Explorer Professional Recovery¶

If a parent disk in a VMDK or VHDX chain was accidentally booted and modified, or if VMFS/NTFS datastore corruption shredded part of a -sesparse.vmdk или .avhdx file so hypervisor tools reject it, UFS Explorer Professional Recovery (or R-Studio Technician) allows you to manually assemble the raw base disk and each child delta image into a custom Virtual Delta Stack in software RAM, bypassing hypervisor CID/GUID провере заглавља за изрезивање и издвајање нетакнутих датотека гостију.

Track 5: Recovering an orphaned VM configuration file (.vmx, .xml, или <vmid>.conf)¶

Sometimes the virtual hard disk chain itself (*.vmdk, *.vhdx, или *.qcow2) is 100 percent intact on the storage array, but the small configuration file that defines the Virtual Machine's hardware layout (.vmx in VMware ESXi, <GUID>.vmcx / .xml у Хипер-В, или /etc/pve/qemu-server/<vmid>.conf у Прокмок ВЕ) је оштећена, случајно избрисана или нулта током пада хоста.

Ако поново направите замену ВМ љуску са погрешним виртуелним контролером складиштења или режимом фирмвера, оперативни систем за госте ће се одмах срушити при покретању са INACCESSIBLE_BOOT_DEVICE (Виндовс) или убаците у а dracut / initramfs схелл за хитне случајеве (Линук). Ускладите ова четири хардверска подешавања са оригиналном конфигурацијом госта пре него што прикључите свој спасени виртуелни диск:

Често постављана питања¶

Извори проверени¶

• ВМваре би Броадцом Тецхницал Кновледге Басе: КБ 1007969 / 316578 (Решавање грешака „Матични виртуелни диск је модификован од када је дете креирано“ ЦИД неподударања грешака), КБ 1002511 (Поновно креирање дескриптора диска виртуелне машине који недостаје .vmdk Датотека) и КБ 10051 (Разумевање снимака виртуелне машине у ЕСКСи).
• Мицрософт Леарн / Виндовс Сервер Хипер-В инжењерска документација: Хипер-В ПоверСхелл Референце за Get-VHD, Set-VHD -IgnoreIdMismatch, и Merge-VHD Оффлине Дифференцинг Диск Цонсолидатион.
• КЕМУ Пројецт & Ред Хат Ентерприсе Линук виртуелизација документација: * Званична qemu-img Приручник (info --backing-chain, check -r all, rebase -u, convert) и libguestfs (guestmount --ro) Инспекција виртуелног диска само за читање*.
• Техничка документација за Орацле ВиртуалБок: VBoxManage showmediuminfo и clonemedium Различита архитектура слике.
• Национални институт за стандарде и технологију (НИСТ, Сједињене Државе): НИСТ посебна публикација 800-86: Водич за интеграцију форензичких техника у одговор на инциденте (очување слике виртуелне машине).

Повезани водичи¶

• НАС и РАИД низ деградиран, вишеструки квар дискова и ЗФС/Бтрфс опоравак
• НВМе или ССД изненада улазе у режим само за читање или нестају из БИОС-а
• Квар чврстог диска и хитан опоравак података
• Грешка при покретању Линук система и поправка ГРУБ-а
• Виндовс Блуе Сцреен (БСОД) и поправка покретања
• Резервне копије рачунара: стратегија 3-2-1 и опоравак од катастрофе
• Глобални бројеви за хитне случајеве