Как мы восстанавливали данные с Synology DS418

Диагностика и восстановление DS 418

Любое восстановление данных с raid массива начинатся с определения его уровня и параметров: порядок дисков, размер блока данных, распределения контрольных сумм, если речь о raid 5 или 6, и порядка чтения дисков. Большиство параметров можно определить в Raid Reconstruction, но в этом случае мы решили работать в Data Extractor PC3000 RAID Editions.

Такое решение было принято потому, что из-за многократных попыток установить DSM начало дисков перезаписалось и начальный сектор (смещение от начала диска) для сборки массива оказался потерян. И нужно было как-то решить эту головоломку.

В инструментах РС3000 RAID Editions есть класный инструмент определения параментров массива на основе пользовательских данных. Точнее сказать, на основе структур файлов, которые пользователи часто хранят на массиве и диске. К ним можно отнести офисные документы *.docx и *.xlsx или архивы *.zip. Эти файлы имеет четкую внутреннюю структуру и, именно, на этой особенности файлов нам удалось установить, что массив следует собирать с 224 сектора, как и все остальные параметры рейд массива.

Информации о том, как было все организовано на рейд массиве мы от заказчика узнать не смогли, потому что он достался в наследство и все работало пока не сломалось. Придется побыть «Шерлоком».

Так как начало каждого из 4 дисков перезаписано примерно на 10 гб, а это, на минуточку, примерно 20 млн секторов, то мы запустили сканирование на поиск наиболее вероятных файловых структур — ext или btrfs. Неполное сканирование нашло файловую систему btrfs на весь рейд массив, на котором был организован LUN на 16 Тб, внутри которого файловая система NTFS. Но она оказалась сильно повреждена, а именно, перезаписана вся файловая таблица MFT. При такой ситуации возможно восстановление данных по типам файлов.

Из ТЗ мы знаем, что нужно восстановить виртуальные машины и, если повезет и виртуалки окажутся несжатыми и не фрагментированными, то шанс восстановить данные все еще остается. Запустили скан на поиск файловых систем NTFS, ReFS, exFAT, FAT32, ext2/3/4, BTRFS уже внутри LUNа.

В результате сканирования нашлись две виртуальные машины с файловой системой ReFS на 4 Тб и 4.5 Тб. Но данные в них оказались поврежденными и начало второй виртуалки лежало внутри «тела» первой. А это явный признак того, что файлы виртуальных машин фрагментированы. «Покопавшись» вокруг MBR обоих виртуальных машин на собранном массиве, мы нашли еще одну занозу — виртуальный диск создавался в формате VHDX, а это накладывает дополнительную трансляцию между содержимым виртуалки и массивом, на котором она лежит.

На этом «матрешка» упаковки данных еще не закончилась. Анализ содержимого виртуалок поставлил жирную точку в шансах восстановить данные. Выяснилось, что внутри конечных виртуалок лежат файлы бэкапов Veeam Backup, для архивации данных которых в большистве случаев используется алгоритм сжатия LZ4.

Схематично всю вложенность до данных, к которым нам предстояло добраться, можно представить так: