Счупена верига моментни снимки на виртуална машина (.VMDK / .VHDX / .QCOW2) и спасяване на диск¶

Когато производствена виртуална машина (VM) на VMware ESXi / Workstation, Microsoft Hyper-V, Proxmox VE / QEMU-KVM или Oracle VirtualBox внезапно откаже да се включи след неуспешно задание за архивиране, дисковото пространство в хранилището за данни свършва (0 bytes free), или администраторът докосне файл със снимка, едно паническо щракване може да изтрие месеци или години живи бизнес данни. Моментните снимки на виртуална машина не са пълни независими резервни копия; те са крехки Copy-on-Write (CoW) делта диференциращи вериги (*-000001-delta.vmdk, *.avhdx, или архивен файл .qcow2 наслагвания), където всеки отделен блок, записан след заснемането на моментната снимка, живее изключително в дъщерните делта файлове, докато оригиналният основен диск стои замразен в миналото.

Ако видите грешки като "The parent virtual disk has been modified since the child was created (Parent CID does not match)" във VMware, "Cannot boot: The chain of virtual hard disks is broken" в Hyper-V, или "Could not open backing file: L1/L2 table corrupted" в QEMU/Proxmox, пренасочване на VM директно към основния диск (flat.vmdk или база .vhdx) и зареждането му е фатално. Това зарежда сървъра, както е съществувал преди 6 месеца, когато е създадена първата моментна снимка, незабавно анулирайки криптографската връзка родител-дете GUID/CID и изобразявайки всяка делта моментна снимка от тази дата на осиротяла и неподлежаща на сливане.

Това ръководство предоставя стъпка по стъпка недеструктивна реконструкция на веригата от моментни снимки, поправка на заглавката на дескрипторния файл и протоколи за извличане на файлове за гости извън лентата, базирани на статии от базата знания на VMware от Broadcom (KB 1007969 / 316578 и KB 1002511), Microsoft Hyper-V Merge-VHD и Set-VHD инженерни спецификации, QEMU qemu-img и libguestfs (guestmount) криминалистични стандарти и специална публикация на NIST 800-86.

Направете това сега¶

Ако виртуална машина откаже да се стартира или издаде грешка в прекъсната верига на моментни снимки/повреден виртуален диск:

1. НИКОГА не редактирайте настройките на VM за зареждане директно от основния диск (Server.vmdk или Server.vhdx), когато делта моментни снимки (-000001.vmdk или .avhdx) съществуват в папката. В момента, в който операционна система за гост се зарежда директно от основния родителски диск дори за 2 секунди, гост OS записва времеви клеймца за зареждане и NTFS/ext4 актуализации на журнала в основния диск, модифицирайки Content ID ( ID на съдържанието на родителския дискCID) във VMware или GUID за свързване / времево клеймо в Hyper-V. Това едно зареждане прекъсва цялата верига от дъщерни моментни снимки, които зависят от това, че основният диск остава замразен бит по бит. Ако във вашето сървърно помещение има активен пожар, повреда в охлаждането или физическа опасност, евакуирайте се и се обадете на местния номер за спешни случаи (911 в Съединените щати и Канада, 112 в целия Европейски съюз, 999 в Обединеното кралство) или проверете номера за спешни случаи.
2. НИКОГА не изтривайте .avhdx, -delta.vmdk, или -sesparse.vmdk файлове в Windows Explorer или ESXi Datastore Browser, за да "освободите дисково пространство." За разлика от нормалните временни файлове, .avhdx и -delta.vmdk файлове СА вашият текущ жив твърд диск. Ако моментна снимка е създадена преди 8 месеца от блокирано задание за архивиране на Veeam/CommVault и е оставена да работи, 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["VM отказва да стартира: Прекъсната верига за моментни снимки, несъответствие на CID на родител или повреден VMDK/VHDX/QCOW2"] --> B["СПРИ: НЕ стартирайте директно основния диск и НЕ изтривайте -delta.vmdk или .avhdx файлове"]
    B --> C["Стъпка 1: Проверете Хост Datastore / Volume Free Space (`df -h` / `esxcli storage filesystem list`)"]
    C --> D["Стъпка 2: Копирайте всички основни файлове и файлове със снимки на вторично NAS/SAN/USB устройство за архивиране, преди да модифицирате"]
    D --> E{"Кой формат на хипервайзор/виртуален диск е засегнат?"}
    E -->|"1. VMware ESXi / Работна станция (.vmdk / -flat.vmdk / -delta.vmdk / -sesparse.vmdk)"| F["Проверете текстовите дескриптори (`cat *.vmdk`) и проверете веригата (`vmkfstools -e Server-000002.vmdk`)"]
    F --> G{"Каква е грешката на VMware VMDK?"}
    G -->|"Несъответствие на CID на родител (`parentCID .= CID на родител`)"| H["Редактирайте дъщерния текстов дескриптор `.vmdk`, така че `parentCID` да съответства на `CID` на родителя, ИЛИ клонирайте активния листов диск към нов консолидиран VMDK (`vmkfstools -i`)"]
    G -->|"Липсва 1-KB текстов дескриптор `.vmdk` (съществува само огромен `-flat.vmdk`)"| I["Изчислете точния размер на байта / 512 сектора и пресъздайте дескриптора `.vmdk` в обикновен текст с `vmkfstools -c`"]
    E -->|"2. Microsoft Hyper-V (.vhdx и .avhdx верига)"| J["Проверете веригата от най-новия `.avhdx` нагоре: `Get-VHD -Path *.avhdx | Изберете Path,ParentPath`"]
    J --> K["Повторно свързване на счупен родителски указател (`Set-VHD -Path child.avhdx -ParentPath parent.vhdx -IgnoreIdMismatch`) или офлайн сливане (`Merge-VHD`)"]
    E -->|"3. Proxmox / KVM / QEMU (.qcow2) или VirtualBox (.vdi)"| L["Проверете `qemu-img info --backing-chain`; поправете refcount/L2 таблици (`qemu-img check -r all`) или пребазирайте (`qemu-img rebase -u`)"]
    H --> M["Резервно спасяване на файлове извън лентата: Монтирайте всяка верига директно в режим само за четене чрез `guestmount --ro` или `7-Zip` / `UFS Explorer`"]
    I --> M
    K --> M
    L --> M

Разбиране как всъщност работят веригите за моментни снимки на виртуална машина¶

Независимо дали използвате VMware ESXi, Microsoft Hyper-V, Proxmox/KVM или VirtualBox, всеки хипервайзор реализира моментни снимки, използвайки абсолютно същата фундаментална архитектура: еднопосочен свързан списък от родителски дискове само за четене и четене-записване на дъщерен лист Delta диск.

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

• Когато VM иска да напише нов блок днес, той записва САМО във файла на долния лист (Snapshot 2).
• Когато VM иска да прочете блок днес, хипервайзорът проверява Snapshot 2 първи. Ако този блок е бил променен след 1 юни, той го чете от Snapshot 2. Ако не, търси се нагоре по веригата Snapshot 1. Ако не е модифициран и там, той чете оригиналния блок от Base Disk.
• Защо веригите се прекъсват: Всяка дъщерна моментна снимка съхранява два стриктни указателя в заглавката си: (1) пътят на файла на своя непосредствен родител и (2) 32-битов идентификатор на съдържанието (CID във VMware) или 128-битов GUID за свързване (ParentUniqueId в Hyper-V), който се регенерира всеки път, когато родителски диск се отвори за запис. Ако някой премести файл, преименува папка или за кратко монтира родителския диск в режим на четене-запис, родителският CID / GUID промени и хипервайзорът незабавно отказва да монтира дъщерната моментна снимка, за да предотврати повреда на тихия блок.

Път 1: Спасяване на VMware ESXi и работна станция .vmdk вериги за моментни снимки¶

Във VMware ESXi един виртуален диск всъщност се състои от два отделни файла за основния диск и два отделни файла за всяка моментна снимка: 1. Мъничък (-500 байта) дескрипторен файл с обикновен текст (Server.vmdk и Server-000001.vmdk), който съдържа CID, parentCID, геометрията на диска и точното име на файла на двоичния екстент. (Забележка: Стандартният уеб GUI на браузъра на ESXi Datastore скрива сдвоените -flat.vmdk и -sesparse.vmdk двоични файлове и показва само една обединена икона, ТРЯБВА да използвате SSH терминална сесия на ESXi хоста, за да видите истинските файлове). 2. Многогигабайтов двоичен файл с разширение на данни (Server-flat.vmdk за основния диск и Server-000001-sesparse.vmdk или Server-000001-delta.vmdk за всяка моментна снимка).

Сценарий 1A: Коригиране "The parent virtual disk has been modified since the child was created (Parent CID mismatch)"¶

1. SSH в ESXi хоста и отидете до директорията за съхранение на данни на VM:

   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. Ако веригата е непокътната, ESXi извежда: Disk chain is consistent.
9. НЕРАЗРУШИТЕЛНА КОНСОЛИДАЦИЯ (vmkfstools -i Неуместен клонинг):
10. Ако Server.vmdk беше леко променен, преди да поправите parentCID, не консолидирайте на място върху единственото си копие. Вместо това точка vmkfstools -i при най-новата моментна снимка на листа (Server-000002.vmdk) и клонирайте цялата верига в чисто нов, единичен сплескан VMDK в хранилище за данни със свободно пространство:

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

