Как быть с ext3?
Как мы уже упоминали, Linux-драйвер ext3 использует другой механизм разлинковки. Он затирает всю таблицу соответствия в inode, делая процесс восстановления данных чрезвычайно трудным, если не сказать невозможным. Но попробуем мыслить логически. Файл представляет собой последовательность блоков определенного размера, разбросанных по всему жесткому диску. У каждого типа файла есть набор признаков, по которым его можно идентифицировать. Любой медиа-файл (изображение, аудио, видео – неважно) имеет заголовок, в котором в большинстве случаев размещен не только его тип и размер, но и сведения об авторе и времени создания (id3-теги в mp3, например). Текстовые файлы сразу бросаются в глаза, благодаря своему читаемому без специальных средств содержимому. HTML, DOC и другие документы, напичканные высокоуровневыми системами разметки, также имеют заголовок и набор узнаваемых признаков.
Учитывая это, можно смело утверждать, что найти и восстановить удаленный файл на не слишком фрагментированной и захламленной файловой системе возможно даже после полного разрушения ее управляющих структур. В том случае, если файл был записан в непрерывную последовательность блоков, все, что потребуется сделать, - найти усопшего по метаданным (которые будут указывать на его начало), извлечь из них размер файла и вернуть бедолагу к жизни с помощью команды dd.
Однако описанный прием сработает лишь в очень небольшом проценте случаев (например, файл, удаленный на только что созданной ФС). В остальных 99% файл окажется сильно фрагментирован; части убитого будут разбросаны по всей файловой системе, а на сбор их в единое целое придется потратить уйму времени и нервов, а то и вообще смириться с утратой.
Ситуация не была бы столь плачевной, если бы не размеры современных дисков и файловых систем. Дело в том, что метаданные многих типов файлов хранят еще и контрольную сумму самих данных. Для восстановления информации с небольшого носителя начала 90-х мы могли бы воспользоваться знаниями языка Си и написать программу, которая находила бы первый блок файла по его метаданным и определяла размер. А затем просто подбирала остальные свободные блоки файловой системы в надежде составить весь файл, контрольная сумма которого будет правильной. К сожалению, если применить такую программу к современному хранилищу данных, мы дождемся скорее выхода из строя жесткого диска (вследствие износа), чем реинкарнации файла.
Тем не менее небольшие текстовые файлы, такие как базы паролей, легко умещаются в один блок файловой системы, и найти их можно с помощью обычного grep:
# grep -a -B1 -A200 'root:x:0' /dev/sda1
Восстановление супер-блока
В случае повреждения супер-блока драйвер файловой системы откажется примонтировать раздел, а команда e2fsck уверенно скажет, что подсовываемый раздел - это что угодно, только не файловая система ext2. К счастью, копии супер-блока в ext2 и ext3 разбросаны по всему разделу, так что восстановить его не трудно.
Файловые системы ext2 и ext3 используют своего рода мета-блоки (группы блоков), в начале каждого из которых расположена копия супер-блока. Размер мета-блока равен размеру блока файловой системы, умноженному на восемь. Так, первая копия супер-блока в ФС, размер блока которой равен 4 Кб, будет расположена по смещению 4096*8=32768, вторая - 65536 и т.д.
Восстановить супер-блок из копии можно с помощью все той же утилиты e2fsck:
# e2fsck -b 32768 /dev/sda1
Первая копия может оказаться поврежденной. Придется обратиться к следующей, затем еще к одной – до тех пор, пока не будет найдена целая и невредимая копия супер-блока.