Как восстановить базу данных MySQL после удаления файлов или раздела в Ubuntu: RAID 6 и LUKS2
-
Автор:
Dmytriy Zhura
-
Редактор:
Andrey Mareev
Удаление файлов или всего раздела диска в 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 | Аппаратный 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 version 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 с помощью функции Сохранить диск и сохранить на другом исправном накопителе.
Это особенно полезно, если диск нестабилен, имеет bad sectors или выдает ошибки чтения. Создание образа сохраняет читаемые данные и позволяет позже сканировать копию, уменьшая количество повторных обращений к проблемному диску.
Если диски остаются на Linux-сервере и доступны для чтения, их можно анализировать удаленно. Для этого подключитесь к серверу по SSH в Hetman RAID Recovery и получите доступ к его блочным устройствам.
Как восстановить удаленную базу данных MySQL из RAID 6 + LUKS2
ШАГ 1. Автоматическое определение RAID 6 и разделов LUKS
Сразу после запуска Hetman RAID Recovery автоматически определила конфигурацию MD RAID 6 и восстановила ее структуру для анализа.
В правой панели отображаются основные параметры массива: тип и состояние RAID, порядок и размер блоков, а также список участвующих дисков с их порядком, смещениями и размерами.
На собранном массиве программа обнаружила три раздела, включая ранее удаленный второй, и определила шифрование LUKS на всех трех. До ввода пароля их файловые системы не отображаются — для дальнейшего анализа разделы необходимо разблокировать.
Второй раздел отображается в интерфейсе как нераспределенное пространство с пометкой LUKS. Это означает, что программа распознала метаданные зашифрованного контейнера в месте удаленного раздела.
ШАГ 2. Разблокировка и восстановление удаленных файлов
Чтобы начать анализ, дважды щелкните по нужному разделу. Поскольку он зашифрован с помощью LUKS2, программа предложит ввести пароль или указать файл ключа. Введите пароль и нажмите Разблокировать.
Сначала выберите Быстрое сканирование. Дождитесь завершения сканирования, после чего программа откроет структуру найденных каталогов. В нашем тесте быстрое сканирование нашло нужные файлы на удаленном разделе.
Если в вашем случае нужные данные не будут найдены, вернитесь к выбору типа анализа и запустите Полный анализ, указав файловую систему EXT2/3/4.
Просмотрите результаты сканирования. В нашем случае программа отобразила SQL-дамп backup1.sql, каталог company_db и файлы таблиц MySQL с расширением .ibd. Содержимое SQL-дампа можно проверить в окне предпросмотра.
Выберите файлы и папки, которые нужно восстановить, затем нажмите Восстановить. Выберите способ сохранения, укажите другой физический диск и оставьте включенной опцию сохранения структуры каталогов.
Не сохраняйте найденные файлы на тот же диск, с которого они восстанавливаются, чтобы не перезаписать другие утраченные данные.
ШАГ 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, механизм хранения, сопоставление и параметры tablespace. Они также содержат определения столбцов. Информация о первичных и уникальных ключах, вторичных индексах и связях с другими таблицами хранится отдельно.
Полученный JSON можно анализировать вручную в текстовом редакторе. На основе обнаруженных параметров специальные скрипты и конвертеры могут автоматически формировать предварительные команды CREATE TABLE. Для большого количества таблиц это значительно ускоряет восстановление структуры.
ШАГ 6. Подключение восстановленных файлов ibd
В Workbench временно отключите проверки внешних ключей и выполните команду ALTER TABLE … DISCARD TABLESPACE для каждой созданной таблицы. Это отсоединит созданное пустое tablespace и подготовит таблицу к подключению восстановленного файла.
После этого скопируйте соответствующие файлы .ibd в каталог базы данных на подготовленном сервере. После копирования не забудьте назначить файлам владельца mysql и установить необходимые права доступа.
Вернитесь в Workbench и выполните ALTER TABLE … IMPORT TABLESPACE для каждой таблицы. Предупреждения об отсутствии файлов .cfg не критичны: MySQL продолжит импорт без автоматической проверки структуры. MySQL зарегистрирует восстановленные tablespace и подключит данные и индексы к ранее созданным определениям таблиц.
После успешного импорта снова включите проверки внешних ключей. Обновите список схем и проверьте количество и содержимое записей с помощью запросов SELECT.
Файлы .ibd позволяют восстановить таблицы, их данные и индексы. Однако представления, процедуры и функции не хранятся как отдельные файлы в каталоге company_db. Если они не включены в SQL-дамп, эти объекты необходимо воссоздать вручную.
После проверки восстановленной базы данных рекомендуется создать новую резервную копию в формате SQL dump.
Вывод
С помощью Hetman RAID Recovery удалось автоматически восстановить структуру Linux MD RAID 6 и обнаружить, а также разблокировать контейнеры LUKS2 с использованием известного пароля. Быстрое сканирование позволило найти нужные файлы как после их удаления, так и после удаления всего раздела.
Восстановленный SQL-дамп можно импортировать через MySQL Workbench, восстановив структуру базы данных и данные до состояния на момент создания резервной копии. Если подходящий дамп отсутствует, отдельные таблицы InnoDB можно восстановить из файлов .ibd после предварительного воссоздания их структуры.
