Відновлення даних з дисків віртуальних машин: все, що потрібно знати

Віртуалізація забезпечує надзвичайну гнучкість сучасних ІТ-середовищ, але водночас може ускладнювати процес відновлення даних у разі їх втрати. На відміну від традиційних систем зберігання, у яких файлові системи розміщуються безпосередньо на локальних накопичувачах, віртуальні машини функціонують у межах багаторівневих структур; їхні віртуальні диски, знімки стану, відомі як снепшоти (з англ. snapshots), та розділи гостьової системи часто зберігаються в сховищі даних на рівні хоста.

Через таку багаторівневу побудову звичайні методи відновлення даних не завжди підходять для віртуальних сховищ. Ба більше, стандартні операції з керування такими сховищами, наприклад, запуск нестабільної віртуальної машини для визначення сутності проблеми або виконання автоматичної перевірки диска без нагляду, можуть призвести до небажаного запису даних і ускладнити процес відновлення.

Тому безпечне відновлення даних у віртуалізованих середовищах вимагає системного підходу: визначення рівня, на якому виникла проблема (хост, система віртуалізації чи гостьова ОС) та аналізу ланцюжка снепшотів віртуального сховища без зміни вихідних даних. У цьому посібнику ви знайдете огляд основних варіантів побудови віртуальних дисків, а також перелік типових сценаріїв втрати даних з таких сховищ і заходів, які варто вжити для безпечного відновлення інформації з віртуальних машин.

Основи відновлення даних з віртуальних машин

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

Дізнатися більше: отримайте загальне уявлення про віртуальні машини та особливості зберігання даних на віртуальних дисках, ознайомившись з відповідною статтею.

Для відновлення даних з віртуальних машин слід розуміти принципи організації їхніх вкладених рівнів абстракції та, за потреби, вміти опрацьовувати їх у відповідній послідовності:

• Фізичне обладнання для зберігання даних і засоби підключення (SAS/SATA, NVMe, SAN): це базовий рівень фізичних носіїв і засобів підключення, що забезпечує доступ до необроблених чи сирих даних (з англ. raw). Збої на цьому рівні можуть бути зумовлені несправністю обладнання, наявністю пошкоджених (битих) секторів, пошкодженням носіїв або проблемами з підключенням та нерідко вимагають професійного втручання в апаратну частину або створення образу диска перед виконанням відновлення за допомогою програмного забезпечення.

  Дізнатися більше: за покроковими інструкціями, будь ласка, зверніться до статті про створення образу диска.

• Рівень агрегації та пулів зберігання (апаратний або програмний RAID, пули ZFS, Windows Storage Spaces, HCI-платформи, як-от Ceph або vSAN від VMware): проміжний рівень, що об'єднує кілька фізичних накопичувачів у єдине логічне сховище за допомогою методів чергування (з англ. striping), дзеркалювання (з англ. mirroring) та обчислення парності (з англ. parity). У разі виникнення проблем або повного виходу з ладу цього рівня масив дисків чи пул вимагатиме віртуальної реконструкції, перш ніж можна буде отримати доступ до даних у ньому через хост-систему.

  Дізнатися більше: будь ласка, перегляньте наш посібник із відновлення даних з RAID, щоб дізнатися більше про поширені типи RAID, випадки втрати даних з них та методи їх відновлення.

• Файлова система або сховище даних (datastore) на рівні хоста (VMFS-5/6, CSVFS, ReFS, NFS, GlusterFS): рівень хоста, що використовується для розміщення та керування файлами віртуальних дисків або іншими ресурсами віртуального сховища.

  Дізнатися більше: будь ласка, ознайомтеся з детальним оглядом кластерних файлових систем, особливостями їхньої будови та поширеними типами.

• Контейнер віртуального диска (VMDK, VHD/VHDX, QCOW2, VDI): представлення віртуального диска, що надає гостьовій системі простір адресації логічних блоків та може містити специфічні для формату метадані, які описують виділені блоки, віртуальну геометрію та ємність.

