Как восстановить данные с Synology NAS после сбоя во время миграции с RAID 1 на RAID 5?
Представьте, что вы добавляете диск в Synology NAS и начинаете миграцию с RAID 1 на RAID 5, чтобы увеличить емкость хранилища. Но во время перестроения внезапно пропадает питание, и NAS выключается. После восстановления питания оказывается, что один из исходных дисков больше не определяется, и доступ к файлам отсутствует. Что делать, если актуальной резервной копии необходимых данных нет? Можно ли восстановить файлы с двух оставшихся дисков, если миграция на новый уровень RAID так и не была завершена?

- ШАГ 1. Тестовая среда
- ШАГ 2. Подключение дисков к компьютеру с Windows
- ШАГ 3. Результаты анализа RAID 5
- ШАГ 4. Ручная реконструкция RAID
- ШАГ 5. Определение смещения начала данных
- ШАГ 6. Автоматическое определение параметров RAID
- ШАГ 7. Поиск данных в исходной конфигурации RAID 1
- Вывод
- Часто задаваемые вопросы
- Комментарии
Миграция массива на Synology NAS с RAID 1 на RAID 5 обычно завершается без потери данных. Однако сбой питания, ошибки диска или прерывание процесса могут привести к деградации хранилища или полной недоступности данных. В такой ситуации главное — избегать поспешных действий, которые могут усложнить восстановление. В этой статье мы рассмотрим, как правильно оценить состояние RAID-массива Synology после аварийной миграции и какие методы могут помочь восстановить доступ к данным.
Восстановление данных Synology NAS после сбоя миграции RAID 1 → RAID 5
ШАГ 1. Тестовая среда
Для теста мы использовали сетевое хранилище Synology DS409 под управлением DSM 4.2 и три жестких диска емкостью по 320 гигабайт каждый.
Изначально два диска были объединены в RAID 1 — зеркальный массив, в котором данные дублировались на обоих дисках. На нем был создан том с файловой системой Ext4, и на него было записано примерно 110 гигабайт тестовых данных: документы, фотографии, видео и архивы. Файлы были размещены в каталогах с несколькими уровнями вложенности, чтобы затем можно было проверить сохранность как содержимого, так и структуры папок.

Затем к массиву был добавлен третий диск, и с помощью Storage Manager был запущен процесс изменения уровня RAID с RAID 1 на RAID 5.
Эта миграция позволяет увеличить доступную емкость хранилища, сохраняя защиту от отказа одного диска после успешного завершения операции.

Когда индикатор перестроения показал 29,55 процента, питание NAS было намеренно отключено без корректного завершения работы. После этого один из двух исходных дисков RAID 1 был извлечен, что имитировало полную недоступность.

В результате для восстановления остались доступны два диска: один диск из исходного зеркала и третий диск, добавленный для перехода на RAID 5. Перестроение не было завершено, поэтому часть данных уже была перенесена, а остальная часть по-прежнему хранилась по прежней схеме. Эти два диска будут использоваться на следующих этапах.

ШАГ 2. Подключение дисков к компьютеру с Windows
Переходим к компьютеру с Windows, на котором установлена программа Hetman RAID Recovery.
Подключаем два оставшихся диска через USB-док-станцию:
- один из исходных дисков RAID 1;
- диск, добавленный для перехода на RAID 5.
Второй участник исходного зеркала в нашем тесте недоступен.
Запускаем программу. В разделе RAID Arrays видим автоматически обнаруженный массив DiskStation:2.

Выбираем его и просматриваем сведения на панели Preview справа. Программа определила тип RAID 5, порядок блоков Left Synchronous и размер блока 64 килобайта.

Ниже, в списке RAID Disks, видны два подключенных диска и позиция Empty disk, соответствующая отсутствующему участнику. Для обоих доступных дисков указан одинаковый смещение начала данных — к этому параметру мы вернемся при ручной реконструкции.
В списке также отображаются два небольших массива RAID 1 размером примерно 2,37 и 2 гигабайта. Они соответствуют системным областям Synology.
Не следует путать их с исходным зеркалом, на котором находились наши тестовые файлы.

Исходный RAID 1 с пользовательскими данными отдельно больше не отображается.
ШАГ 3. Результаты анализа RAID 5
Проверим, что доступно через автоматически обнаруженную конфигурацию RAID 5. Для этого откроем том Ext4 в этом массиве двойным щелчком. В мастере анализа выберем Fast scan и нажмем Next, чтобы начать поиск файлов.

Доступная часть тестовых данных: после анализа RAID 5 программа нашла 390 папок и 8239 файлов. В результатах видны папка My Data и вложенные каталоги с тестовыми файлами. Часть исходной структуры сохранилась: программа показывает имена папок и файлов, а также их расположение.

Таким образом, даже при наличии двух доступных участников прерванного массива часть его содержимого удалось прочитать. Чтобы сохранить нужные файлы, выделите их, нажмите Recovery и укажите папку на отдельном диске, не входящем в восстанавливаемый массив, чтобы избежать перезаписи исходных данных.

Однако в результатах присутствуют не все файлы, записанные до теста. До миграции данные хранились на двух дисках как зеркальные копии. Во время перехода на RAID 5 система постепенно изменила схему размещения блоков, распределив их между тремя дисками и создав контроль четности.
В результате на оставшихся дисках сохранились области с разной организацией данных. Разметка RAID 5 соответствует размещению блоков в уже перестроенных областях, тогда как в остальной части сохраняется прежняя организация RAID 1, хотя само зеркало уже не определяется автоматически.
Поэтому отсутствие файла в этих результатах еще не означает, что его содержимое полностью утеряно.
ШАГ 4. Ручная реконструкция RAID
В нашем случае программа автоматически определила RAID 5 и его параметры. Но что делать, если конфигурацию нужно задать вручную или некоторые параметры неизвестны? Для этого в Hetman RAID Recovery предусмотрен RAID Constructor. На примере обнаруженного RAID 5 рассмотрим его возможности, а затем с помощью этого инструмента восстановим исходный RAID 1.

Открываем RAID Constructor, выбираем RAID 5 и добавляем два доступных диска. Отсутствующий участник помечается как Empty disk. Таким образом мы получаем три позиции, соответствующие составу массива на момент миграции.

В конфигурациях RAID 5, которые мы тестировали на Synology, часто встречались порядок блоков Left Synchronous и размер блока 64 килобайта, поэтому мы используем именно эту комбинацию в конструкторе. В нашем случае она также соответствует параметрам автоматически обнаруженного массива.

Однако эти значения не универсальны: для другого набора дисков или другого устройства хранения их нужно проверять отдельно с учетом конфигурации массива и истории изменений.
Отдельно необходимо указать смещение начала данных для каждого диска, поэтому сначала рассмотрим, где его найти и как вычислить.
ШАГ 5. Определение смещения начала данных
Смещение показывает, какую начальную часть диска нужно пропустить перед чтением блоков пользовательского массива. На схеме физического диска видны системные разделы Synology и раздел, в котором хранятся наши файлы. В этом тесте он начинается с сектора 9 437 184. Это наша отправная точка. Сами данные RAID начинаются немного позже, поскольку в начале раздела зарезервировано место для системной информации.

Открываем физический диск в HEX Editor. Чтобы перейти к началу нужного раздела, сначала преобразуем его начальный сектор в байтовый адрес. В калькуляторе умножаем 9 437 184 на размер сектора — 512 байт. Получаем 4 831 838 208 байт. Преобразуем результат в шестнадцатеричный формат и переходим по этому адресу в редакторе.

Из текущей позиции начинаем поиск вперед. Выбираем шестнадцатеричный поиск и вводим сигнатуру FC 4E 2B A9. Это позволяет пропустить начальные системные разделы Synology и найти суперблок EXT в разделе, где находятся наши файлы.

Нужное совпадение найдено по адресу 120001000. Рядом, в текстовой части редактора, видно имя DiskStation:2. Одна только сигнатура недостаточна, поскольку такая последовательность байтов может встречаться и в других данных.

Теперь найдем поле data_offset, которое указывает смещение начала RAID-данных внутри раздела. В этом формате суперблока оно находится на расстоянии 128 байт от начала и занимает восемь байт. В нашем случае это первые восемь байт строки по адресу 120001080.

Значение хранится в порядке little-endian. В стандартной записи это число 800 в шестнадцатеричном формате. Вводим его в калькулятор и переключаемся в десятичный формат — получаем 2048 секторов. Это расстояние от начала раздела до начала данных RAID. Следовательно, прибавляем 2048 к начальному сектору раздела. Получаем 9 439 232 сектора. Умножаем на 512 байт — итоговое смещение от начала физического диска составляет 4 832 886 784 байта. Оно совпадает со значением в свойствах автоматически обнаруженного RAID 5.

ШАГ 6. Автоматическое определение параметров RAID
Возвращаемся в RAID Constructor и указываем определенное смещение для каждого доступного диска. Теперь можно использовать автоматическое определение неизвестных параметров.

Если размер блока или порядок блоков неизвестны, в полях Block size и Block order можно выбрать Detect automatically. Для определения порядка дисков предусмотрена отдельная опция Detect the disk order automatically. Например, можно оставить RAID 5, Left Synchronous и размер блока 64 килобайта, а порядок дисков поручить программе.
После перехода к следующему шагу программа начинает поиск конфигураций, соответствующих заданным условиям. Найденные варианты отображаются в списке. Выберите нужную конфигурацию и нажмите Add.

После этого собранный RAID появится на главном экране программы, где его можно открыть для анализа и поиска файлов.

Теперь используем конструктор для другой задачи — проверим оставшийся диск исходного зеркала в конфигурации RAID 1.
ШАГ 7. Поиск данных в исходной конфигурации RAID 1
Возвращаемся в RAID Constructor и выбираем RAID 1. Добавляем оставшийся диск исходного зеркала и отмечаем отсутствующий участник как Empty disk.

Указываем проверенное смещение начала данных. Это сообщает программе, как читать данные по прежней схеме. Это виртуальная реконструкция для анализа: она не отменяет миграцию и не возвращает диски в состояние до инцидента.

Собранный RAID 1 появится на главном экране программы.

Открываем его двойным щелчком и выбираем Full analysis в мастере анализа. Указываем файловую систему Ext4 и запускаем анализ.

После завершения программа нашла 979 папок и 14 049 файлов. Для сравнения, после Fast scan конфигурации RAID 5 было получено 390 папок и 8 239 файлов. Эти числа не отражают количество уникальных корректных файлов: в результатах могут присутствовать дубликаты, которые требуют проверки.

Просматриваем найденные данные. Исходная структура каталогов была восстановлена не полностью, и часть найденных объектов находится в Lost and Found.

Восстановление дерева папок требует сохраненных структур метаданных файловой системы и связей между ними. После прерванной миграции данные отдельного файла могут читаться в выбранной конфигурации, тогда как записи, связывавшие его с исходным каталогом, могут быть недоступны. Поэтому отсутствие привычной папки не обязательно означает, что все ее содержимое утрачено.
Чтобы быстрее найти нужные файлы, используйте функцию Find File. В окне поиска введите полное имя или его часть и нажмите Find. При необходимости можно включить поиск с учетом регистра или ограничить поиск только точными совпадениями слов.

Мы просматриваем несколько файлов в разных форматах, включая найденные через поиск. В окне Preview проверяем изображения, содержимое документов и другие файлы, доступные для предварительного просмотра. Это позволяет определить нужные данные и оценить их содержимое перед сохранением.
Вывод
В этом тесте мы рассмотрели потерю диска после прерванной миграции Synology с RAID 1 на RAID 5. Hetman RAID Recovery автоматически определила RAID 5 на основе сохраненных метаданных, однако через эту конфигурацию была доступна только часть исходных данных.
Поэтому мы также проанализировали оставшийся диск исходного зеркала как RAID 1. В результатах были найдены файлы, содержимое которых можно просмотреть, хотя структура каталогов восстановлена не полностью.
Этот случай показывает, почему после незавершенной миграции важно учитывать предыдущую конфигурацию массива: текущие метаданные не всегда описывают расположение всех данных на дисках.
Актуальная резервная копия значительно упрощает восстановление после инцидента. Если ее нет, анализ сохраненных данных может помочь восстановить как минимум часть файлов — именно такой сценарий мы и рассмотрели здесь.







