Як відновити базу MySQL після видалення файлів або розділу в Ubuntu: RAID 6 і LUKS2
-
Автор:
Valery Martyshko
-
Редактор:
Vladyslav Kupriyenko
Видалення файлів або цілого розділу диска в Ubuntu може призвести до критичної втрати даних, особливо якщо на сервері працює база даних MySQL. Ситуація стає значно складнішою, коли система зберігання побудована на масиві RAID 6, а дані додатково захищені шифруванням LUKS2. У таких умовах стандартні інструменти відновлення не завжди дають очікуваний результат, а необережні дії можуть остаточно знищити інформацію. У цій статті розглянемо можливі сценарії втрати даних, особливості роботи з RAID 6 і LUKS2, а також процес відновлення бази MySQL після випадкового видалення файлів або розділу диска.
- Підготовка тестового середовища та бази MySQL
- Підключення дисків для аналізу
- Як відновити видалену базу MySQL із RAID 6 + LUKS2
- КРОК 1. Автоматичне визначення RAID 6 і розділів LUKS
- КРОК 2. Розблокування та відновлення видалених файлів
- КРОК 3. Відновлення бази з SQL-дампа
- КРОК 4. Відновлення бази з фізичних файлів MySQL
- КРОК 5. Відновлення структури таблиць з ibd файла
- КРОК 6. Підключення відновлених ibd-файлів
- Висновок
- Поширені запитання
- Коментарі
Файли бази даних MySQL та її резервні копії на Linux-сервері можуть стати недоступними з різних причин: випадкове видалення файлів, форматування або видалення розділу, пошкодження файлової системи, збій RAID-масиву, відмова дисків чи RAID-контролера. Ситуація додатково ускладнюється, якщо дані зберігаються на зашифрованому LUKS2-розділі.
Hetman RAID Recovery допомагає відтворити структуру RAID-масивів, знайти втрачені розділи, розблокувати LUKS2 за наявності пароля та відновити файли бази даних і SQL-дампи.
Роботу програми продемонструємо на комп’ютері з Windows. При цьому Hetman RAID Recovery також доступна для Linux і macOS.
Як відновити видалену базу MySQL із RAID 6 + LUKS2 (Ubuntu)
Підготовка тестового середовища та бази MySQL
Для тестування ми використали сервер Dell PowerEdge R710 із контролером PERC H700.
| Параметр | Характеристика |
|---|---|
| Модель сервера | Dell PowerEdge R710 |
| Формфактор | Rack 2U |
| Процесор | До 2 × Intel Xeon серій 5500/5600 |
| Оперативна пам’ять | DDR3 ECC, до 288 ГБ (18 слотів) |
| RAID-контролер | Dell PERC H700 |
| Тип RAID | Апаратний (Hardware RAID) |
| Підтримувані RAID-рівні | RAID 0, 1, 5, 6, 10, 50, 60 |
| Конфігурація масиву | RAID 6 |
| Інтерфейс накопичувачів | SAS/SATA, до 6 Гбіт/с |
| Кількість дискових відсіків | До 6 × 3,5″ або 8 × 2,5″ залежно від конфігурації |
| Кеш RAID-контролера | 512 МБ або 1 ГБ (залежно від модифікації) |
| Захист кешу | BBU — резервне живлення кешу від батареї |
| Операційна система | Ubuntu Server |
| Шифрування даних | LUKS2 (на рівні Linux, не RAID-контролера) |
| Система керування базами даних | MySQL |
| Відмовостійкість RAID 6 | Допускає одночасну відмову до двох дисків |
| Інструменти діагностики | Dell OpenManage, MegaCLI, StorCLI (за сумісності) |
Щоб надати операційній системі прямий доступ до кожного фізичного диска, на контролері створили шість однодискових масивів RAID 0 — по одному для кожного диска. На одному встановили Ubuntu Server 24.04, а чотири інші об’єднали в програмний масив MD RAID 6 через Cockpit.
На масиві створили таблицю розділів GPT і три розділи, для кожного вибравши файлову систему ext4 та шифрування LUKS2.
На третьому розділі розмістили каталог mysql-data з даними тестової бази company_db, системними файлами та журналами MySQL. Використали MySQL версії 8.0.46.
Сама база містила таблиці customers, products і orders, а також представлення, збережену процедуру та функцію.
Резервну копію бази створили в MySQL Workbench у форматі SQL-дампа та зберегли в каталозі mysql-backups.
Перед тестуванням каталоги mysql-data і mysql-backups скопіювали з третього розділу на другий. Потім другий розділ видалили через Cockpit, а з третього видалили файли бази даних і SQL-дамп за допомогою Shift + Delete, оминаючи кошик. Так підготували два сценарії: відновлення файлів із видаленого розділу та відновлення видалених файлів зі збереженого розділу.
Підключення дисків для аналізу
У нашому випадку диски-учасники RAID 6 підключили до комп’ютера з Windows через USB-док-станцію та запустили Hetman RAID Recovery для аналізу.
Окрім роботи з фізичними дисками, програма підтримує аналіз їхніх повних побайтових образів. Створити такі образи можна безпосередньо в Hetman RAID Recovery за допомогою функції Save Disk, зберігши їх на іншому справному накопичувачі.
Це особливо корисно, якщо диск працює нестабільно, має пошкоджені сектори або помилки читання. Створення образу дозволяє зберегти доступні для зчитування дані та надалі сканувати копію, зменшуючи кількість повторних звернень до проблемного диска.
Якщо диски залишаються на Linux-сервері й доступні для читання, їх можна аналізувати віддалено. Для цього підключіться до сервера через SSH у Hetman RAID Recovery та отримайте доступ до його блокових пристроїв.
Як відновити видалену базу MySQL із RAID 6 + LUKS2
КРОК 1. Автоматичне визначення RAID 6 і розділів LUKS
Відразу після запуску Hetman RAID Recovery автоматично визначила конфігурацію MD RAID 6 і відтворила його структуру для аналізу.
У правій панелі відображаються основні параметри масиву: тип і стан RAID, порядок і розмір блоків, а також список дисків-учасників із зазначенням їхньої послідовності, зміщень і розмірів.
На зібраному масиві програма виявила три розділи, зокрема раніше видалений другий, і розпізнала шифрування LUKS на всіх трьох. До введення пароля їхні файлові системи не відображаються — для подальшого аналізу потрібно розблокувати розділи.
Другий розділ показано в інтерфейсі як нерозподілений простір із позначкою LUKS. Це означає, що програма розпізнала службові дані зашифрованого контейнера на місці видаленого розділу.
КРОК 2. Розблокування та відновлення видалених файлів
Щоб запустити аналіз, двічі клацніть потрібний розділ. Оскільки він зашифрований за допомогою LUKS2, програма запропонує ввести пароль або вказати файл ключа. Введіть пароль і натисніть Unlock.
Спочатку виберіть Fast Scan. Дочекайтеся завершення сканування, після чого програма відкриє структуру знайдених каталогів. У нашому тесті швидке сканування знайшло потрібні файли на видаленому розділі.
Якщо у вашому випадку потрібні дані не знайдено, поверніться до вибору типу аналізу та запустіть Full Analysis, указавши файлову систему EXT2/3/4.
Перегляньте результати сканування. У нашому випадку програма відобразила SQL-дамп backup1.sql, каталог company_db і файли таблиць MySQL із розширенням .ibd. Вміст SQL-дампа можна перевірити у вікні попереднього перегляду.
Позначте файли та папки, які потрібно відновити, і натисніть Recovery. Виберіть спосіб збереження, вкажіть інший фізичний диск і залиште активною опцію відновлення структури каталогів.
Не зберігайте знайдені файли на носій, з якого вони відновлюються, щоб не перезаписати інші втрачені дані.
КРОК 3. Відновлення бази з SQL-дампа
Найпростіший спосіб повернути базу — це використати відновлений SQL-дамп. Він містить команди для створення структури бази та відновлення даних станом на момент створення копії. Якщо під час експорту були вибрані відповідні параметри, дамп також міститиме представлення, процедури та функції.
Запустіть MySQL Workbench і підключіться до сервера MySQL. Відкрийте меню Server — Data Import, виберіть Import from Self-Contained File та вкажіть відновлений SQL-файл.
Якщо втрачено весь каталог mysql-data із системними файлами MySQL, то спочатку потрібно відновити працездатність сервера або підготувати новий екземпляр MySQL. Лише після цього можна імпортувати дамп через Workbench.
Виберіть цільову схему або створіть нову базу company_db, після чого натисніть Start Import. Дочекайтеся завершення операції та перевірте журнал на наявність помилок.
Оновіть список схем. У базі мають з’явитися таблиці customers, products і orders. Відкрийте їх та перевірте записи.
КРОК 4. Відновлення бази з фізичних файлів MySQL
Якщо придатного SQL-дампа немає, але Hetman RAID Recovery вдалося повернути каталог бази з файлами таблиць, то можна спробувати фізичне відновлення.
У нашому випадку в каталозі company_db збереглися файли customers.ibd, products.ibd та orders.ibd. Кожен із них містить дані й індекси відповідної InnoDB-таблиці.
Простого копіювання цих файлів до каталогу MySQL недостатньо. Новий сервер ще не має описів відповідних таблиць у словнику даних. Тому відновлення складається з двох етапів: спочатку потрібно відтворити структуру таблиць, а потім підключити до них знайдені файли .ibd.
Для відновлення підготуйте працездатний сервер із тією самою версією MySQL. Підключіться до нього через Workbench і створіть порожню базу.
Якщо зберігся початковий SQL-скрипт зі структурою, виконайте з нього команди CREATE TABLE. Таблиці мають точно відповідати початковим, включно з типами стовпців, ключами, індексами, кодуванням і форматом рядків. Команди додавання даних виконувати не потрібно — на цьому етапі таблиці мають залишатися порожніми.
КРОК 5. Відновлення структури таблиць з ibd файла
Якщо початкового SQL-скрипту немає, то структуру таблиць можна спробувати відновити з файлів .ibd. У MySQL 8.0 вони містять SDI — службові метадані словника даних. Для їхнього читання використовується утиліта ibd2sdi.
Запустіть її для кожного відновленого файла та збережіть результати у форматі JSON. У нашому випадку ми отримали метадані з customers.ibd, products.ibd та orders.ibd, а потім за допомогою jq переглянули опис таблиці customers.
У метаданих можна знайти назву таблиці, версію MySQL, тип сховища, кодування, зіставлення та параметри табличного простору. Вони також містять опис стовпців. Окремо зберігається інформація про первинні й унікальні ключі, звичайні індекси та зв’язки з іншими таблицями.
Отриманий JSON можна проаналізувати вручну в текстовому редакторі. На основі знайдених параметрів спеціальні скрипти й конвертери можуть автоматично сформувати попередні команди CREATE TABLE. Для великої кількості таблиць це значно пришвидшує відновлення структури.
КРОК 6. Підключення відновлених ibd-файлів
У Workbench тимчасово вимкніть перевірку зовнішніх ключів і для кожної створеної таблиці виконайте команду ALTER TABLE … DISCARD TABLESPACE. Вона від’єднає створений порожній табличний простір і підготує таблицю до підключення відновленого файла.
Після цього скопіюйте відповідні .ibd-файли до каталогу бази на підготовленому сервері. Після копіювання не забудьте призначити файлам власника mysql і встановити необхідні права доступу.
Поверніться до Workbench та виконайте ALTER TABLE … IMPORT TABLESPACE для кожної таблиці. Попередження про відсутність .cfg не є критичними: MySQL продовжить імпорт без автоматичної перевірки структури. MySQL зареєструє відновлені табличні простори й підключить дані та індекси до створених раніше описів таблиць.
Після успішного імпорту знову ввімкніть перевірку зовнішніх ключів. Оновіть список схем і перевірте кількість та вміст записів за допомогою запитів SELECT.
Файли .ibd дозволяють повернути таблиці, їхні дані та індекси. Проте представлення, процедури й функції не зберігаються окремими файлами в каталозі company_db. Якщо їх немає в SQL-дампі, ці об’єкти доведеться створити повторно.
Після перевірки відновленої бази рекомендуємо створити нову резервну копію у форматі SQL-дампа.
Висновок
За допомогою Hetman RAID Recovery вдалося автоматично відтворити структуру Linux MD RAID 6, розпізнати й розблокувати контейнери LUKS2 за відомим паролем. Швидке сканування знайшло потрібні файли як після їх видалення, так і після видалення цілого розділу.
Відновлений SQL-дамп можна імпортувати через MySQL Workbench, повернувши структуру й дані бази станом на момент створення резервної копії. Якщо придатного дампа немає, окремі InnoDB-таблиці можна спробувати відновити з файлів .ibd, попередньо відтворивши їхню структуру.