• Рівень файлів змін або снепшотів (SESparse, AVHD/AVHDX, ланцюжки залежностей QCOW2): розріджені (з англ. sparse) рівні, що використовують механізм перенаправлення запису (з англ. redirect-on-write) для збереження змін, що стосуються батьківського віртуального диска; вони покладаються на специфічні для формату метадані зв'язку між батьківським та дочірніми елементами для відтворення повного стану віртуального диска.

• Схема розподілу на розділи і менеджер томів гостьової системи (GPT/MBR, LVM у Linux, LDM у Windows): внутрішня структура гостьової віртуальної машини, яка визначає межі розділів, логічні томи, динамічні томи або конфігурацію програмного RAID.

• Файлова система гостьової ОС (NTFS, ReFS, Ext4, XFS, Btrfs, APFS): логічний рівень, що організовує файли користувача, каталоги, метадані файлів, журнали та структури розподілу даних.

Проте деякі з цих рівнів, наприклад, RAID, снепшоти або менеджери томів гостьової системи, є необов'язковими й можуть бути відсутніми в певних середовищах.

Оскільки віртуальні машини можуть мати кілька вкладених рівнів зберігання даних, спроби отримати доступ до них, як зазвичай, тобто через гіпервізор або безпосередньо в гостьовій ОС, можуть змінити метадані чи інші структури сховища, необхідні для успішного відновлення даних. Щоб запобігти зміні цих структур через виконання автоматизованих фонових операцій, кожен етап відновлення даних з диска віртуальної машини має виконуватися з дотриманням принципу неінвазивного втручання:

• Віртуальне збирання має здійснюватися виключно в режимі лише для читання: відновлення не слід виконувати шляхом завантаження віртуальної машини або запуску утиліт для виправлення помилок (наприклад, chkdsk чи fsck) безпосередньо на вихідному віртуальному диску, оскільки такі операції можуть змінити метадані файлової системи та ускладнити подальше відновлення. Натомість безпечне відновлення передбачає доступ до віртуального диска та його ключових структур у режимі лише для читання, відтворення відповідних рівнів віртуального диска та знімків (снепшотів) без зміни вихідних даних з подальшим аналізом або копіюванням файлів із отриманого віртуального образу.

Контейнери віртуальних дисків і розподіл даних

Гіпервізори інкапсулюють сховище гостьової системи у спеціальні файли віртуальних дисків або віртуальні сховища інших форматів. Кожен формат використовує власні структури метаданих для зіставлення блоків віртуального диска з місцями розташування даних у сховищі хоста:

• VMware Workstation та ESXi (VMDK): середовища VMware підтримують кілька варіантів VMDK, зокрема плаский (з англ. flat) та розріджений (з англ. sparse) формати. У сховищах даних ESXi (з англ. datastores) віртуальний диск може складатися з невеликого дескрипторного файлу (.vmdk), що містить метадані диска та екстенту, а також плаского екстенту (-flat.vmdk), що містить власне дані віртуального диска. Розріджені формати (зокрема розріджений файл VMDK та ESXi SESparse) виділяють простір динамічно, використовуючи одиниці, що називаються "зернами" (з англ. grains). Якщо файл-дескриптор втрачено, інформацію з нього іноді можна відновити з відповідного екстенту та інших метаданих. Однак у разі пошкодження зерен або таблиць розподілу може знадобитися відновлення зіставлення віртуальних блоків, перш ніж можна буде отримати доступ до файлової системи гостьової ОС. Деякі формати VMDK також дозволяють розподіляти віртуальний диск між кількома файлами екстентів; втрата або пошкодження одного з таких екстентів може зробити відповідні частини віртуального диска недоступними.

