СПОСОБ ВОССТАНОВЛЕНИЯ ДАННЫХ В ФАЙЛОВОЙ СИСТЕМЕ EXT4 С ИСПОЛЬЗОВАНИЕМ ИНФОРМАЦИИ ЖУРНАЛА ИЗМЕНЕНИЙ ТОМА

Основная сложность восстановления информации в ext4 связана с тем, что при удалении последней жесткой ссылки на файл драйвер заполняет нулями область индексного узла, где указаны номера кластеров с данными файл [1]. Анализ битовой карты с целью последующего исследования свободных областей памяти на машинном носителе занимает продолжительное время, особенно на накопителях большого объема и RAID-массивах. Для ускорения процесса поиска данных удаленного файлового объекта требуется возможность быстрого обнаружения номеров его кластеров. Ее предоставляет журнал изменений тома — файл, призванный обеспечить отказоустойчивость раздела с точки зрения его логической структуры. Формат журнала и алгоритм его работы не являются закрытыми и описываются на сайте Ext4 Wiki [1]. Алгоритм восстановления информации в комбинации с утилитой для сигнатурного поиска файлов foremost описан в работе [2], однако подобного материала в отношении ext4 не представлено.

Файл журнала (рис. 1) записывается циклично, а информация расположена в блоках различного типа, в результате чего обеспечивается непрерывный контроль над состоянием производимых файловых операций. В связи с тем, что при каждом монтировании раздела для записи данные в журнал начинают записываться с его начала, подключать раздел с целью извлечения содержащейся на нем информации необходимо только в режиме чтения [3, с. 389].

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

Рисунок 1 - Формат журнала файловой системы ext4 [1, 2]

Для большей наглядности рассмотрим пример расположения информации в журнале и поиска состояний индексного узла (inode) удаленного файла на рис. 2.

Рисунок 2 - Пример расположения данных о файловых операциях

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

При использовании предложенного способа сначала нужно извлечь с помощью утилиты dd журнал. Его inode, по умолчанию имеющий номер 8, следует использовать для определения расположения кластеров журнала утилитой debugfs.

Вторым этапом получения содержимого удаленного файла является поиск в журнале его индексного узла, который, например, расположен в кластере 20 после массива описателей 127 (рис. 2).

Далее нужно осуществить поиск и извлечение номеров блоков с данными файла. В связи с тем, что состояние найденного на 2 этапе inode соответствует удаленному файлу, поля с номерами кластеров заполнены нулями [4]. Для того чтобы их обнаружить, необходимо найти этот же узел в ранее описанных в журнале операциях, когда файл еще не был удален, например, в том же кластере с номером 20 после массива описателей 1 (рис. 2). Наличие в журнале нескольких версий двадцатого кластера обусловлено тем, что, помимо индексного узла удаленного файла, в нем могут присутствовать до 15 аналогичных структур, связанных с другими файловыми объектами. Вследствие того, что при изменении любого inode, который расположен в одном кластере с найденным на 2-м этапе индексным узлом, происходит копирование этого блока с данными в журнал, необходимо учитывать, что вероятность нахождения информации, описывающей состояние файла до его удаления, зависит от наличия изменений соседних узлов.

Если информация о предыдущем состоянии inode будет обнаружена в журнале, содержимое кластеров, на которые он указывает, следует скопировать в новый файл с помощью утилиты dd.

Эффективность предложенного способа значительно зависит от интенсивности файловых операций на разделе, при этом наилучшие результаты достигаются при быстром реагировании на удаление важной информации. В ходе проведенного эксперимента установлено, что при удалении файла на рабочей станции запись об этом событии находилась в журнале в течение трех часов, в то же время небольшой Web-сервер, обслуживающий форум, «переписывает» журнал менее чем за 20 минут. К недостаткам описанного способа восстановления можно отнести отсутствие реального имени файлового объекта у извлеченных данных, а также наличие ложных срабатываний при поиске удаленных индексных узлов в содержимом журнала. Среди достоинств способа стоит отметить возможность его полной автоматизации с помощью, например скриптового файла, и необходимость использования всего двух дополнительных утилит (dd и debugfs), которые входят в стандартную поставку большинства дистрибутивов операционных систем на базе ядра Linux.