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

И вот этот день настал. На разделе поверх софтового raid0, хранившем, откровенно говоря, всякую ерунду, файлы оказались недоступны, а причина — долгожданный I/O Error. Неожиданным было то, что устройства-носителя второй половинки рэйда вообще не оказалось в выводе fdisk, хотя список файлов был доступен. Перезагрузка — и массив собрался, а файлы прекрасно читаются. В отчете SMART видно огромное количество переназначенных секторов. Как раз то, что нужно. Отключаю диски и начинаю продумывать стратегию восстановления.

Для вычитывания уцелевших секторов решено было использовать GNU ddrescue — специализированную версию dd для чтения данных с умирающих дисков, которая позволяет выбирать стратегию чтения и умеет строить карту диска для продолжения работы после сбоев, а они обязательно будут, работаю ведь с неисправными устройством.

Итак, подключаю первый диск к своему десктопу, и POST торжественно сообщает, что один из подключенных дисков совсем плох. Загрузка ОС прошла штатно, если не считать пару сообщений о каких-то ошибках ata устройства. После успешной загрузки fdisk -l пациента видит, ну наконец-то я буду восстанавливать целостность данных raid0.

ddrescue -ndAvv /dev/sdd1 bad mapbad

Процесс пошел довольно резво, 80 МБ/с. Из-за шума охлаждающего диски вентилятора, изъятого специально по такому случаю из списанного сервера, леденящих кровь звуков чтения умирающего диска было бы не слышно, даже если бы они были. Возможно, не слышать их даже лучше. Меньше знаешь — крепче спишь.

К утру работа ddrescue завершилась, и на новеньком диске лежали образ и карта погибающего товарища. Но повторный запуск ddrescue почему-то завершался подозрительно быстро, а карта


«Что-то очевидно пошло не так», — подсказал сонный внутренний голос. «А попробуй-ка fdisk -l» — вот, и разум уже подключился. /dev/sdd в выводе не оказалось. — Как такое вообще возможно?, — Ах да, на сервере было тоже самое, — Значит, не все еще пропало: примерно такие мысли обитали в голове весь рабочий день.

Вечером подопытный диск опять подавал признаки жизни, а передо мной стояла непростая задача: что делать с полученным образом, ведь ddrescue c финализированной картой что-либо читать отказывался, оставив мне файл образа меньше размера раздела.
С одной стороны, ddrescue умеет заполнять - блоки произвольными данными, чтобы потом определить битые файлы. С другой стороны, я не просил его делать спарс-файл (параметр -S), и усиленное гугление вопроса о том, как именно будет заполняться меньший-чем-раздел файл образа, осталось без ответа.


Полагаться на случай крайне не хотелось, и я решил с калькулятором в руках изучить карту диска. Оказалось, что 96% содержимого диска успешно прочиталось и попало в первый + блок. Но к сожалению, сумма всех + блоков не давала размер считанного образа, что окончательно спутало мне все карты. По-этому я пошел другим путем: раз у меня есть хорошее начало и черт знает что в конце, почему бы не достать старый добрый dd и не слепить из непонятного образа как раз то, с чем можно спокойно работать?

dd if=bad of=bad_new bs=16M count=42751
dd if=/dev/zero of=bad_new bs=1024 seek=700432384 count=32139617

Результат — новенький образ, который теперь в точности такого же размера, как и умирающий раздел, а именно 750153729024 байт. Теперь займемся ноликами в конце. Делаю вручную


и запускаю:

ddrescue -ndAvv /dev/sdd1 bad_new mapbad

Ура! Теперь все хорошо. Читающиеся блоки с диска переехали на пустое место нового образа по нужным адресам, а карта опять финализировалась, и мои приключения подходят к концу. Но может быть сделать последний рывок и перечитать - блоки по одному сектору? Теперь даю ddrescue


и запускаю так:

ddrescue -ndAvv /dev/sdd1 -с1 bad_new mapbad

В общем, он повел себя совсем не так, как я рассчитывал. Наткнувшись на плохой сектор в - блоке, он переходил к следующему - блоку, пока не зацепился за уверенное чтение из последнего - блока. Час спустя я остановил это безобразие с помощью CTRL-C и запустил чтение на нормальной скорости. Еще несколько гигабайт из конца раздела прочитались, пока ddrescue снова не напоролся на сбойные сектора, что почему-то опять привело к пропаданию /dev/sdd из системы и финализации карты, которая сильно распухла и представляла собой месиво из +, - и ? блоков. Разбирать все это не было уже никакого смысла, и я решил прекратить мучить умирающего и заняться, наконец, сборкой массива. Но перед этим захотелось выяснить, что было бы, если бы я использовал режим заполнения. Готовлю заполнитель и включаю режим заполнения, не забыв заменить карту на первоначальную:

printf "BADSECTOR" > tmpfile
ddrescue --fill-mode=- tmpfile bad mapbad

И получаю еще один образ правильного размера! Как он это сделал для меня осталось загадкой, ведь я несколько раз пересчитал сумму размеров + блоков из карты, и она не совпадала с размером готового файла.

И вот на месте отдающего магнитную душу богу уже его здоровый собрат, а я выполняю команды:

losetup /dev/loop1 bad_new 
mdadm --assemble -o /dev/md12 /dev/loop1 /dev/sdd1

Но результат, мягко говоря, не тот, что я ожидал после 24 часов надежды на успех:

mdadm: no RAID superblock on /dev/loop1
mdadm: /dev/loop1 has no superblock - assembly aborted

Что делать, попробуем теперь пообщаться с гуглом и разделами:

#mdadm --examine /dev/loop1
mdadm: No md superblock detected on /dev/loop1.

— То есть как это no md superblock detected?
— А у этого, который пока здоров?

#mdadm --examine /dev/sdd1
/dev/sdd1:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 64d38efd:b8e92c8c:f5292846:21864477
  Creation Time : Fri Oct 10 20:22:23 2008
     Raid Level : raid0
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 2

    Update Time : Fri Oct 10 20:22:23 2008
          State : active
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0
       Checksum : 6f768a67 - correct
         Events : 1

     Chunk Size : 4K

— Версия 0.90.00? А где должен быть суперблок у mdadm 0.90.00?
— В конце раздела.
— А как его прочитать с помощью mdadm?
— Никак.
— То есть как это никак? Ну ладно, так где там он поточнее?
— Не дальше 128K но не ближе 64К от конца раздела, выровнен по границе 64К, размер 4К.

Н-да, беру dd и проверяю:

dd if=/dev/sdd1 of=last128 bs=1024 skip=732571873 count=128
dd if=last128 of=bad_new bs=1024 seek=732571873 count=128

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

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

#dd if=/dev/sdd1 of=last128 bs=1024 skip=732571873 count=128
dd: reading `/dev/sdd1': Input/output error
0+0 records in
0+0 records out

«Да, такого удара Великий комбинатор не испытывал никогда», — почему-то в памяти всплыла именно эта бессмертная цитата.
Ну ладно, так легко мы не сдаемся. А мы вот так:

dd if=/dev/sdd1 of=last128 bs=1024 skip=732571873 count=128 conv=noerror

Эх, размер last128 >0 но <128К. И где там что? Как с этим работать? А как сделать нолики-то вместо убитых секторов? А вот так:

dd if=/dev/sdd1 of=last128 bs=1024 skip=732571873 count=128 conv=noerror,sync

Вот они, последние 128К. Прописываю их в конец образа, перезагружаюсь со здоровым диском, и массив собрался!
Осталась простая команда и:

#mount -o ro /dev/md11 /srv/old/
mount: wrong fs type, bad option, bad superblock on /dev/md11,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

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

dd if=/dev/md11 of=ext3 bs=16M conv=noerror,sync

И спать, а наутро пробую:

losetup /dev/loop2 ext3 
mount -o ro /dev/loop2 /srv/old/

И оно монтируется! Структура каталогов на первый взгляд не изменилась, а файлы, от которых у меня есть хэши, прочитались без ошибок. На восстановленном разделе свободно всего 20 ГБ, поэтому его loop-файл получил заслуженный атрибут:

chattr +i ext3

и запись в fstab:

/srv/ext3	/srv/old	ext3		ro,loop	0	0

В качестве заключения дочитавшему до сюда рекомендую:

• настроить автоматическое резервное копирование важных и не очень данных,
• периодически просматривать отчеты SMART,
• использовать для восстановления устройство USB to SATA, или аналогичное для вашего диска,
• относиться к любому диску, с которого нужно снять образ, как к умирающему и использовать GNU ddrescue,
• помнить, что если дело дойдет до восстановления действительно важных данных, то такого везения точно не будет.