• Hyper-V від Microsoft (VHD та VHDX): у файлах застарілого формату VHD використовується динамічна структура диска на базі таблиці розподілу блоків, і вони підтримують віртуальні диски розміром до 2 ТБ. У разі файлів VHDX максимальний розмір підтримуваного віртуального диска збільшується до 64 ТБ і у них застосовується механізм журналювання метаданих, розроблений для підвищення стійкості до переривання операцій запису та збоїв хоста. Якщо після некоректного завершення роботи виникає неузгодженість метаданих, віртуальний диск може вимагати структурного аналізу або реконструкції, перш ніж можна буде отримати безпечний доступ до його вмісту.

• QEMU, KVM та Proxmox VE (QCOW2): формат QCOW2 використовує багаторівневі таблиці розподілу для зіставлення блоків диска гостьової системи з кластерами всередині файлу-контейнера та пропонує такі функції, як динамічне виділення простору, внутрішні знімки стану (з англ. snapshots), стиснення та опціональне шифрування. Оскільки логічні блоки гостьової системи можуть бути розміщені в контейнері не послідовно, для відновлення з віртуального диска критично важливою є цілісність метаданих розподілу даних. Тому пошкодження таблиць розподілу може унеможливити пряме отримання даних гостьової системи з файлу-контейнера.

• VirtualBox від Oracle (VDI): контейнери образів віртуальних дисків VirtualBox (VDI) використовують внутрішню таблицю розподілу блоків для зіставлення логічних блоків диска з місцями розташування усередині контейнера. Динамічні образи VDI виділяють місце на носії хоста в міру запису блоків гостьової системи, тому успіх відновлення залежить від цілісності метаданих розподілу блоків і відповідних блоків даних.

• Режими фізичного розподілу (так зване тонке та товсте виділення):

  • Диски з товстим виділенням (з фіксованим розподілом): заздалегідь резервують увесь віртуальний простір для зберігання. Залежно від формату віртуального диска та файлової системи хоста, розміщення даних на фізичному носії може бути безперервним або фрагментованим. Тож попереднє виділення місця для зберігання саме по собі не гарантує передбачуваного розташування фізичних секторів.

  • Диски з тонким виділенням (з динамічним розподілом): виділяють місце на носії хоста поступово, у міру запису даних; при цьому відповідність між розміщенням на віртуальному диску та на фізичному носії підтримується за допомогою спеціальних структур розподілу, властивих конкретному формату. У разі пошкодження або втрати цих структур може знадобитися відновлення зіставлення віртуальних блоків, перш ніж можна буде отримати доступ до розділів і файлових систем гостьової ОС.

• Шифрування: дані віртуальної машини можуть бути зашифровані на різних рівнях: усередині гостьової операційної системи, на рівні віртуального диска чи сховища даних або засобами самої платформи для зберігання даних. Метод шифрування і рівень, на якому його застосовано, визначають, які облікові дані або ключі знадобляться для доступу до даних під час відновлення.

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

• Геометрія логічних і фізичних секторів (512n, 512e та 4Kn): віртуальні диски можуть представляти гостьовій системі розмір логічного сектора 512 байтів або 4 КБ, незалежно від реального розміру секторів носія. Під час відновлення або монтування віртуального диска необхідно зберігати відповідність між розміром логічного сектора віртуального диска, параметрами сховища хоста та структурою розділів гостьової системи. Неправильна інтерпретація розміру сектора може призвести до помилок у перерахунку LBA в байти, через що коректні таблиці розділів, завантажувальні записи томів і структури файлових систем можуть почати сприйматися як пошкоджені або недоступні.

Архітектури снепшотів і ланцюжки файлів змін

Знімки стану (снепшоти) віртуальних машин — це спосіб тимчасової фіксації відмінностей, а не повноцінні резервні копії. Пошкоджені, неправильно налаштовані або загублені ланцюжки знімків можуть ускладнити доступ до поточного стану віртуального диска та погіршити втрату даних у віртуалізованих середовищах.

• Перенаправлення запису та ієрархія ланцюжків: під час створення знімка (снепшоту) гіпервізор фіксує поточний стан батьківського віртуального диска й перенаправляє подальші операції запису до новоствореного розрідженого файлу змін (наприклад, *-000001.vmdk або .avhdx). Додаткові знімки можуть подовжувати цей ланцюг: кожен наступний файл (дельта-файл) зберігає зміни, що стосуються його батьківського елемента, тоді як нові записи робляться у найновішому.

• Перевірка відповідності "батьківський — дочірній елемент": різні формати знімків (снепшотів) використовують власні метадані, що пов'язують кожен файл змін із батьківським. Якщо цей зв'язок порушується (наприклад, через перервану консолідацію або самостійну зміну батьківського диска), гіпервізор, ймовірно, не матиме змоги коректно відкрити або завантажити відповідний ланцюжок знімків віртуального диска. Тож для відновлення даних потрібно встановити правильні "батьківсько-дочірні" відносини і забезпечити використання правильних снепшотів.

• Відтворення поточного стану віртуального диска: для повного відновлення даних необхідно відтворити стан віртуального диска, послідовно застосовуючи кожен файл змін до батьківського у правильному порядку — зазвичай від базового диска до найновішого файлу змін. Відновлення лише базового віртуального диска надає доступ лише до найстаріших даних і може не відображати зміни, збережені в наступних знімках (зокрема оновлення файлової системи, зміни в базах даних і нещодавно записані дані користувача).

Типи збоїв: фізичні несправності, проблеми на рівні хоста чи контейнера та логічні помилки

Віртуальні машини можуть зазнавати збоїв на різних рівнях. Визначення ураженого рівня є критично важливим для вибору належного методу відновлення:

• Несправність фізичного носія: йдеться про несправності, що стосуються апаратного забезпечення, наприклад, вихід із ладу або нестабільна робота HDD/SSD, пошкоджені (биті) сектори, проблеми з контролером чи об'єднувальною платою, а також проблеми з підключенням на рівні пристрою. Такі випадки можуть вимагати втручання в апаратне забезпечення або створення образу диска перед виконанням власне логічного відновлення даних.

• Збої на рівні інфраструктури сховища та хоста: проблеми на шляху доступу до сховища або на рівні системи зберігання хоста, а не в самому віртуальному диску. До таких проблем належать збої підключення SAN/NAS, перебої в роботі мережі зберігання даних, недоступність пулів зберігання або пошкодження метаданих сховища (наприклад, структур VMFS чи CSVFS). У таких випадках файли віртуальних дисків можуть залишатися неушкодженими, але гіпервізор втрачає доступ до сховища даних (з англ. datastore), у якому вони розміщені.

• Пошкодження віртуальних дисків і знімків (снепшотів): мова про порушення цілісності структур віртуального диска або знімків. Це може бути пошкодження заголовків контейнерів і метаданих розподілу, порушення зв'язків "батьківський — дочірній елемент" між файлами змін, а також переривання процесу консолідації знімків через раптову втрату живлення або брак місця у сховищі. Якщо важливі метадані контейнера пошкоджені або неузгоджені, гіпервізор не матиме змоги коректно ініціалізувати чи підключити віртуальний диск.

• Логічні пошкодження на рівні гостьової системи: йдеться про пошкодження даних або їх втрату безпосередньо на віртуальному диску. Контейнер віртуального диска та ієрархія його знімків (снепшотів) можуть залишатися неушкодженими, тоді як дані гостьової системи страждають від випадкового видалення файлів, пошкодження метаданих файлової системи (наприклад, структур каталогів або бітових карт розподілу), неможливості завантаження операційної системи чи шифрування шкідливою програмою-вимагачем (з англ. ransomware).

