подготовка к восстановлению
Прежде, чем приступать к восстановлению, обязательно размонтируете дисковый раздел или на худой конец перемонтируете его в режим "только на чтение". Лечение активных разделов зачастую только увеличивает масштабы разрушения. Если восстанавливаемые файлы находятся на основном системном разделе у нас два пути – загрузится с 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 с нами не случится. Подробное описание структуры хранения данных ищите в документе "Design and Implementation of the Second Extended Filesystem", а так же книге Таненбаума "Operating Systems: Design and Implementation", электронную версию которой можно раздобыть в Осле. Исходные тексты дисковых утилит (драйвер файловой системы, 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 boot record ; загрузочный сектор
-- block group 0 -- ; группа блоков 0
(1024 bytes) 1 superblock ; суперблок
2 1 group descriptors ; дескриптор группы
3 1 block bitmap ; карта свободных блоков
4 1 inode bitmap ; карта свободных inode
5 214 inode table ; массив inode (сведения о файлах)
219 7974 data blocks ; блоки данных (файлы, директории)
-- block group 1 -- ; группа блоков 1
8193 1 superblock backup ; копия суперблока
8194 1 group descriptors backup ; копия дескрпиора группы
8195 1 block bitmap ; карта свободных блоков
8196 1 inode bitmap ; карта свободных inode
8197 214 inode table ; массив inode (сведения о файлах)
8408 7974 data blocks ; блоки данных (файлы, директории)
-- block group 2 -- ; группа блоков 2
16385 1 block bitmap ; карта свободных блоков
16386 1 inode bitmap ; карта свободных inode
16387 214 inode table ; массив inode (сведения о файлах)
16601 3879 data blocks ; блоки данных (файлы, директории)
Листинг 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'а полностью разрушена.
Имя файла в 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). Все блоки, принадлежащие файлу, в карте свободного пространства (block bitmap) помечаются как неиспользуемые, после чего данная inod'а так же освобождается (inode bitmap).
Комментариев нет:
Отправить комментарий