Як відновити віртуальні диски та снапшоти KVM/QEMU з LUKS2 RAID 6
-
Автор:
Valery Martyshko
-
Редактор:
Vladyslav Kupriyenko
У цій статті розглянуто відновлення віртуальних дисків і снапшотів KVM/QEMU зі сховища, побудованого на LUKS2 та RAID 6. Основну увагу приділено визначенню правильної послідовності рівнів відновлення, безпечній роботі з образами фізичних дисків, реконструкції RAID-масиву, відкриттю зашифрованого контейнера, пошуку QCOW2/RAW-образів, аналізу backing chain та відновленню доступу до даних віртуальних машин без внесення змін до оригінальних носіїв.
- КРОК 1. Створення віртуальної машини KVM/QEMU
- КРОК 2. Створення снапшота і видалення LUKS2-розділу
- КРОК 3. Підключення дисків і початок відновлення
- КРОК 4. Автоматичне визначення MD RAID 6 і LUKS2-розділів
- КРОК 5. Аналіз LUKS2-розділу та відновлення файлів віртуальної машини
- КРОК 6. Монтування віртуальних дисків та снапшотів
- КРОК 7. Порівняння станів диска та відновлення файлів зі снапшота
- КРОК 8. Пошук даних за файловими системами віртуальних дисків
- Підсумки
- Поширені запитання
- Коментарі
У сучасних серверних середовищах віртуалізація на базі KVM/QEMU часто використовується разом із програмними RAID-масивами та шифруванням дисків. Така архітектура дає змогу поєднати продуктивність, відмовостійкість і захист даних, однак суттєво ускладнює процедуру відновлення у разі пошкодження накопичувачів, RAID-метаданих, контейнера LUKS2, файлової системи або ланцюжка снапшотів віртуальних машин.
Особливо складними є випадки, коли віртуальні диски KVM/QEMU у форматах QCOW2, RAW або інших сумісних форматах розміщені всередині зашифрованого сховища LUKS2, яке, своєю чергою, побудоване поверх RAID 6. У такій конфігурації доступ до даних залежить одразу від кількох рівнів: фізичних накопичувачів, структури RAID-масиву, коректності LUKS2-метаданих, файлової системи та внутрішньої структури віртуальних дисків.
Додаткову складність створюють снапшоти QEMU/KVM. Вони можуть утворювати ланцюжок залежних QCOW2-файлів, де кожен наступний образ містить лише змінені блоки та посилається на базовий диск або попередній снапшот. Втрата одного з елементів такого ланцюжка, пошкодження backing file або неправильне визначення їх послідовності може призвести до неможливості запуску віртуальної машини навіть за умови, що більшість даних фізично залишилася на накопичувачах.
Як відновити віртуальні диски та снапшоти KVM/QEMU з LUKS2 RAID 6
КРОК 1. Створення віртуальної машини KVM/QEMU
Для тестування ми встановили Ubuntu Server 24.04 і через Cockpit зібрали програмний Linux MD RAID 6 із чотирьох дисків.
На RAID-масиві створили три розділи. Кожен із них зашифрували за допомогою LUKS2, а всередині зашифрованих контейнерів створили файлові системи Ext4. Третій розділ використали для зберігання віртуальної машини.
На сервері працював гіпервізор KVM/QEMU. Через Cockpit на третьому розділі ми створили окремий пул сховища для віртуальної машини – raid6-vm-images. Файли віртуальної машини зберігалися в каталозі vm-images.
Для віртуальної машини створили системний диск у форматі QCOW2 обсягом 32 гігабайти, а також два додаткові диски: QCOW2 на 2 гігабайти та IMG на 1 гігабайт.
На системний диск встановили Windows 10. Два додаткові диски вже всередині Windows відформатували у файлові системи NTFS та FAT32 відповідно.
КРОК 2. Створення снапшота і видалення LUKS2-розділу
На системний і два додаткові диски ми скопіювали початковий набір файлів, після чого створили зовнішній снапшот. Потім додали ще одну папку з файлами та частину з них видалили.
Після завершення тестових змін віртуальну машину вимкнули. Далі, папку vm-images із базовими образами дисків, файлами зовнішніх снапшотів і файлом стану оперативної пам’яті скопіювали на другий LUKS2-розділ RAID-масиву.
Щоб змоделювати втрату даних, через Cockpit ми видалили цей розділ із таблиці розділів. У результаті його область стала нерозподіленою. При цьому ми не форматували її та не записували туди нові дані, щоб зберегти можливість подальшого відновлення.
КРОК 3. Підключення дисків і початок відновлення
Після видалення розділу ми вимкнули сервер і дістали диски RAID-масиву. До комп’ютера з Windows 11 через USB-док-станцію підключили лише два з чотирьох накопичувачів.
Якщо після підключення Windows запропонує ініціалізувати або відформатувати диски, обов’язково натисніть Cancel. Не записуйте на них нові дані та не запускайте перевірку або виправлення помилок, оскільки це може погіршити результат відновлення.
Працювати з дисками можна й іншими способами. Наприклад, підключити їх до програми віддалено через SSH або змонтувати попередньо створені образи, якщо небажано працювати безпосередньо з оригінальними накопичувачами.
КРОК 4. Автоматичне визначення MD RAID 6 і LUKS2-розділів
Одразу після запуску Hetman RAID Recovery прочитала службову інформацію з двох підключених дисків.
RAID 6 допускає відсутність до двох накопичувачів. Оскільки обидва доступні диски були справними, а службова інформація збереглася, програма автоматично реконструювала MD RAID 6. Два відсутні накопичувачі відобразилися як Empty disk, а масив отримав статус Recoverable.
У властивостях видно схему Left Synchronous P+Q, розмір блоку 512 КБ, а також розташування, зміщення та розмір дисків.
На масиві програма знайшла три області з шифруванням LUKS2. Перший і третій розділи залишилися на місці, а видалений другий відображається як нерозподілений простір із позначкою LUKS.
КРОК 5. Аналіз LUKS2-розділу та відновлення файлів віртуальної машини
Двічі клацніть по нерозподіленій області з позначкою LUKS. Програма запропонує ввести пароль або вибрати ключ-файл.
Після розблокування стане доступною файлова система Ext4. Далі, оберіть режим аналізу.
Спочатку рекомендуємо запустити Fast Scan. Якщо швидке сканування не знайде потрібних даних, виконайте Full Analysis і вкажіть файлову систему Ext2/3/4.
У нашому випадку швидкого сканування було достатньо. Програма відновила структуру видаленого розділу та знайшла папку vm-images, у якій збереглися системний і додаткові віртуальні диски, а також файли їхніх снапшотів.
Важливо враховувати, що конфігурація віртуальної машини зберігається окремо від її дисків – зазвичай у каталозі /etc/libvirt/qemu. Якщо XML-файл конфігурації втрачено, дані з віртуальних дисків усе одно можна відновити, але для повторного запуску машини її конфігурацію доведеться створити заново.
Позначте папку з віртуальними дисками та файлами снапшотів і натисніть Recovery.
Рекомендуємо відновлювати всю папку повністю, щоб базові образи та пов’язані з ними снапшоти залишилися разом.
Для збереження виберіть інший фізичний накопичувач. Не відновлюйте файли назад на початковий RAID-масив, оскільки це може перезаписати дані, які ще можна відновити.
КРОК 6. Монтування віртуальних дисків та снапшотів
Якщо вам потрібно отримати доступ до даних усередині віртуальних дисків або снапшотів, а також знайти й відновити видалені файли, це можна зробити безпосередньо в нашій програмі.
Натисніть Mount Disk.
У вікні Disk Image Type, у групі Virtual Machine Disk Images, виберіть QEMU, оскільки в нашому тесті віртуальна машина та її диски були створені на базі KVM/QEMU. Якщо ж образи були створені в іншому середовищі віртуалізації, виберіть зі списку відповідний тип диска. Після цього натисніть Next.
На наступному кроці вкажіть не окремий файл образу, а папку, до якої ми відновили всі файли віртуальної машини. Важливо, щоб базові диски та пов’язані з ними снапшоти знаходилися разом і зберігали свої початкові назви.
Програма проаналізує вміст папки, визначить зв’язки між файлами та автоматично згрупує базові диски з відповідними снапшотами. Якщо для одного диска було створено кілька снапшотів, програма побудує їх у правильній послідовності. Останній стан кожного ланцюжка буде позначено як Active. Позначте потрібні диски та їхні стани й натисніть Next.
Після монтування вони з’являться в розділі Mounted Disks як окремі накопичувачі. На головному екрані позначка Active уже не відображається, тому базовий диск і його снапшоти можна розрізнити за назвами відповідних файлів.
КРОК 7. Порівняння станів диска та відновлення файлів зі снапшота
Щоб порівняти основний образ диска та його снапшот, потрібно проаналізувати обидва змонтовані диски. Двічі клацніть по кожному з них і спочатку запустіть Fast Scan.
Якщо швидке сканування не знаходить потрібних даних, виконайте Full Analysis. Під час повного аналізу необхідно вказати файлову систему, яка використовується всередині віртуального диска.
В основному образі зберігся попередній стан файлової системи.
На диску, змонтованому зі снапшота, відображаються зміни, зроблені пізніше: додана папка та видалені з неї файли, які програма позначає хрестиком.
Оскільки ці файли були записані вже після створення попереднього стану диска, шукати та відновлювати їх потрібно зі змонтованого снапшота.
Перевірте знайдені файли у вікні попереднього перегляду, яке підтримує багато поширених форматів. Тут можна переглянути вміст документів, список вкладених в архіви файлів, зображення, відео та інші дані. Попередній перегляд можна розгорнути на весь екран, що особливо зручно для перевірки зображень і відеозаписів.
Переконавшись, що вибрано потрібні файли, позначте їх і натисніть Recovery. Збережіть відновлені дані на інший фізичний накопичувач.
КРОК 8. Пошук даних за файловими системами віртуальних дисків
Якщо потрібні образи віртуальних дисків не були знайдені або їх не вдалося змонтувати, можна спробувати відновити дані безпосередньо за файловими системами, які використовувалися всередині цих дисків.
Для цього виберіть розблокований розділ RAID-масиву, запустіть майстер відновлення та оберіть Full Analysis.
Під час налаштування аналізу замість файлової системи Ext4, яка фактично використовувалася на цьому розділі для зберігання файлів віртуальних дисків, вкажіть файлові системи, розміщені безпосередньо всередині самих віртуальних дисків. У нашому випадку це FAT32 і NTFS, тому для пошуку вибираємо FAT та NTFS.
Такий спосіб найбільш ефективний для віртуальних дисків, під які весь простір був зарезервований одразу – preallocated. У цьому випадку дані віртуального диска фізично присутні всередині файлу образу, і програма може знайти та проаналізувати розміщену в ньому файлову систему навіть тоді, коли сам файл образу пошкоджений або втрачений.
Для тонких, або thin-provisioned, віртуальних дисків такий підхід, як правило, не дозволяє відновити диск повністю. У таких образах фізично зберігаються лише блоки, в які вже були записані дані, тоді як невикористаний простір не виділяється заздалегідь. Тому без структури самого образу окремі блоки віртуального диска можуть бути розташовані фрагментарно, і правильно відтворити всю файлову систему значно складніше.
Після завершення аналізу перевірте знайдені розділи та файли.
Цей метод може допомогти повернути окремі дані або навіть файлову систему з preallocated-диска, однак сам файл образу та його зв’язки зі снапшотами таким способом не відновлюються
Підсумки
У результаті Hetman RAID Recovery автоматично зібрала Linux MD RAID 6 із двох доступних дисків, знайшла видалений LUKS2-розділ, розблокувала його та відновила папку з образами дисків і снапшотами віртуальної машини.
Після монтування ми змогли переглянути стан дисків до і після створення снапшота, знайти потрібні дані та відновити файли, видалені пізніше. Важливо зберігати всі пов’язані образи та снапшоти разом, не змінювати їхні назви й відновлювати дані лише на інший фізичний накопичувач.