• Видалення контейнера та звільнення простору для зберігання: мова про ситуації, коли файли .vmdk, .vhdx або .qcow2 випадково видаляються безпосередньо зі сховища даних (з англ. datastore). У накопичувачах на базі флешпам'яті або із тонким виділенням механізми звільнення простору, як-от TRIM або UNMAP, можуть повідомляти системі, що вивільнені блоки більше не потрібні. Подальше переписування блоків чи їх повне очищення у результаті операції "збирання сміття" (з англ. garbage collection) може зробити попередній вміст цих блоків недоступним, що залишає критично малий проміжок часу, протягом якого відновлення видалених файлів контейнерів взагалі можливе.

  Дізнатися більше: щоб дізнатися, як підібрати програмне забезпечення для різних сценаріїв логічної втрати даних, будь ласка, перегляньте нашу статтю про вибір програми для відновлення даних.

Скористатися програмою чи звернутися до фахівців з відновлення?

Вибір між використанням спеціалізованого програмного забезпечення та зверненням до фахівців з відновлення даних залежить насамперед від фізичного стану носія інформації та характеру логічного збою. Спеціалізоване ПЗ здатне працювати зі складними структурами віртуальних дисків, порушеними ланцюгами знімків (снепшотів) і пошкодженими сховищами даних (з англ. datastore), однак для нормальної роботи йому потрібно, щоб фізичний носій був повністю справним та працював без збоїв.

Коли доцільно використовувати програмне забезпечення для самостійного відновлення даних:

• Фізичний носій даних не був ушкоджений: жорсткі диски, SSD, RAID-масиви та контролери працюють у штатному режимі, не відключаються від хост-системи і не видають помилок читання.

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

• Логічна втрата або пошкодження даних у гостьовій системі: випадкове видалення файлів, форматування розділів або пошкодження структури файлової системи всередині віртуальної машини за умови, що фізичне сховище залишається стабільним і доступним для читання.

• Сховище даних (datastore) недоступне через проблеми логічного характеру: сховище гіпервізора (наприклад, VMFS або CSVFS) стало недоступним після збою хоста, раптового перезавантаження або втрати зв'язку, тоді як фізичне сховище залишається справним і його можна без проблем зчитати або створити з нього образ.

Коли варто звернутися до лабораторії з професійного відновлення даних:

• Кількість несправних дисків перевищує можливості надлишковості: йдеться про вихід з ладу кількох дисків пулу зберігання даних або RAID-масиву, що перевищує межу відмовостійкості застосованої конфігурації.

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

• Фізичне пошкодження або вплив зовнішніх чинників: сервери, дискові масиви чи окремі диски зазнали ушкоджень від електричного струму або через пожежу, задимлення, потрапляння у воду чи інший несприятливий вплив зовнішнього середовища. У таких випадках може знадобитися діагностика на апаратному рівні та, у разі певних несправностей HDD, втручання в умовах "чистої кімнати" перед безпечним створенням посекторного образу диска.

Ключовий етап відновлення з дисків віртуальних машин

Якщо гіпервізор не може змонтувати сховище даних (з англ. datastore) або підключити віртуальний диск, для відновлення може знадобитися доступ до самого носія даних в обхід стандартних процедур керування через гіпервізор. Спеціалізоване програмне забезпечення для відновлення даних здатне проаналізувати відповідні структури сховища, знайти контейнери віртуальних дисків і допомогти відновити порушені зв'язки між віртуальними дисками та їхніми знімками (снепшотами):

• Безпосередній аналіз сховища даних (datastore): якщо файлова система або сховище даних (datastore) хоста стають недоступними, програмне забезпечення для відновлення даних може отримати доступ до відповідного LUN, RAID-масиву або фізичного носія в обхід гіпервізора. Аналізуючи внутрішні метадані сховища, програма може знайти файли віртуальних дисків і скопіювати їх на інший носій.

