Hyper-V під мікроскопом: відновлюємо VHDX, AVHDX і дані гостьової ОС

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Нещодавно ми тестували відновлення даних віртуальних машин Hyper-V у Windows Server 2022. Нас цікавив не звичайний backup/restore, а сценарії після втрати даних: видалення файлів віртуальної машини, видалення інформації всередині гостьової ОС, робота з Checkpoints і ситуація, коли сам файл VHDX уже неможливо відновити як цілісний віртуальний диск.

Тестове середовище

Для тесту використовували Windows Server 2022 з Hyper-V. Сховище було побудоване на Windows Storage Spaces з типом resiliency Parity. У нашій конфігурації за принципом розподілу даних і парності це близький аналог RAID 5, але це саме програмне сховище Storage Spaces, а не класичний апаратний RAID 5.

Логічний том додатково був зашифрований BitLocker, а вже на ньому зберігалися файли Hyper-V. Тобто стек виглядав приблизно так:

Physical disks → Storage Pool → Storage Spaces Parity → BitLocker → REFS → Hyper-V → VHDX / AVHDX → файлова система гостьової ОС

Для відновлення це важливо, оскільки дані знаходяться одразу на декількох рівнях абстракції.

Спочатку потрібно правильно реконструювати Storage Spaces, потім отримати доступ до BitLocker-тому, відновити файлову систему хоста і вже після цього працювати з Hyper-V.

Що саме зберігає Hyper-V

Основний диск віртуальної машини зберігається у файлі VHDX. Після створення Checkpoint базовий диск перестає отримувати нові зміни безпосередньо. Hyper-V створює differencing disk у форматі AVHDX, куди записуються наступні зміни.

Якщо Checkpoints декілька, формується залежний ланцюжок:

VHDX → AVHDX → AVHDX → ...

Тому знайдений VHDX ще не означає, що ми отримали останній стан віртуальної машини.

Крім того, для повного відновлення VM важливі конфігураційні файли VMCX, VMRS та пов’язаний ланцюжок Checkpoints.

Тест 1. Видалення віртуальної машини

У першому сценарії перевіряли відновлення файлів самої VM. Після реконструкції Storage Spaces Parity та розблокування BitLocker аналізували REFS-том, на якому зберігалася Hyper-V.

Основне завдання — знайти не окремий VHDX, а всю директорію віртуальної машини. Особливо це важливо, якщо використовувалися Checkpoints. Якщо відновити лише базовий VHDX, можна отримати старіший стан диска без змін, які залишилися в AVHDX.

Тому ми відновлювали всю папку VM разом із віртуальними дисками, конфігурацією та Checkpoints.

Тест 2. Видалені файли всередині гостьової ОС

Другий сценарій відрізнявся тим, що саме сховище та Hyper-V залишалися працездатними, але дані були видалені всередині гостьової Windows.

У такій ситуації необов’язково запускати саму VM. VHDX можна розглядати як окремий дисковий контейнер, усередині якого знаходиться ще одна файлова система.

У нашому випадку:

REFS хоста → VHDX → NTFS гостьової Windows

Після монтування віртуального диска ми отримали доступ до розділів гостьової системи та проаналізували їх аналогічно звичайному фізичному накопичувачу.

Видалені файли вдалося знайти без запуску Windows усередині Hyper-V. Цей підхід може бути корисним, коли потрібно витягти з VM лише окремі документи, бази даних або інші файли, не відновлюючи працездатність усієї віртуальної машини.

Тест 3. Checkpoints та AVHDX

Окремо перевіряли роботу з Checkpoints. Hyper-V не створює повну копію VHDX для кожної контрольної точки. Замість цього використовується базовий диск та один або декілька differencing disks AVHDX.

У тестовій VM було два AVHDX, які відповідали різним станам системи. Після завантаження всієї папки VM вдалося визначити базовий VHDX і пов’язані з ним AVHDX. У результаті можна було аналізувати дані з різних станів віртуальної машини.

Наприклад, якщо файл був присутній на момент створення одного Checkpoint, але пізніше видалений, його дані можуть залишатися доступними через попередній стан ланцюжка. При цьому Checkpoint не є заміною резервної копії.

VHDX та AVHDX утворюють залежну структуру, і втрата одного з важливих елементів може зробити VM непридатною для звичайного запуску.

З погляду відновлення даних ситуація трохи інша: навіть якщо Hyper-V уже не може запустити машину, з доступних елементів ланцюжка все ще можна спробувати витягти файли.

Тест 4. Якщо VHDX уже не відновлюється

Найцікавішим виявився сценарій із пошкодженим або частково втраченим VHDX.

Тут має значення тип віртуального диска.

Fixed size VHDX одразу резервує необхідний простір, тому його дані зазвичай розташовані передбачуваніше. Dynamically expanding VHDX збільшується в процесі використання. Його блоки можуть бути розташовані на файловій системі хоста фрагментовано.

Після видалення такого VHDX частина метаданих контейнера може бути втрачена або перезаписана. У результаті файл начебто відновлений, але як коректний Hyper-V disk він уже не відкривається.

Тоді ми спробували перейти ще на один рівень нижче.

Замість пошуку структури самого VHDX виконали повний аналіз сховища за файловою системою, яка використовувалася всередині гостьової VM.

У нашому випадку це була NTFS.

Тобто замість:

REFS хоста → VHDX → NTFS гостя

Ми намагалися знайти структури гостьової NTFS безпосередньо серед доступних блоків сховища. У результаті вдалося знайти дані файлової системи гостьової Windows і перейти безпосередньо до її файлів.

Саму працездатну VM таким способом уже не відновити. Але якщо головна задача — витягти документи, бази даних, архіви або іншу важливу інформацію, цей підхід все ще може дати результат.

Що показав тест

Для себе ми виділили кілька практичних моментів. По-перше, при відновленні Hyper-V бажано працювати не з одним VHDX, а з усією директорією VM, особливо якщо використовувалися Checkpoints.

По-друге, VHDX варто розглядати як окремий рівень сховища. Навіть якщо сама VM не запускається, файлова система всередині віртуального диска може залишатися доступною.

По-третє, AVHDX можуть містити попередні стани даних. Тому Checkpoints іноді дозволяють знайти інформацію, якої вже немає в актуальному стані гостьової системи.

І нарешті, пошкоджений VHDX ще не означає, що всі дані всередині нього втрачені.

Якщо структуру самого контейнера Hyper-V відновити неможливо, можна спробувати перейти нижче та знайти файлову систему гостьової ОС безпосередньо на рівні блоків сховища.

Саме багаторівневість цього сценарію здалася нам найцікавішою:

Storage Spaces Parity → BitLocker → REFS → Hyper-V → VHDX/AVHDX → NTFS гостьової системи.

На кожному з цих рівнів може виникнути окрема проблема, але водночас втрата верхнього рівня не завжди означає втрату інформації на нижньому.

Чим проводили тест

Для реконструкції Windows Storage Spaces Parity, розблокування BitLocker, аналізу файлової системи та роботи з віртуальними дисками Hyper-V у цьому тесті ми використовували Hetman RAID Recovery.

Також записали повну відеодемонстрацію тесту — від структури Windows Storage Spaces і Hyper-V до пошуку та відновлення даних із VHDX/AVHDX: