Порушений ланцюжок знімків віртуальної машини (.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 overlays), де кожен окремий блок, записаний після створення знімка, зберігається виключно всередині дочірніх дельта-файлів, тоді як вихідний базовий диск залишається замороженим у минулому.

Якщо ви бачите такі помилки, як "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, перенаправляючи віртуальну машину безпосередньо на базовий диск (flat.vmdk або база .vhdx) і його завантаження є фатальним. Це завантажує сервер, як він існував 6 місяців тому, коли було створено перший знімок, миттєво скасовуючи криптографічний батьківський і дочірній зв’язок GUID/CID і відтворюючи кожен дельта-миттєвий знімок з цієї дати як сироту та неможливий для об’єднання.

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

Зробіть це зараз¶

Якщо віртуальна машина відмовляється запускатися або видає помилку розірваного ланцюжка знімків/пошкодженого віртуального диска:

1. НІКОЛИ не змінюйте налаштування віртуальної машини для завантаження безпосередньо з базового диска (Server.vmdk або Server.vhdx) коли дельта знімки (-000001.vmdk або .avhdx) існують у папці. У той момент, коли гостьова операційна система завантажується безпосередньо з базового батьківського диска навіть протягом 2 секунд, гостьова ОС записує мітки часу завантаження та оновлення журналу NTFS/ext4 на базовий диск, змінюючи Ідентифікатор вмісту батьківського диска (CID) у VMware або Linkage GUID / Timestamp у Hyper-V. Це єдине завантаження розриває весь ланцюжок дочірніх знімків, які залежать від того, що базовий диск залишається порозрядно замороженим. Якщо у вашій серверній кімнаті сталася активна пожежа, збій охолодження або фізична небезпека, евакуюйтеся та зателефонуйте за місцевим номером служби екстреної допомоги (911 у Сполучених Штатах і Канаді, 112 у всьому Європейському Союзі, 999 у Великобританії) або перевірте номери екстрених служб.
2. НІКОЛИ не видаляйте .avhdx, -delta.vmdk, або -sesparse.vmdk файли в Провіднику Windows або браузері сховища даних ESXi, щоб «звільнити місце на диску». На відміну від звичайних тимчасових файлів, .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. Відобразіть точний ланцюжок залежностей Parent -> Child за допомогою команд перевірки лише для читання (vmkfstools -e, Get-VHD, або qemu-img info --backing-chain) перед тим, як торкнутися одного байта. Кожен заголовок файлу знімка явно вказує точну назву батьківського файлу та батьківський криптографічний ідентифікатор, який він очікує розташувати безпосередньо над ним.

flowchart TD
    A["Віртуальна машина відмовляється завантажуватися: зламаний ланцюжок знімків, невідповідність батьківського CID або пошкоджений VMDK/VHDX/QCOW2"] --> B["СТОП: НЕ завантажуйте безпосередньо основний диск і НЕ видаляйте файли -delta.vmdk або .avhdx"]
    B --> C["Крок 1. Перевірте сховище даних хосту/вільний том (`df -h` / `список файлової системи зберігання esxcli`)"]
    C --> D["Крок 2: Скопіюйте всі базові файли та файли знімків на додатковий резервний диск NAS/SAN/USB перед зміною"]
    D --> E{"Який формат гіпервізора/віртуального диска впливає?"}
    E -->|"1. VMware ESXi / Workstation (.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 -->|"Відсутній текстовий дескриптор `.vmdk` розміром 1 КБ (існує лише величезний `-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, кожен гіпервізор реалізує знімки, використовуючи ту саму фундаментальну архітектуру: односпрямований зв’язаний список батьківських дисків лише для читання та дочірнього дельта-диска для читання та запису.

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

• Коли віртуальна машина хоче записати новий блок сьогодні, вона записує ЛИШЕ у нижній листовий файл (Snapshot 2).
• Коли віртуальна машина хоче прочитати блок сьогодні, гіпервізор перевіряє Snapshot 2 перший. Якщо цей блок було змінено з 1 червня, він читає його з Snapshot 2. Якщо ні, він шукає ланцюжок Snapshot 1. Якщо його також не було змінено, він читає вихідний блок із Base Disk.
• Чому ланцюжки розриваються: Кожен дочірній знімок зберігає два строгі вказівники у своєму заголовку: (1) Шлях безпосереднього батьківського файлу та (2) 32-розрядний ідентифікатор вмісту (CID у VMware) або 128-розрядний зв’язок GUID (ParentUniqueId у Hyper-V), який генерується щоразу, коли батьківський диск відкривається для запису. Якщо хтось переміщує файл, перейменовує папку або ненадовго монтує батьківський диск у режимі читання-запису, батьківський CID / GUID зміни, і гіпервізор негайно відмовляється монтувати дочірній знімок, щоб запобігти пошкодженню тихого блоку.

Трек 1: Порятунок VMware ESXi & Workstation .vmdk ланцюжки знімків¶

У VMware ESXi один віртуальний диск фактично складається з двох окремих файлів для базового диска та двох окремих файлів для кожного знімка: 1. Маленький (-500 байт) файл дескриптора звичайного тексту (Server.vmdk і Server-000001.vmdk), що містить CID, parentCID, геометрія диска та точне ім’я файлу бінарного екстенту. (Примітка: стандартний веб-інтерфейс ESXi Datastore Browser приховує парні -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 та перейдіть до каталогу сховища даних віртуальної машини:

   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 Browser перестає відображати віртуальний диск, незважаючи на величезний розмір 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)¶

Якщо віртуальна машина відмовляється вмикатися за допомогою Failed to lock the file або Cannot open disk: Resource busy, інший хост ESXi у кластері (або пристрій Veeam/резервний HotAdd, який вийшов з ладу під час резервного копіювання) все ще підтримує блокування файлів SCSI/VMFS -flat.vmdk або -sesparse.vmdk: 1. Перевірте, чи резервна віртуальна машина проксі-сервера, що вийшла з ладу, все ще містить ваші робочі віртуальні машини .vmdk під’єднано до свого віртуального контролера SCSI: Відредагуйте налаштування віртуальних машин проксі-сервера Veeam/CommVault і видаліть усі застарілі підключені робочі диски (виберіть «Видалити з віртуальної машини», НІКОЛИ не «Видалити файли зі сховища даних»). 2. Знайдіть MAC-адресу хоста ESXi і світовий процес, який утримує блокування 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 (Найновіший активний листовий диск)

Крок 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 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 файли у вашій папці, які більше не відображаються в дереві «Контрольних точок» графічного інтерфейсу користувача 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 (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: позаполосне відновлення файлів (видобування файлів, коли віртуальна машина все ще не завантажується)¶

Що робити, якщо гостьова операційна система на віртуальному диску не завантажується, або середній знімок у ланцюжку частково пошкоджено, і вам потрібно витягнути бази даних 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 змінить заголовок диска) і натисніть ОК. Диски C: і D: вашої віртуальної машини негайно з’являться у Провіднику файлів Windows.

Спосіб 3: Реконструкція сильно пошкоджених ланцюгів за допомогою UFS Explorer Professional Recovery¶

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

Доріжка 5: Відновлення загубленого файлу конфігурації віртуальної машини (.vmx, .xml, або <vmid>.conf)¶

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

Якщо ви відтворите замінну оболонку віртуальної машини з неправильним контролером віртуальної пам’яті або режимом мікропрограми, гостьова операційна система негайно завершить роботу під час завантаження з INACCESSIBLE_BOOT_DEVICE (Windows) або перейдіть до a dracut / initramfs аварійна оболонка (Linux). Зіставте ці чотири апаратні параметри з початковою конфігурацією гостьової системи, перш ніж підключати врятований віртуальний диск:

Часті запитання¶

Джерела перевірені¶

• VMware від Broadcom Technical Knowledge Base: KB 1007969 / 316578 (Вирішення помилок невідповідності CID «батьківський віртуальний диск було змінено після створення дочірнього»), KB 1002511 (відновлення відсутнього дескриптора диска віртуальної машини). .vmdk File) і KB 10051 (Розуміння моментальних знімків віртуальної машини в ESXi).
• Microsoft Learn / Windows Server Hyper-V Engineering Documentation: Hyper-V PowerShell Reference for Get-VHD, Set-VHD -IgnoreIdMismatch, і Merge-VHD Offline Differencing Disk Consolidation.
• Документація щодо віртуалізації проекту QEMU та 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 і аварійне відновлення
• Глобальні номери екстрених служб