• Відновлення пошкоджених дескрипторів дисків: у разі втрати або пошкодження текстового файлу-дескриптора (наприклад, дескриптора VMDK) відповідний екстент віртуального диска може перестати коректно розпізнаватися. За наявності достатньої інформації сумісний дескриптор можна відтворити, використовуючи такі параметри, як обсяг віртуального диска, структура розміщення екстентів та інші метадані, специфічні для застосовного формату.

• Усунення невідповідностей у ланцюжках і зв'язках: цілісність ланцюжків знімків може порушитися через зміну зв'язків "батьківський — дочірній елемент" або пошкодження метаданих (наприклад, внаслідок перерваної консолідації знімків чи некоректного завершення роботи). Спеціалізоване ПЗ для відновлення даних може проаналізувати ці зв'язки та відтворити правильний ланцюжок у віртуальному режимі, не змінюючи при цьому вихідні файли віртуальних дисків.

• Віртуальне об'єднання: замість того, щоб консолідувати снепшоти, так би мовити, у реальному часі, програма для відновлення може віртуально відтворити ланцюжок файлів змін. Базовий диск і відповідні файли змін будуть представлені як єдиний віртуальний диск у режимі лише для читання, а запити до секторів оброблятимуться відповідно до ієрархії знімків — від найновішого актуального знімка до базового диска. Таке відтворене у віртуальному режимі сховище можна проаналізувати та використати для відновлення даних.

Дізнатися більше: будь ласка, ознайомтеся зі статтею про те, як відкрити віртуальний диск у програмі UFS Explorer для подальшої обробки.

Застереження під час відновлення даних з віртуальних машин

Оскільки віртуальні машини інкапсулюють кілька вкладених рівнів зберігання даних, стандартні процедури з адміністрування сховища та автоматизовані операції на ньому можуть змінити або перезаписати важливі структури метаданих, що стануть у пригоді у разі втрати даних. Дотримання наступних принципів неінвазивної роботи зі сховищем допомагає захистити вихідні віртуальні диски та томи сховищ даних (з англ. datastore) протягом усієї процедури відновлення:

• Не завантажуйте віртуальну машину та не застосовуйте і не консолідуйте знімки (снепшоти): якщо віртуальна машина не завантажується або повідомляє про пошкодження тома, не користуйтеся інструментами керування гіпервізора для консолідації, видалення або відновлення зі знімків (снепшотів). Такі операції можуть змінювати метадані знімків або записувати зміни до ланцюжка знімків, що лише ускладнить подальше відновлення.

• Не запускайте утиліти для автоматизованого відновлення файлової системи на рівні гостьової системи: не запускайте інструменти з відновлення файлової системи, як-от chkdsk або fsck, безпосередньо на вихідному віртуальному диску, якщо цілісність його даних не підтверджена. Ці утиліти можуть змінювати метадані файлової системи та структури розподілу даних, що потенційно може призвести до перезапису інформації, яка може знадобитися для відновлення.

• Налаштуйте доступ у режимі лише для читання до сховищ даних хоста (datastore) та LUN: під час підключення до дискових масивів, LUN сховищ SAN або спільних томів з машини-хоста, за допомогою якої ви плануєте відновити дані, за можливості налаштуйте доступ лише для читання. Запобігайте автоматичному монтуванню або зміні нерозпізнаних томів операційною системою, оскільки навіть випадкові разові записи можуть зачепити видалені або загублені файли віртуальних дисків та інші метадані, які можуть стати у пригоді під час відновлення.

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

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

• Завжди зберігайте відновлені дані в окремому сховищі призначення: не записуйте образи віртуальних дисків, перетворені контейнери або відновлені файли назад у вихідне сховище даних (datastore) або на вихідний носій. Збережіть результати на окремому пристрої або у окремому томі сховища, щоб запобігти перезапису тих даних, які все ще можна відновити.

Дізнатися більше: покрокова процедура відновлення даних з віртуальних дисків наведена у відповідній статті.

Останнє оновлення: 01 жовтня 2026

Якщо вам сподобалася ця стаття, поділіться нею у соцмережах: