Материал из Linuxformat.

Восстановление данных Спасительные советы на случаи бунта технологий

Содержание 1 Данные: если дело плохо 1.1 Основы fsck 1.2 dd 1.3 Foremost и извлечение данных 1.4 Autopsy 1.5 Альтернативы для dd_rescue 1.6 Последнее китайское предупреждение...

Данные: если дело плохо

Потеряли важную информацию? Без паники: заварите чайку, внемлите совету сисадмина-ниндзя Джульетты Кемп и верьте в успех.

К сожалению, у файловых систем или жестких дисков имеется множество вариантов выхода из строя: в одних случаях данные восстановить легче, в других – сложнее. Вот несколько методов, способных помочь вам избежать либо потери всех данных на диске, либо огромных денежных расходов на их профессиональное восстановление.

Но сначала – очень важное замечание: если у вас неполадки в оборудовании или в файловой системе, немедля выключите компьютер. Выполнив запись на сбойный диск, вы можете усугубить проблему. Для всех перечисленных ниже способов, загружайтесь с другого (хорошего) жесткого диска или Live CD, а не с поврежденного накопителя.

Основы fsck

Прежде всего размонтируйте диск (если поврежден корневой раздел, нужно будет загрузиться со спасательного диска или Live CD) и попробуйте запустить на нем fsck. Если вы везунчик, больше ничего и не понадобится.

Если fsck выявит проблемы, то следующий этап – убедиться в том, что это не из-за плохого суперблока (ошибка «bad suoperblock»). Суперблок – часть файловой системы ext2 или ext3, в нем содержатся метаданные: сведения о типе файловой системы, ее размере, статусе и т.д. Без суперблока вам никуда. Поэтому Linux припасает несколько его копий в разных местах, и один плохой суперблок не означает окончательной гибели файловой системы.

Чтобы проверить это, во-первых, получите информацию о суперблоке проблемной файловой системы:

dumpe2fs /dev/hda2 | grep superblock

(dumpe2fs работает и для ext2, и для ext3). В результате вы увидите нечто вроде

 Primary superblock at 0, Group descriptors at 1-3
 Backup superblock at 32768, Group descriptors at 32769-32771
 Backup superblock at 98304, Group descriptors at 98305-98307
 Backup superblock at 163840, Group descriptors at 163841-163843
 [ и так далее ... ]

Теперь подставьте резервную копию суперблока как опцию в fsck:

 fsck -b 32768 /dev/hda2

fsck, вероятно, попросит вас подтвердить несколько исправлений. Обойтись без вопросов позволит запуск fsck с параметром -y, но тут следует быть осторожным, поскольку тогда программа станет действовать на свой страх и риск, невзирая на найденные ошибки.

По завершении работы fsck попытайтесь смонтировать файловую систему обычным образом (через mount). Если проблемы остались, попробуйте передать в mount резервный суперблок:

 mount sb=32768 /dev/hda2 /mnt

dd

Если fsck не принесла вам счастья, следующий шаг – создание побитовой копии данных с помощью dd. Для этого понадобится запасной диск с объемом не менее чем у поврежденного. Копирование диска командой dd бит за битом означает, что даже если диск был в основном пуст, придется все равно перекрыть весь его номинальный размер. Если ваш запасной диск смонтирован в /mnt/recovery, а старый диск подключен как /dev/hda, запустите такую команду (от имени root):

 dd if=/dev/hda of=/mnt/recovery/hdaimage.dd

Отметим: во-первых, диск, взятый в качестве запасного, нельзя использовать как /, так что загружайтесь либо с другого диска, либо с Live CD. Во-вторых, это может занять довольно длительное время (порядка нескольких часов!).

По пути возможна проблема, поскольку по умолчанию dd, обнаружив ошибку, прерывает работу. Тогда попробуйте еще раз, в варианте conv = noerror. Некоторые применяют опцию sync – при этом неполные блоки дописываются нулевыми байтами; однако это идея спорная, так как файл может стать нечитаемым. Или воспользуйтесь dd-rescue (доступно как пакет в Debian/Ubuntu):

 dd_rescue /dev/hda /mnt/recovery/hdaimage.dd

