Восстановление таблицы разделов в Linux

В моем домашнем NAS внезапно отказал один из дисков. Это был единственный диск не в raid, данные на котором вроде как не важные (торренты, софт и т.д., все, что можно заново выкачать из инетрнета), поэтому диск не дублировался. Ничего критичного не произошло, но мне все равно стало жалко данные, поэтому я заменил диск, а этот отложил в сторонку, чтобы попытаться восстановить информацию. У меня это получилось, поэтому решил задокументировать результат, чтобы самому не забыть и с вами поделиться.

Введение

Симптомы поломки были следующие. Заметил, что пропал сетевой диск. Зашел на сервер и увидел, что диск не инициализирован. Таблица разделов пустая. При этом, диск работал нормально и SMART ошибок не показывал. Я сразу заподозрил, что проблема именно с таблицей разделов. Данные должны быть на месте.

Дополнительная важная информация - диск был в составе mdadm массива, состоящим из одного диска. LVM не использовался.

Я подключил сбойный диск в обычный системник. Сделал загрузочную флешку с Ubuntu Live CD и загрузился с нее. Настроил там сеть, стандартные репозитории.

Восстановление таблицы разделов

Я давно знаю утилиту testdisk. С ее помощью мне уже удавалось восстанавливать данные в linux. Она есть в репозиториях ubuntu, так что я ее установил. Далее все было просто. К сожалению, скриншотов нет, так как делал все на отдельном системнике. Расскажу на словах, что сделал:

1. Запустил утилиту. Она вывела список всех подключенных дисков. В моем случае диск был /dev/sda.
2. Выбрал нужный диск, указал в выборе partition table types первый вариант - Intel.
3. Запустил сканирование. Утилита нашла разделы, которые там были ранее. Я прикинул, вроде бы то, что и должно быть.
4. Записал таблицу разделов на диск.

Далее через fdisk я увидел разделы диска sda, в том числе тот, что меня интересовал - Linux raid autodetect.

Если восстанавливаете таблицу разделов обычного диска, то уже сейчас можно было бы смонтировать найденный раздел и попытаться прочитать данные. В моем же случае, нужно было собрать mdadm массив и подмонтировать уже его. Вот тут и начались самые сложности, с которыми больше всего провозился.

Восстановление mdadm массива

Установил в live систему mdadm:

# apt install mdadm

Первым делом проверил суперблоки на восстановленном разделе:

# mdadm --misc --examine /dev/sda2

На вид все было в порядке. Дальше рассчитывал сразу найти массив и примонтировать его.

# mdadm --assemble --scan
mdadm: failed to add /dev/sda2 to /dev/md3: Invalid argument
mdadm: failed to RUN_ARRAY /dev/md3: Invalid argument

Тут я приуныл, потому что не мог понять, в чем проблема. Пробовал разные команды для запуска массива, но он упорно не стартовал. При этом на вид все было в порядке. Потом в какой-то момент я додумался посмотреть dmesg.

# dmesg | grep sda2
md: sda2 does not have a valid v1.2 superblock, not importing!

Решение этой ошибки достаточно быстро нагуглилось.

# mdadm --assemble --verbose /dev/md2 /dev/sda2 --update=devicesize

После этого массив нормально стартовал и cat /proc/mdstat показывал его состояние. Тут я думал, что мои мучения окончены и я сейчас получу свои данные. Но это тоже было еще не все.

Восстановление таблицы разделов на mdadm

Просто подмонтировать запущенный mdadm массив к системе не получилось.

# mount -t ext4 /dev/md2 /mnt
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/md2, missing codepage or helper program, or other error.

Я так понял, что тут либо таблица разделов так же была уничтожена, либо файловая система. Я не знал, как был разбит на разделы сам массив, поэтому просто решил еще раз прогнать анализ таблицы разделов уже массива md2 через утилиту testdisk.

К счастью, она нашла единственный раздел на диске и восстановила его. Таким образом у меня получилось устройство /dev/md2p1. Дальше я успешно смонтировал этот раздел в /mnt и получил доступ к данным. Они все были на месте.

В заключении я к этой же системе подмонтировал сетевой диск через cifs и начал копировать данные.

# mount -t cifs //192.168.15.50/data /mnt/data -o user=admin,password=adminpass

Заключение

В итоге у меня все получилось, но считаю, что просто повезло, так как любое неверное действие в восстановлении таблицы разделов могло привести к фатальным последствиям. Если вы будете восстанавливать реально важные данные, то обязательно сделайте посекторную копию носителя и работайте с ней. И внимательно смотрите на восстановленные разделы перед их записью. Если что-то пойдет не так, то восстановить данные будет в разы сложнее. Наверняка таблицу разделов придется править уже вручную, а для этого нужны хорошие знания. У меня, к примеру, их нет.

Непонятной осталась причина сбоя, и это хуже всего. На вид все в порядке, но я теряю доступ к данным. Любой другой пользователь, не разбирающийся в linux, просто потерял бы данные, либо пришлось обращаться в специализированные фирмы по восстановлению информации, а это стоит дорого. И еще, как я понял, я точно так же мог потерять доступ и к массиву из нескольких дисков. К слову, потерпевший NAS это Synology, где под капотом обычный linux и mdadm, поэтому я понимал, как надо действовать. На этом же устройстве есть несколько массивов на много Tb и если бы кто-то из них сглючил, то было бы плохо.

Несколько моих статей по восстановлению загрузки linux после различных сбоев:

• Kernel panic not syncing: VFS: Unable to mount root fs
• Booting from Hard Disk error, Entering rescue mode
• Восстановление raid1
• Восстановление загрузки linux сервера
• Восстановление загрузки после переноса виртуальной машины

Надеюсь, вам они не пригодятся.