Различия

Здесь показаны различия между двумя версиями данной страницы.

Ссылка на это сравнение

articles:recover.ext23fs.undel [2017/09/05 02:55] (текущий)
Строка 1: Строка 1:
 +====== recover.ext23fs.undel ======
 +<​sub>​{{recover.ext23fs.undel.odt|Original file}}</​sub>​
 +
 +====== восстановление удаленных файлов под Linux ======
 +
 +крис касперски
 +
 +**каждый из нас хотя бы однажды удалял ценный файл (а то и весь корневой каталог целиком!). резервной копии нет. времени на поиски утилит для восстановления — тоже. как быть? к счастью,​ все необходимое уже включено в ваш любимый дистрибьютив и всегда находится под рукой. если говорить кратко:​ ****debugf****s,​ lsdel, stat, cat, dump, undel. если чуть подлиннее — читайте эту статью,​ рассказывающую о восстановлении данных на ****ext****2****fs**** и отчасти ****ext****3****fs**** разделах.**
 +
 +===== введение =====
 +
 +Информации по восстановлению данных под LINUX'​ом практически нет. Как будто у Линуксоидов данные не исчезают. Исчезают еще как! Ошибочное удаление файлов —достаточно распространенное явление,​ наверное,​ даже более частное,​ чем в мире Microsoft. Под Windows большинство файловых операций осуществляется вручную с помощью Проводника или других интерактивных средств типа FAR'​а. Интерактивные среды есть и в LINUX (KDE, GNOME, Midnight Commander),​ но есть там и поклонники командной строки,​ а командная строка это регулярные выражения и скрипты,​ то есть автоматизированные средства управления — мощные,​ удобные,​ и… разрушительные. Малейшая небрежность их проектирования и… прощай,​ мои файлы!
 +
 +Перефразируя Булгакова можно сказать:​ мало того, что файл смертен,​ так он еще и внезапно смертен! Беда никогда не предупреждает о своем приходе и администратору приходится быть постоянно начеку. Несколько секунд назад все было хорошо:​ цвела весна, винчестер оживленно стрекотал всеми своими головками,​ администратор отхлебывал кофе из черной кружки с надписью root, размышляя толи поиграть в DOOM, толи поболтать с секретаршей,​ как вдруг… бабах! сотни гигабайт ценнейших данных разлетелись на мелкие осколки. Все силы брошены на разгребания завалов и спасения всех, кого еще можно спасти.
 +
 +===== инструментарий =====
 +
 +Программ,​ пригодных для восстановления данных,​ под Linux совсем немного,​ намного меньше,​ чем под Windows NT,​ да и тем до совершенства как до Луны. Но ведь не разрабатывать же весь необходимый инструментарий самостоятельно?​! Будем использовать то, что дают, утешая себя тем, что нашим предкам,​ работающим на динозаврах машинной эры, приходилось намного сложнее.
 +
 +==== редактор диска ====
 +
 +Чаще всего линуксоиды редактируют диски при помощи **lde**(расшифровывается как //​**L**////​inux////​**D**////​isk////​**E**////​ditor//​). Это, конечно,​ не 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).
 +
 +{{recover.ext23fs.undel.lite_Image_0.png}}
 +
 +Рисунок 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).
 +
 +{{recover.ext23fs.undel.lite_Image_1.png}}
 +
 +Рисунок 2 внешний вид редактора hexedit
 +
 +{{recover.ext23fs.undel.lite_Image_2.png}}
 +
 +Рисунок 3 внешний вид редактора khexedit
 +
 +==== отладчики файловой системы ====
 +
 +Отладчиками файловой системы называют утилиты,​ дающие доступ к "​святая святых"​ файловой системе и позволяющие манипулировать ключевыми структурами данных по своему усмотрению. Чем они отличаются от простых редакторов?​ Редактор работает на более низком уровне — уровне блоков или секторов. Он, в принципе,​ может представлять некоторые структуры в наглядном виде, однако,​ в их "​физический"​ смысл никак не вникает.
 +
 +Отладчик файловой системы работает через драйвер и потому испортить раздел с его помощью намного сложнее. Он реализует довольно высокоуровневые операции,​ такие как установка/​снятие флага занятости блока, создание новой символьной ссылки и т. д. А вот "​посекторного"​ hex-редактора отладчики файловой системы обычно не содержат,​ поэтому обе категории программ взаимно дополняют друг друга.
 +
 +Большинство (если не все) дистрибутивов Linux'​а включают в себя отладчик **debugfs**,​ поддерживающий ext2fs и отчасти ext3fs.
 +
 +{{recover.ext23fs.undel.lite_Image_3.png}}
 +
 +Рисунок 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 =====
 +
 +Файловая система 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; загрузочный сектор
 +
 +** ****-- ****block****group**** 0 --; группа блоков 0**
 +
 +(1024 bytes) ​ 1 superblock; суперблок
 +
 + ​2 ​ 1 group descriptors;​ дескрипторгруппы
 +
 + ​3 ​ 1 blockbitmap;​ карта свободных блоков
 +
 + ​4 ​ 1 inodebitmap;​ карта свободных inode
 +
 + ​5 ​ 214 inodetable; массив inode (сведения о файлах)
 +
 + ​219 ​ 7974 datablocks; блоки данных (файлы,​ директории)
 +
 +** ****-- ****block****group**** 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; блоки данных (файлы,​ директории)
 +
 +** ****-- ****block****group**** 2 --; группа блоков 2**
 +
 + ​16385 ​ 1 blockbitmap;​ карта свободных блоков
 +
 + ​16386 ​ 1 inodebitmap;​ карта свободных inode
 +
 + ​16387 ​ 214 inodetable; массив inode (сведения о файлах)
 +
 + ​16601 ​ 3879 datablocks; блоки данных (файлы,​ директории)
 +
 +Листинг 1 структура дискового тома, размеченного под ext2fs
 +
 +Вслед за супер-блоком идут //​**дескрипторы групп **//​(//​**group**////​**descriptors**//​),​ и //​**карты свободного пространства**//,​ в просторечии — //​битмапы//​ (//​**block**////​**bitmap**////​**/​**////​**inode**////​**bitmap**//​),​ которые нас мало интересуют,​ а вот 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 ****DIRECT****BLOCKS**** (ссылки на первые 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'​а полностью разрушена.
 +
 +{{recover.ext23fs.undel.lite_Image_4.png}}
 +
 +Рисунок 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 катастрофически не подходит.
 +
 +{{recover.ext23fs.undel.lite_Image_5.png}}
 +
 +Рисунок 6 утилита R-Studio forNTFS восстанавливает удаленные файлы на ext2fs разделе. Файлы есть, но нет имен.
 +
 +===== восстановление удаленных файлов на 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 на рабочих станциях и домашних компьютерах далеко небесспорны и неочевидны. Поддержка транзакций реально требуется лишь серверам (да и то не всем), а вот невозможность восстановления ошибочного удаленных файлов зачастую приносит намного большие убытки,​ чем устойчивость файловой к внезапным отказам питания.
 +
 +{{recover.ext23fs.undel.lite_Image_6.png}}
 +
 +Рисунок 7 утилита R-Studio, восстанавливающая удаленные файлы на разделе ext3fs. есть имена, нету самих файлов (их длина равна нулю, т.к. список непосредственных блоков затерт)
 +
 +===== заключение =====
 +
 +Доступность исходных текстов драйвера файловой системы значительно упрощает исследование ее внутренней структуры,​ которая кстати говоря очень проста и восстановление данных на ext2fs/​ext3fs – плевое дело. Файловые системы UFS и FFS, работающие под Free BSD, устроены намного сложнее,​ к тому же достаточно скудно документированы. А ведь Free BSD занимает далеко не последнее место в мире UNIX-совместимых операционных систем и разрушения данных даже в масштабах небольшого городка происходят сплошь и рядом. К счастью,​ в подавляющем большинстве случаев информацию можно полностью восстановить,​ но об этом — в следующий раз.
 +
 +===== >>>​ врезкачточитать =====
 +
 +  - **Design and Implementation of the Second Extended File system**
 +    - подробное описание файловой системы ext2fs от самих разработчиков проекта. на английском языке. __http____://​____e____2____fsprogs____.____sourceforge____.____net____/​____ext____2____intro____.____html__;​
 +  - **Linux Ext2fs Undeletion mini-HOWTO**
 +    - краткая,​ но доходчивая инструкция по восстановлению удаленных файлов на ext2fs разделах. на английском языке. __http____://​____www____.____praeclarus____.____demon____.____co____.____uk____/​____tech____/​____e____2-____undel____/​____howto____.____txt____;​__
 +  - **Ext2fs Undeletion of Directory Structures mini-HOWTO**
 +    - краткое руководство по восстановлению удаленных директорий на ext2fs разделах. на английском языке: __http____://​____www____.____faqs____.____org____/​____docs____/​____Linux____-____mini____/​____Ext____2____fs____-____Undeletion____-____Dir____-____Struct____.____html__;​
 +  - HOWTO-undelete
 +    - еще одно руководство по восстановлению удаленных файлов на ext2fs разделах с помощью редактора lde. на английском языке. __http____://​____lde____.____sourceforge____.____net____/​____UNERASE____.____txt____;​__
 +