Теперь попробуйте запустить fsck на необработанном образе (fsck /mnt/recovery/hdaimage.dd), а затем подключить его как loopback-устройство ('mount -o loop /mnt/recovery/hdaimage. dd /mnt/hdaimage). Загляните в /mnt/hdaimage – при удаче ваши данные окажутся там!

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

 fdisk -lu /mnt/recovery/hdaimage.dd

Это должно дать вам количество разделов, а также начало и конец каждого. Вы также узнаете размеры адресуемых единиц на диске (например, «sectors of 1 * 512 = 512 bytes»). Если второй раздел начинается на цилиндре 80300, а размер сектора 512 байт, раздел начинается на 80300 x 512 = 41113600 байт. Для монтирования введите:

mount -o loop,offset=41113600 /mnt/recover/hdaimage.raw /mnt/hdaimage

Foremost и извлечение данных

Foremost (http://foremost.sourceforge.net) была разработана Правительством США для восстановления данных. Она «вытаскивает» файлы с образа диска, выявляя их заголовки, окончания и внутренние структуры данных. Для запуска восстановления данных по умолчанию наберите

 foremost image.dd

Или можно найти все определенные виды и записать их в указанный каталог:

 foremost -t all -o /rescue/dir -i image.dd

Параметр -i определяет образ; -o задает выходной каталог для записи, а -t назначает тип файлов. Доступные опции типов файла включают JPEG, ZIP и MPEG. Файлы извлекаются без должных прав доступа и сведений о владельце, и вам нужно потом это поправить.

Аналогичная, но чуть менее ресурсоемкая программа – scalpel; еще одна – magicrescue. Структуру папок эти программы в общем не восстанавливают, просто перетаскивают ваши файлы.

Autopsy

Autopsy (http://www.sleuthkit.org/autopsy) – это «исследовательский» браузер, написанный на Perl; он позволяет просматривать файловую систему в деталях. Если вам не добраться до ваших данных через обычное монтирование, не исключено, что он вам поможет. Пакеты Autopsy доступны в нескольких дистрибутивах.

Применяйте его к образу диска (созданному посредством dd или других вариантов, рассмотренных выше), а не к самому накопителю, поскольку чем больше вы используете ваш поврежденный диск, тем более вероятны дальнейшие повреждения. Запустите Autopsy или Sleuthkit и посмотрите, читается ли файловая система. Бывает, что даже из нечитаемой файловой системы все-таки можно добыть часть метаданных. В таком случае стоит поэкспериментировать с некоторыми инструментами командной строки от Sleuthkit.

• ils извлекает из образа сведения об индексных дескрипторах.
• ffind находит файл или имя каталога с использованием индексного дескриптора.
• icat выводит содержимое файла на основе номера его индексного дескриптора.

Если вы добудете информацию об индексном дескрипторе, используйте ffind для получения имени файла или каталога, а когда поймете, файл это или каталог, используйте icat для вывода содержимого.

Процесс может оказаться долгим и трудным! Но отчасти он автоматизируется, и он спасет ваши данные, или, по крайней мере, часть из них.

Команда fls от Sleuthkit выведет список имен файлов и каталогов, содержащихся в образе, например:

fls hdaimage.dd -r -f ext3 -i

В выводе fls можно увидеть строку

r/r * 10: myfile.txt

Для извлечения содержимого этого файла попробуйте такую команду:

icat -r -f ext3 -i raw hdaimage.dd 10 > myfile.txt

Может также пригодиться сценарий sorter, он ищет опреде- ленные типы файлов (например, изображения).

Альтернативы для dd_rescue

dd_rhelp использует dd_rescue. Он пропускает плохие сектора и возвращается к повторным попыткам их чтения позже – это значит, что время ожидания откладывается на конец работ, и вы можете выбрать отмену задания, а не дожидаться зря на каждом шагу. Другой вариант – ddrescue, которая делает примерно то же самое, но предоставляет вам больший контроль. Так,

ddrescue -n /dev/had /mnt/recovery/hdaimage.raw rescued.log

быстро захватит большую часть неповрежденных областей, после чего можно запустить ту же команду с -r 1 вместо -n, чтобы извлечь все возможное из проблемных. Это вам пригодится, если вы не уверены, долго ли еще протянет ваш диск.

Последнее китайское предупреждение...

Если вы вынуждены были проработать это в гневе, надеюсь, вам удалось найти здесь что-нибудь полезное. Пора разобраться с вашей стратегией резервного копирования! Оно не всегда вас спасет (например, если планово выполняется по ночам, а вы весь день корпели над созданием эпохальной статьи и жесткий диск «спалился» в 23:00...), но, по крайней мере, вы потеряете одиндва дня работы, а не вообще все. LXF