11. vmkfstools -i чете всеки блок от Server-000002.vmdk надолу през Server-000001.vmdk и Server-flat.vmdk в строг Режим само за четене и записва чиста, без моментна снимка Server_Merged.vmdk без да докосвате оригиналните си файлове.

Сценарий 1B: Повторно създаване на липсващи или изтрити 500 байта .vmdk текстов дескриптор когато Server-flat.vmdk все още е непокътнат¶

Понякога администратор или повреден скрипт изтрива Server.vmdk (или се поврежда до 0 bytes), което кара браузъра на Datastore да спре да показва виртуалния диск, въпреки огромните 500 гигабайта Server-flat.vmdk файлът, съдържащ 100 процента от действителните ви данни, все още се намира точно там в SSH (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)

Сценарий 1C: Отключване a .vmdk заключено от увиснал ESXi хост или повреден резервен прокси (Cannot open the disk: Failed to lock the file)¶

Ако VM откаже да се включи с Failed to lock the file или Cannot open disk: Resource busy, друг ESXi хост в клъстера (или устройство Veeam/backup HotAdd, което се срина по време на архивиране) все още поддържа заключване на SCSI / VMFS файл -flat.vmdk или -sesparse.vmdk: 1. Проверете дали повреден резервен прокси VM все още има вашите производствени VM .vmdk прикрепен към неговия виртуален SCSI контролер: Редактирайте настройките на вашите Veeam/CommVault прокси виртуални машини и премахнете всички остарели прикачени производствени дискове (изберете „Премахване от виртуална машина“, НИКОГА „Изтриване на файлове от хранилище за данни“). 2. Намерете кой ESXi хост MAC адрес и световен процес държи заключването на VMFS:

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

Трак 2: Спасяване на Microsoft Hyper-V .vhdx и .avhdx вериги за моментни снимки¶

В Microsoft Hyper-V всяка контролна точка (моментна снимка) създава различен виртуален твърд диск с разширение .avhdx (или .avhd на по-стар VHD формат) присвоено дълго GUID име на файл като ProdSQL_A1B2C3D4-E5F6-7890-ABCD-1234567890AB.avhdx.

Стъпка 1: Картирайте точната хронология .avhdx дърво родител-дете в PowerShell¶

Преди да обедините или свържете отново нещо в Hyper-V Manager, отворете прозорец Elevated Administrator PowerShell на Hyper-V хоста, отидете до папката, съдържаща вашия .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 (Най-новият Active Leaf Disk)

Стъпка 2: Фиксиране "The chain of virtual hard disks is broken" или "Differencing disk parent ID mismatch" (Set-VHD -IgnoreIdMismatch)¶

Ами ако някой премести папката VM от 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?

Използвайте официалния Hyper-V PowerShell cmdlet 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 файлове във вашата папка, които вече не се показват в дървото на "контролните точки" на GUI на Hyper-V Manager, трябва да ги обедините ръчно в PowerShell, докато виртуалната машина е ИЗКЛЮЧЕНА.

Изпълнете точно тези команди на PowerShell на работно копие на папката:

# 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: Спасяване на Proxmox VE / QEMU / KVM .qcow2 и VirtualBox .vdi вериги¶

1. Проверка и поправка на повредени QCOW2 L1/L2 Cluster & Refcount таблици (qemu-img check)¶

Когато Linux KVM или Proxmox хост претърпи внезапно прекъсване на захранването без кеш, поддържан от батерии, .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. Коригиране на повреден QCOW2 Backing File Path (qemu-img rebase -u)¶

Ако външна QCOW2 снимка (overlay.qcow2) не успява да се отвори, защото неговият родителски архивен файл (base.qcow2) беше преместен в нова директория или пул за съхранение, актуализирайте указателя на архивния файл в опасен (-u, само заглавие) режим без пренаписване на блокове с данни:

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

