recover.ext23fs.undel

восстановление удаленных файлов под Linux

крис касперски

каждый из нас хотя бы однажды удалял ценный файл (а то и весь корневой каталог целиком!). резервной копии нет. времени на поиски утилит для восстановления — тоже. как быть? к счастью, все необходимое уже включено в ваш любимый дистрибьютив и всегда находится под рукой. если говорить кратко: debugfs, lsdel, stat, cat, dump, undel. если чуть подлиннее — читайте эту статью, рассказывающую о восстановлении данных на ext2fs и отчасти ext3fs разделах.

Информации по восстановлению данных под LINUX'ом практически нет. Как будто у Линуксоидов данные не исчезают. Исчезают еще как! Ошибочное удаление файлов —достаточно распространенное явление, наверное, даже более частное, чем в мире Microsoft. Под Windows большинство файловых операций осуществляется вручную с помощью Проводника или других интерактивных средств типа FAR'а. Интерактивные среды есть и в LINUX (KDE, GNOME, Midnight Commander), но есть там и поклонники командной строки, а командная строка это регулярные выражения и скрипты, то есть автоматизированные средства управления — мощные, удобные, и… разрушительные. Малейшая небрежность их проектирования и… прощай, мои файлы!

Перефразируя Булгакова можно сказать: мало того, что файл смертен, так он еще и внезапно смертен! Беда никогда не предупреждает о своем приходе и администратору приходится быть постоянно начеку. Несколько секунд назад все было хорошо: цвела весна, винчестер оживленно стрекотал всеми своими головками, администратор отхлебывал кофе из черной кружки с надписью root, размышляя толи поиграть в DOOM, толи поболтать с секретаршей, как вдруг… бабах! сотни гигабайт ценнейших данных разлетелись на мелкие осколки. Все силы брошены на разгребания завалов и спасения всех, кого еще можно спасти.

Программ, пригодных для восстановления данных, под Linux совсем немного, намного меньше, чем под Windows NT, да и тем до совершенства как до Луны. Но ведь не разрабатывать же весь необходимый инструментарий самостоятельно?! Будем использовать то, что дают, утешая себя тем, что нашим предкам, работающим на динозаврах машинной эры, приходилось намного сложнее.

редактор диска

Чаще всего линуксоиды редактируют диски при помощи lde(расшифровывается как LinuxDiskEditor). Это, конечно, не Norton Disk Editor, но и не Microsoft Disk Probe. Профессионально-ориентированный инструмент консольного типа с разумным набором функциональных возможностей. Понимает ext2fs, minix, xiafs и отчасти FAT (в перспективе обещана поддержка NTFS, которая на LINUX'e ### линухе никому не нужна, а вот отсутствие в этом списке UFS и FFS очень огорчает).

Поддерживает: отображение/редактирование содержимого в HEX-формате, просмотр супер-блока (super-block), файловых записей (inode) и директорий в удобочитаемом виде; контекстный поиск, поиск файловых записей, ссылающихся на данный блок (полезная штука, только к сожалению, реализованная кое-как и срабатывающая не всегда), режим восстановления с ручным редактированием списка прямых/косвенных блоков, сброс дампа на диск и некоторые другие второстепенные операции.

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

Распространяется в исходных текстах (http://lde.sourceforge.net/), денег не требует, работает практически под любой UNIX-совместимой операционной системой (включая Free BSD) и входит во все «правильные» дистрибьютивы (например, в KNOPPIX).

Рисунок 1 дисковый редактор LDE (LinuxDiskEditor)

Работа с lde на первых порах производит довольно странное впечатление: чувствуешь себя неандертальцем, пересевшим с IBM PC на УКНЦИ/ZX Spectrum и добывающим огонь трением. Впрочем, со временем это проходит (программист, как известно, существо неприхотливое и ко всему привыкающее). Как вариант, можно загрузится со «спасательной дискеты» и использовать знакомый Norton Disk Editor или Runtime NT Explorer, запущенной из-под Windows PE (версия Windows NT, запускающаяся с CD-ROM без предварительной установки на жесткий диск). С одной стороны это удобно (привычный интерфейс и все такое), с другой — ни Disk Editor, ни NT Explorer не поддерживают ext2fs/ext3fs, и все структуры данных приходится декодировать вручную.

hex-редакторы

UNIX – это вам не Windows! Без дисковых редакторов здесь, в принципе, можно и обойтись. Берем любой hex-редактор, открываем соответствующее дисковое устройство (например, /dev/sdb1) и редактируем его в свое удовольствие. Красота! Старожилы должно быть помнят, как во времена первой молодости MS-DOS, когда ни HIEW'а, ни QVIEW'a еще не существовало, правка исполняемых файлов на предмет «отлома» ненужного 7xh обычно осуществлялось DiskEdit'ом, т. е. дисковый редактор использовался как hex. Вот! А в UNIX, наоборот, hex-редакторы используются для редактирования диска.

Какой редактор выбрать? В общем-то это дела вкуса (причем, не только вашего, но еще и составителя дистрьбьютива). Одни предпочитают консольный hexedit, другие тяготеют к графическому khededit, а третьи выбирают BIEW (урезанная калька со всем известного HIEW'a).

Рисунок 2 внешний вид редактора hexedit

Рисунок 3 внешний вид редактора khexedit

отладчики файловой системы

Отладчиками файловой системы называют утилиты, дающие доступ к «святая святых» файловой системе и позволяющие манипулировать ключевыми структурами данных по своему усмотрению. Чем они отличаются от простых редакторов? Редактор работает на более низком уровне — уровне блоков или секторов. Он, в принципе, может представлять некоторые структуры в наглядном виде, однако, в их «физический» смысл никак не вникает.

Отладчик файловой системы работает через драйвер и потому испортить раздел с его помощью намного сложнее. Он реализует довольно высокоуровневые операции, такие как установка/снятие флага занятости блока, создание новой символьной ссылки и т. д. А вот «посекторного» hex-редактора отладчики файловой системы обычно не содержат, поэтому обе категории программ взаимно дополняют друг друга.

Большинство (если не все) дистрибутивов Linux'а включают в себя отладчик debugfs, поддерживающий ext2fs и отчасти ext3fs.

Рисунок 4 debugfs за работой

дисковые доктора

В мире UNIX проверка целостности файловой системы обычно осуществляется программой fsck (аналог chkdsk под Windows NT), представляющей собой консольную утилиту, практически лишенную пользовательского интерфейса и входящую в штатный комплект поставки любого дистрибьютива. Как и любое другое полностью автоматизированное средство она не только лечит, но, случается, что и калечит, так что пользоваться ей следует с большой осторожностью.

LiveCD

За последние несколько лет появилось множество дистрибьютивов Linux'а, загружающихся прямо с CD-ROM и не требующих установки на винчестер. Очень удобная штука для восстановления данных. Однако, далеко не все дистрибьютвы для этого пригодны (в частности, недавно анонсированный в «Системном Администраторе» SuSE не подходит точно), поэтому кратный обзор не помешает.

KNOPPIX 3.7 — самый лучший дистрибутив из всех. Основан на GNU/Debian. Занимает всего один диск, но содержит практически все: от дисковых утилит и компиляторов до офисных пакетов и мультимедийных приложений. Очень шустро работает, требует от 128 Мбайт оперативной памяти (если меньше — будет свопиться на диск). В 2004 году издательство O'Reilly выпустило шикарную книгу «KNOPPIXHacks», содержащую главы, посвященные технике восстановления данных. Саму книжку можно найти в Осле, а KNOPPIX заказать в Интернет-магазине www.linuxcenter.ru.

Ferenzy 0.3 – дистрибьютив, основанный на Free BSD с небольшим количеством дисковых утилит, ориентированных на ext2fs, в то время как основной файловой системой самой BSD является USF/FFS и ext2fs она поддерживает постольку-поскольку. Тем не менее для восстановительных работ данный диск вполне пригоден, и всем поклонникам BSD его можно смело рекомендовать.

SuSE 9.2 – отвратительный дистрибутив. Занимает два диска (один с KDE, другой с GNOME). Требует не менее 256 Мбайт оперативной памяти (правда, KDE версия запускается и при 220 Мбайтах). Очень медленно работает и не содержит ничего кроме щепотки офисных программ.

Прежде, чем приступать к восстановлению, обязательно размонтируете дисковый раздел или на худой конец перемонтируете его в режим «только на чтение». Лечение активных разделов зачастую только увеличивает масштабы разрушения. Если восстанавливаемые файлы находятся на основном системном разделе у нас два пути – загрузится с LiveCD или подключить восстанавливаемый жесткий диск на Linux-машину вторым.

Чтобы чего-нибудь не испортить, никогда не редактируйте диск напрямую. Работайте с его копией! Копию можно создать командой cp /dev/sdb1 my_dump, где sdb1 – имя устройства, а my_dump — имя файла-дампа. Файл-дамп можно разместить на любом свободном разделе или перегнать на другую машину по сети. Все дисковые утилиты (lde, debugsf, fschk) не заметят подвоха и будут работать с ним как с «настоящим» разделом. При необходимости его даже можно смонтировать на файловую систему: mount my_dump mount_point –o loop, чтобы убедиться, что восстановление прошло успешно. Команда cp my_dump /dev/sdb1 копирует восстановленный файл-дамп обратно в раздел, хотя делать это совсем необязательно. Проще (и безопаснее) копировать только восстанавливаемые файлы.

Файловая система ext2fs все еще остается базовой файловой системой для многих Linux'ов, поэтому рассмотрим ее первой. Концепции, которые она исповедует, во многом схожи с NTFS, так что культурного шока при переходе с NTFS на ext2fs с нами не случится. Подробное описание структуры хранения данных ищите в документе «DesignandImplementationoftheSecondExtendedFilesystem», а так же книге Таненбаума «OperatingSystems: DesignandImplementation», электронную версию которой можно раздобыть в Осле. Исходные тексты дисковых утилит (драйвер файловой системы, lde, debugfs) так же не помешают.

структура файловой системы

В начале диске расположен boot-сектор (на незагрузочных разделах он может быть пустым). За ним, по смещению 1024 байта от начала первого сектора лежит супер-блок (super-block), содержащий ключевую информацию о структуре файловой системе. (В FAT и NTFS эта информация хранится непосредственно в boot). В первую очередь нас будет интересовать 32-разрядное поле s_log_block_size, расположенное по смещению 18h байт от начала супер-блока. Здесь храниться размер одного блока (block) или, в терминологии MS-DOS/Windows, кластера, выраженный в виде показателя позиции, на которую нужно сдвинуть число 200h. В естественных единицах это будет звучать так:block_size = 200h « s_log_block_size (байт). То есть, если s_log_block_size равен нулю, размер одного блока составляет 400h байт или два стандартных сектора.

смещение размер описание

——- ——- ———–

0 1 bootrecord; загрузочный сектор

blockgroup 0 –; группа блоков 0

(1024 bytes) 1 superblock; суперблок

2 1 group descriptors; дескрипторгруппы

3 1 blockbitmap; карта свободных блоков

4 1 inodebitmap; карта свободных inode

5 214 inodetable; массив inode (сведения о файлах)

219 7974 datablocks; блоки данных (файлы, директории)

blockgroup 1 –; группа блоков 1

8193 1 superblock backup; копиясуперблока

8194 1 group descriptors backup ; копиядескрпиорагруппы

8195 1 blockbitmap; карта свободных блоков

8196 1 inodebitmap; карта свободных inode

8197 214 inodetable; массив inode (сведения о файлах)

8408 7974 datablocks; блоки данных (файлы, директории)

blockgroup 2 –; группа блоков 2

16385 1 blockbitmap; карта свободных блоков

16386 1 inodebitmap; карта свободных inode

16387 214 inodetable; массив inode (сведения о файлах)

16601 3879 datablocks; блоки данных (файлы, директории)

Листинг 1 структура дискового тома, размеченного под ext2fs

Вслед за супер-блоком идут дескрипторы групп (groupdescriptors), и карты свободного пространства, в просторечии — битмапы (blockbitmap/inodebitmap), которые нас мало интересуют, а вот indoe-таблицу, расположенную за ними, мы рассмотрим поподробнее. В ext2fs (как и многих других файловых системах из мира UNIX), inode играет ту же самую роль, что и FILE Record в NTFS. Здесь сосредоточена вся информация о файле: тип файла (обычный файл, директория, символьная ссылка и т. д.), логический и физический размер, схема размещения на диске, время создания, модификации, последнего доступа и удаления, правда доступа и количество ссылок на файл.

смещение размер описание

——- ——- ———–

0 2 i_mode; формат представления описание

2 2 i_uid; uid пользователя

4 4 i_size; размер файла в байтах

8 4 i_atime; время последнего доступа к файлу

12 4 i_ctime; время создания файла

16 4 i_mtime; время модификации файла

20 4 i_dtime; время удаления файла

24 2 i_gid; gid группы

26 2 i_links_count; количество ссылок на файл (0 – файл удален)

28 4 i_blocks; количество блоков, принадлежащих файлу

32 4 i_flags; разные флаги

36 4 i_osd1; OS dependant value

40 12 x 4 i_block; 12 DIRECTBLOCKS (ссылки на первые 12 блоков файла)

88 4 i_iblock; 1x INDIRECT BLOCK

92 4 i_2iblock; 2x INDIRECT BLOCK

96 4 i_3iblock; 3x INDIRECT BLOCK

100 4 i_generation; поколение файла (используется NFS)

104 4 i_file_acl; внешниеатрибуты

108 4 i_dir_acl; higer size

112 4 i_faddr; положение последнего фрагмента

116 12 i_osd2; OS dependant structure

Листинг 2 формат представления inode

Первые 12 блоков, занимаемых файлов, хранятся непосредственно в самой inod'е в массиве DIRECT BLOCKS (непосредственные блоки, для наглядности выделены полужирным). Каждый элемент массива представляет собой 32-битный номер блока. При среднем значении BLOCK_SIZE в 4 Кбайта, DIRECT BLOCK'и могут адресовать до 4 12 == 48 Байт данных. Если файл превышает этот размер, создаются один или несколько блоков косвенной адресации (INDIRECT BLOCK). Первый блок косвенной адресации (1x INDIRECT BLOCK или просто INDIRECT BLOCK) хранит ссылки на другие непосредственные блоки и может. Адрес этого блока хранится в поле i_indirect_blockв inod'e. Как легко посчитать, он адресует порядка BLOCK_SIZE/sizeof(DWORD) * BLOCK_SIZE = 4096/4 *4 Мбайт данных. Если этого вдруг окажется недостаточно, создается дважды косвенный блок (2x INDIRECT BLOCK или DOUBLE INDIRECT BLOCK), хранящий указатели на косвенные блоки, что позволяет адресовать (BLOCK_SIZE/sizeof(DWORD))2* BLOCK_SIZE =4096/4  4096 == 4 Гбайт данных. Если же этого все равно недостаточно, создается трижды косвенный блок (3x INDIRECT BLOCK или TRIPLE INDIRECT BLOCK), содержащий ссылки на дважды косвенные блоки (на данном рисунке трижды косвенный блок не показан).

Отметим, что по сравнению с NTFS такая схема хранения информации об размещении намного более просто устроена, но в месте с тем и прожорлива. Однако, одна обладает одним несомненным достоинством, которое рвет NTFS как Тузик грелку. Поскольку все ссылки хранятся в неупакованном виде, для каждого блока файла мы может быстро найти соответствующий ему косвенный блок, даже если inod'а полностью разрушена.

Рисунок 5 описание порядка размещения файла на диске, иерархия непосредственных и косвенных блоков

Имя файла в inode не хранится. Ищите его внутри директорией, представляющих собой массив записей следующего вида:

смещение размер описание

——- ——- ———–

0 4 inode; ссылка на inod'у

4 2 rec_len; длина данной записи

6 1 name_len; длина имени файла

7 1 file_type; типфайла

8 … name; имя файла

Листинг 3 формат представления массива директорий

При удалении файла, операционная система находит соответствующую запись в директории. Обнуляет поле inode и увеличивает размер предшествующей записи (поле ren_len) на величину удаляемой. То есть, предшествующая запись как бы «поглощает» удаленную. И хотя имя файла до поры до времени остается нетронутым, ссылка на соответствующую ему inod'у оказывается уничтоженной. Вот и попробуй разобраться какому файлу какое имя принадлежит!

В самой inod'e при удалении файла тоже происходят большие изменения. Количество ссылок (i_links_count) сбрасывается в нуль и обновляется поле последнего удаления (i_dtime). Все блоки, принадлежащие файлу, в карте свободного пространства (blockbitmap) помечаются как неиспользуемые, после чего данная inod'а так же освобождается (inodebitmap).

техника восстановления удаленных файлов

В ext2fs полное восстановление даже только что удаленных файлов, невозможно. В этом смысле она проигрывает как FAT, так и NTFS. Как минимум теряется имя файла. Точнее говоря, теряется связь имен файлов с их содержимым. При удалении небольшого количества хорошо известных файлов это еще терпимо (имена-то ведь сохранились!), но что делать, если вы удалили несколько служебных подкаталогов, в которых никогда ранее не заглядывали?

Достаточно часто inod'ы назначаются в том же порядке, в котором создаются записи в таблице директорий, к тому же существует такая штука как «расширения» (.c, .gz, .mpg и т. д.), так количество возможных комбинаций соответствий чаще всего бывает относительно небольшим. Тем не менее, восстановить удаленный корневой каталог в автоматическом режиме никому не удастся (а вот NTFS с этим справляется без труда).

В общем случае, стратегия восстановления выглядит приблизительно так: сканируем таблицу inode и отбираем все записи, чье поле i_links_count равно нулю. Сортируем их по дате удаления, чтобы файлы, удаленные последними, оказались наверху списка. Как вариант, можно просто наложить фильтр (мы ведь помним примерное время удаления, не правда ли?). Если соответствующие inod'ы еще не затерты вновь создаваемыми файлами, извлекаем список прямых/косвенных блоков и записываем их в дамп, корректируя его размер с учетом «логического» размера файла, за которое отвечает поле i_size.

восстановление при помощи lde

Открываем редактируемый раздел или его файловую копию: «lde my_dump» или «lde /dev/sdb1». Редактор автоматически определяет тип файловой системы (в данном случае ext2fs) и предлагает нажать any key для продолжения. Нажимаем! Редактор автоматически переключается в режим отображения супер-блока, и предлагает нажать <I> для перехода в режим inode и <B> для перехода в блочный режим (block-mode). Жмем <I> и оказываемся в первой inod'e, описывающей корневой каталог. <Page Dowd> перемещает нас к следующей inod'e, а <Page Up> к предыдущей. Пролистываем inod'ы вниз, обращая внимание на поле LINKS. У удаленных файлов оно равно нулю и тогда «DELETIONTIME» содержит время последнего удаления (мы ведь помним его, правда?). Обнаружив подходящую inod'у, перемещаем курсор к первому блоку в списке DIRECT BLOCKS (где он должен находиться по умолчанию) и нажимаем <F2>. В появившемся меню выбираем пункт «Block mode, viewingblockundercursor» (или сразу нажимаем горячу клавишу <Shift-B>). Редактор перемещается на первый блок удаленного файла. Просматривая его содержимое в hex-режиме, пытаемся определить он ли это или нет. Чтобы возвратиться к просмотру следующей inod'ы, нажимаем <I>, чтобы восстановить файл — <Shift-R>, затем еще раз <R> и имя файла-дампа для восстановления.

Можно восстанавливать файлы и по их содержимому. Допустим, нам известно, что удаленный файл содержит строку «hello, world». Нажимаем <f> изатем <A> (Search all block). Этим мы заставляем редактор искать ссылки на все блоки, в том числе и удаленные. Как вариант, можно запустить редактор с ключом «–all». Но так или иначе, мы нажимаем <B>, и когда редактор перейдет в block-mode, давим </> и вводим ASCII-строку для поиска. Находим нужный блок. Прокручивая его вверх-вниз, убеждаемся, что он действительно принадлежит тому самому файлу. Если это так, нажимаем <Ctrl>+<R>, заставляя редактор просматривать все inod'ы, содержащие ссылку на этот блок. Номер текущей найденной inod'ы отображается внизу экрана. (Именно что внизу! Вверху отображается номер последней просмотренной inod'ы в режиме inod'e). Переходим в режим inod'е по клавише <I>, нажимаем <#> и вводим номер inod'ы, которую хотим просмотреть. Если дата удаления более или менее соответствует действительности, нажимаем <Shift-R>/<R> для сброса файла на диск. Если нет — возвращаемся в block-mode и продолжаем поиск.

В сложных случаях, когда список прямых и/или косвенных блоков разрушен, восстанавливаемый файл приходится собирать буквально по кусочкам, основываясь на его внутреннем содержимом и частично — на стратегии выделения свободного пространства файловой системой. В этом нам поможет клавиша <w>  — дописать текущий блок к файлу-дампу. Просто перебираем все свободные блоки один за другим (редактор помечает их строкой NOT USED), и обнаружив подходящий, дописываем в файл. Конечно, сильно фрагментированный бинарник так не восстановить, но вот листинг программы — можно вполне.

Вывод — ручное восстановление файлов с помощью lde крайне непроизводительно и трудоемко, зато наиболее «прозрачно» и надежно. А вот восстанавливать оригинальные имена лучше всего при помощи debugfs.

восстановление при помощи debugfs

Загружаем в отладчик редактируемый раздел или его копию, «debugfs my_dump» или «debugfs /dev/sdb1». Если мы планируем осуществлять запись на диск, необходимо указать ключ «–w» («debugfs —w my_dump» или «debugfs —w /dev/sdb1».

Чтобы просмотреть список удаленных файлов даем команду «lsdel» (или «lsdel t_sec», где t_sec количество секунд, прошедшее со момента удаления файла). Экран заполняется список удаленных файлов. Естественно без имен. Файлы, удаленные более, чем t_sec секунд назад (если sec задан) в этот список не попадают.

Команда «cat <N>», выводит содержимое текстового файла на терминал, где <N>, номер inod'ы, заключенный в угловые кавычки. При выводе двоичных файлов на экране творится черт знает что, и такие файлы должны сбрасываться в дамп командой «dump <N> new_file_name», где new_file_name новое имя файла (с путем), под которым он будет записан в нативную (native) файловую систему, т. е. ту файловую систему из-под которой был запущен debugfs. Файловая система восстанавливаемого раздела при этом остается неприкосновенной. Другими словами, наличие ключа «–w» для этого не требуется.

При желании можно восстановить файл непосредственно на самой восстанавливаемой файловой системе (что особенно удобно при восстановлении больших файлов). В этом нам поможет команда «undel <N> undel_file_name», где undel_file_name — имя, которое будет присвоено файлу после восстановления. Внимание! Когда будете это делать, помните, что команда undel крайне агрессивна и деструктивна по своей природе. Она затирает первую свободную запись в таблице директорий, делая восстановление оригинальных имен невозможным!

Команда «stat <N>» отображает содержимое inod'ы в удобочитаемом виде, а команда «mi <N>» позволяет редактировать их по своему усмотрению. Для ручного восстановления файла (которого не пожелаешь и врагу) мы должны установить счетчик ссылок (link count) в единицу, а время удаления (deletiontime), наоборот, сбросит в нуль. Затем отдать команду «seti <N>», помечающую данную inod'у как используемую, и для каждого из блоков файла выполнить «setb X», где X – номер блока (перечень блоков, занимаемых файлов, можно подсмотреть командой stat, причем, в отличии от lde она отображает не только непосредственные, но и косвенные блоки, что несравненно удобнее). Остается только дать файлу имя, что осуществляется путем создания каталожной ссылки (directorylink), а делает это команда «ln <N> undel_file_name», где undel_file_name – имя, которое будет дано файлу после восстановления, при необходимости с путем. (Внимание! создание каталожных ссылок необратимо затирает оригинальные имена удаленных файлов). После этого полезно дать команду «dirty», чтобы файловая система была автоматически проверка при следующей загрузке, или выйти из отладчика и вручную запустить fsck с ключом «–f», форсирующим проверку.

Теперь перейдем к восстановлению оригинального имени. Рассмотрим простейший случай, когда директория, содержащая удаленный файл (так же называемая материнской директорией) все еще цела. Даем команду «stat dir_name» и запоминаем номер inode, который нам сообщат. Говорим отладчику «dump <INODE> dir_file», где INODE – номер сообщенной inod'ы, dir_file имя файла нативной файловой системы, в которую будет записан дамп. Загружаем полученный дамп в hex-редактор и просматриваем его содержимое в «сыром» виде. Все имена будет там. При желании можно написать утилиту-фильтр, выводящую только удаленные имена. На Perl'е это не замет и десяти минут.

А как быть если материнская директория тоже удалена? Тогда она и будет помечена удаленной! Выводим список удаленных inod'е, отбираем из них директории, формируем перечень принадлежащих им блоков и дампим в файл, просматриваемый вручную или с помощью утилиты-фильтра. Как уже отмечалось, порядок расположения файлов в inod'е очень часто совпадает с порядком расположения файлов в директории, поэтому восстановление оригинальных имен в четырех из пяти случаев проходит на ура.

При тяжких разрушениях, когда восстанавливаемый файл приходится собирать по кусочкам, помогает команда «dump_unused», выводящая на терминал в все неиспользуемые блоки. Имеет смысл перенаправить вывод в файл, запустить hexedit и покопаться в этой куче хлама — это по крайней мере проще, чем лазить по всему диску (на дисках, заполненных более чем на три четверти, этот трюк сокращает массу времени).

Вывод: debugfs в значительной мере автоматизирует восстановление удаленных файлов (впрочем, до полного комфорта ему далеко), однако, восстановить файл с разрушенным inode он не способен и без lde здесь не обходится.

восстановление при помощи R-Studio

Утилита R-Studio for NTFS, уже рассмотренная нами в предыдущих номерах журнала, вопреки своему названию, поддерживает не только NTFS, но и ext2fs/ext3fs. С точки зрения неквалифицированных пользователей это хорошее средство для автоматического восстановления удаленных файлов: интуитивно-понятный интерфейс, простое управление и прочие прелести прогресса. Файлы восстанавливаются несколькими щелчками. Правда без и имен и без каких-либо гарантий, что они вообще восстановятся. Ручное восстановление не поддерживается. Файлы с разрушенной inode не восстанавливаются, хотя под ext2fs, в отличии от NTFS это достаточно просто сделать!

В общем, для профессионального использования R-Studio катастрофически не подходит.

Рисунок 6 утилита R-Studio forNTFS восстанавливает удаленные файлы на ext2fs разделе. Файлы есть, но нет имен.

Файловая система ext3fs это ext2fs с поддержкой журналирования (в терминологии NTFS – транзакций). В отличие от ext2fs она намного бережнее относится к массиву директорий и при удалении файла, ссылка на inode уже не уничтожается, что упрощает автоматическое восстановление оригинальных имен. Однако, поводов для радости у нас нет никаких, поскольку в ext3fs перед удалением файла список принадлежащих ему блоков тщательно вычищается. Как следствие — восстановление становится невозможно. Ну… практически невозможно. Нефрагментированные файлы с более или менее осмысленным содержимым (например, исходные тексты программ) еще можно собрать по частям, но и времени на это уйдет… К счастью, косвенные блоки не очищаются, а, значит, мы теряем лишь первые 12 * BLOCL_SIZE байт каждого файла. На типичном 10 Гбайтном разделе BLOCK_SIZE обычно равен 4- или 8 Кбайтам, т. е. реальные потери составляют менее 100 Кбайт. По современным понятиям сущие пустяки! Конечно, без этих 100 Кбайт большинство файлов просто не запустятся, однако, недостающие 12 блоков найти на диске вполне реально. Если повезет, они окажутся расположенными в одном-двух непрерывных отрезках. Даже на сильно фрагментированных разделах, непрерывные отрезки из 6-12 блоков достаточно часто встречаются.

Как мы будем действовать? Необходимо найти хотя бы один блок, гарантированно принадлежащий файлу и при этом расположенных за границей в 100 Кбайт от его начала. Это может быть текстовая строка, копирайт фирмы да все что угодно! Короче, нам нужен номер блока. Пусть для определенности он будет равен 0x1234. Записываем его в обратном порядке так, чтобы младший байт располагался по меньшему адресу и выполняем поиск 34h 12h 00h 00h — именно это число будет присутствовать в косвенном блоке. Отличить косвенный блок от всех остальных блоков (например, блоков, принадлежащих файлам данных) очень легко — он представляет собой массив 32-битных номеров блоков более или менее монотонно возрастающих. Дважды и трижды косвенные блоки отыскиваются по аналогичной схеме.

Проблема в том, что одни и те же блоки в разное время могли принадлежать различным файлам, а, значит, и различным косвенным блокам. Как разобраться какой из них правильный? Да очень просто! Если хотя бы одна из ссылок косвенного блока указывает на уже занятый блок, данный косвенный блок принадлежит давно удаленному файлу и нам совсем не интересен.

Кстати говоря, debugfs довольно криво поддерживает ext3fs. В частности, команда lsdel всегда показывает ноль удаленных файлов, даже если грохнуть ### удалить весь раздел. Так что вопрос выбора файловой системы отнюдь не так прост, каким его пытаются представить книги «LINUX для начинающих», а преимущества ext3fs на рабочих станциях и домашних компьютерах далеко небесспорны и неочевидны. Поддержка транзакций реально требуется лишь серверам (да и то не всем), а вот невозможность восстановления ошибочного удаленных файлов зачастую приносит намного большие убытки, чем устойчивость файловой к внезапным отказам питания.

Рисунок 7 утилита R-Studio, восстанавливающая удаленные файлы на разделе ext3fs. есть имена, нету самих файлов (их длина равна нулю, т.к. список непосредственных блоков затерт)

Доступность исходных текстов драйвера файловой системы значительно упрощает исследование ее внутренней структуры, которая кстати говоря очень проста и восстановление данных на ext2fs/ext3fs – плевое дело. Файловые системы UFS и FFS, работающие под Free BSD, устроены намного сложнее, к тому же достаточно скудно документированы. А ведь Free BSD занимает далеко не последнее место в мире UNIX-совместимых операционных систем и разрушения данных даже в масштабах небольшого городка происходят сплошь и рядом. К счастью, в подавляющем большинстве случаев информацию можно полностью восстановить, но об этом — в следующий раз.

  1. Design and Implementation of the Second Extended File system
    1. подробное описание файловой системы ext2fs от самих разработчиков проекта. на английском языке. http:e2fsprogs.sourceforge.net/ext2intro.html; - Linux Ext2fs Undeletion mini-HOWTO - краткая, но доходчивая инструкция по восстановлению удаленных файлов на ext2fs разделах. на английском языке. http:www.praeclarus.demon.co.uk/tech/e2-undel/howto.txt;
  2. Ext2fs Undeletion of Directory Structures mini-HOWTO
    1. краткое руководство по восстановлению удаленных директорий на ext2fs разделах. на английском языке: http:www.faqs.org/docs/Linux-mini/Ext2fs-Undeletion-Dir-Struct.html; - HOWTO-undelete - еще одно руководство по восстановлению удаленных файлов на ext2fs разделах с помощью редактора lde. на английском языке. http:lde.sourceforge.net/UNERASE.txt;