В 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. У удаленных файлов оно равно нулю и тогда "DELETION TIME" содержит время последнего удаления (мы ведь помним его, правда?). Обнаружив подходящую inod'у, перемещаем курсор к первому блоку в списке DIRECT BLOCKS (где он должен находиться по умолчанию) и нажимаем <F2>. В появившемся меню выбираем пункт "Block mode, viewing block under cursor" (или сразу нажимаем горячу клавишу <Shift-B>). Редактор перемещается на первый блок удаленного файла. Просматривая его содержимое в hex-режиме, пытаемся определить он ли это или нет. Чтобы возвратиться к просмотру следующей inod'ы, нажимаем <I>, чтобы восстановить файл — <Shift-R>, затем еще раз <R> и имя файла-дампа для восстановления.
Можно восстанавливать файлы и по их содержимому. Допустим, нам известно, что удаленный файл содержит строку "hello, world". Нажимаем
В сложных случаях, когда список прямых и/или косвенных блоков разрушен, восстанавливаемый файл приходится собирать буквально по кусочкам, основываясь на его внутреннем содержимом и частично — на стратегии выделения свободного пространства файловой системой. В этом нам поможет клавиша <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) в единицу, а время удаления (deletion time), наоборот, сбросит в нуль. Затем отдать команду "seti <N>", помечающую данную inod'у как используемую, и для каждого из блоков файла выполнить "setb X", где X – номер блока (перечень блоков, занимаемых файлов, можно подсмотреть командой stat, причем, в отличии от lde она отображает не только непосредственные, но и косвенные блоки, что несравненно удобнее). Остается только дать файлу имя, что осуществляется путем создания каталожной ссылки (directory link), а делает это команда "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 катастрофически не подходит.
восстановление удаленных файлов на ext3fs
Файловая система 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 на рабочих станциях и домашних компьютерах далеко небесспорны и неочевидны. Поддержка транзакций реально требуется лишь серверам (да и то не всем), а вот невозможность восстановления ошибочного удаленных файлов зачастую приносит намного большие убытки, чем устойчивость файловой к внезапным отказам питания.
Комментариев нет:
Отправить комментарий