3. Изравняване на крехка QCOW2 или VMDK или VHDX верига в чисто ново самостоятелно изображение (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: Извънлентово спасяване на файлове (Извличане на файлове, когато VM все още не се зарежда)¶

Ами ако операционната система за гост във виртуалния диск не може да се стартира или средна моментна снимка във веригата е частично повредена и трябва да изтеглите SQL бази данни (.mdf/.ldf), файлове на QuickBooks, /var/lib/mysql, или фирмени документи в рамките на следващите 30 минути?

Не е необходимо да зареждате виртуална машина, за да извлечете файловете във виртуалния твърд диск. Използвайте който и да е от тези три недеструктивни инструмента за монтиране извън лентата:

Метод 1: Монтирайте всеки .vmdk, .vhdx, .qcow2, или .vdi в режим само за четене при използване на Linux libguestfs (guestmount / qemu-nbd)¶

Инсталирайте libguestfs-tools (sudo apt install libguestfs-tools qemu-utils на Ubuntu/Debian/Proxmox) и монтирайте най-новата моментна снимка на листа в строг режим само за четене (--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: Незабавно извличане само за четене при използване на Windows 7-Zip или Disk Management -> Attach VHD (Read-Only)¶

• ** Използване на 7-Zip (Работи на .vmdk, .vhdx, .vhd, .qcow2, и .vdi):** Щракнете с десния бутон върху самостоятелен или сплескан .vmdk, .vhdx, или .qcow2 файл в Windows и изберете 7-Zip -> Отваряне на архив. 7-Zip естествено анализира GPT/MBR таблици на дялове и NTFS/ext4 файлови системи във виртуални дискове в 100% режим само за четене, което ви позволява да плъзгате и пускате гост папки направо върху вашия работен плот за секунди.
• Използване на управление на дискове в Windows (за .vhdx / .avhdx): Отворете diskmgmt.msc -> Действие -> Прикачване на VHD -> Преглед до най-новия лист .avhdx (или .vhdx), ПОСТАВЕТЕ ОТМЕТКА ЗА [X] Read-only (КРИТИЧНО: Никога не забравяйте да поставите отметка само за четене, или Windows ще промени заглавката на диска) и щракнете върху OK. C: и D: устройствата на вашата виртуална машина веднага се появяват в Windows File Explorer.

Метод 3: Възстановяване на силно повредени вериги с UFS Explorer Professional Recovery¶

Ако родителски диск във верига VMDK или VHDX е бил случайно стартиран и модифициран, или ако VMFS/NTFS повреда в хранилището за данни е унищожила част от -sesparse.vmdk или .avhdx файл, така че инструментите на хипервайзора да го отхвърлят, UFS Explorer Professional Recovery (или R-Studio Technician) ви позволява ръчно да сглобите необработения основен диск и всяко дъщерно делта изображение в персонализиран Виртуален делта стек в софтуерна RAM, заобикаляйки хипервайзор CID/GUID проверки на заглавките за изрязване и извличане на непокътнати гост файлове.

Трак 5: Възстановяване на осиротели конфигурационен файл на VM (.vmx, .xml, или <vmid>.conf)¶

Понякога самата верига на виртуалния твърд диск (*.vmdk, *.vhdx, или *.qcow2) е 100 процента непокътнат в масива за съхранение, но малкият конфигурационен файл, който определя хардуерното оформление на виртуалната машина (.vmx във VMware ESXi, <GUID>.vmcx / .xml в Hyper-V, или /etc/pve/qemu-server/<vmid>.conf в Proxmox VE) е повреден, случайно изтрит или нулиран по време на срив на хост.

Ако пресъздадете резервна обвивка на VM с грешен контролер за виртуално съхранение или режим на фърмуер, операционната система за гости незабавно ще се срине при зареждане с INACCESSIBLE_BOOT_DEVICE (Windows) или пуснете в a dracut / initramfs аварийна обвивка (Linux). Съпоставете тези четири хардуерни настройки с вашата първоначална конфигурация за гост, преди да прикачите вашия спасен виртуален диск:

Често задавани въпроси¶

Проверени източници¶

• VMware от Broadcom Technical Knowledge Base: KB 1007969 / 316578 (Разрешаване на „Родителският виртуален диск е променен след създаването на дъщерния“ грешки при несъответствие на CID), KB 1002511 (Пресъздаване на липсващ дескриптор на диск на виртуална машина .vmdk Файл) и KB 10051 (Разбиране на моментните снимки на виртуална машина в ESXi).
• Microsoft Learn / Windows Server Hyper-V Инженерна документация: Hyper-V PowerShell Reference за Get-VHD, Set-VHD -IgnoreIdMismatch, и Merge-VHD Офлайн диференцираща дискова консолидация.
• QEMU Project & Документация за виртуализация на Red Hat Enterprise Linux: Официална qemu-img Ръчно (info --backing-chain, check -r all, rebase -u, convert) и libguestfs (guestmount --ro) Проверка на виртуален диск само за четене.
• Техническа документация на Oracle VirtualBox: VBoxManage showmediuminfo и clonemedium Различна архитектура на изображението.
• Национален институт за стандарти и технологии (NIST, Съединени щати): Специална публикация на NIST 800-86: Ръководство за интегриране на криминалистични техники в реакция при инциденти (запазване на изображения на виртуална машина).

Свързани ръководства¶

• NAS и RAID масивът са влошени, отказ на множество устройства и възстановяване на ZFS/Btrfs
• NVMe или SSD внезапно влиза в режим само за четене или изчезва от BIOS
• Повреда на твърдия диск и спешно възстановяване на данни
• Грешка при зареждане на Linux системата и поправка на GRUB
• Син екран на Windows (BSOD) и ремонт на зареждане
• Компютърни резервни копия: стратегия 3-2-1 и възстановяване след бедствие
• Глобални номера за спешни повиквания