Проверка ФС ext2/ext3/ext4 при помощи e2fsck
Утилита e2fsck является потомком известной UNIX-утилиты fsck, предназначенной для проверки файловых систем. При помощи e2fsck вы можете проверять на наличие ошибок и выполнять восстановительные работы в файловых системах ext2/ext3/ext4.
Одним из наиболее важных моментов в работе с e2fsck является то, что при помощи неё работы можно проводить только на отмонтированной файловой системе, в противном случае вы можете получить себе ещё больше головной боли, о чём и предупреждает сама утилита при попытке запуска её для работы на смонтированной ФС. Если проверяемая ФС не является корневой, то вы можете завершить работу всех пользователей, переключиться в однопользовательский режим (init 1), отмонтировать ФС и работать с ней.
Однако автор всё же рекомендует воспользоваться каким-нибудь live-дистрибутивом и, загрузившись с него, выполнять все работы. Используя этот метод вы получите в своё полное распоряжение несмонтированные ФС без необходимости выполнять какие-то дополнительные действия.
Если же вы по каким-то причинам выбираете первый вариант, то после того, как перейдёте в однопользовательский режим:
# init 1
отмонтируйте нужную для работы файловую систему:
# umount /dev/sdb1
и после успешного размонтирования запускайте e2fsck:
# e2fsck -y /dev/sdb1
Опция '-y' сообщает утилите e2fsck о том, что мы заранее согласны со всеми её вопросами и уходим пить кофе, в надежде что она самостоятельно всё сделает. В зависимости от размера файловой системы проверка и восстановление могут занять некоторое время. После окончания проверки вы всегда можете запустить тест ещё раз, чтобы убедиться в том, что не в ФС не возникло новых ошибок, что может быть вызвано аппаратными проблемами накопителя.
После того, как все проверки и восстановительные работы будут закончены, вы можете смонтировать проверенную файловую систему и обратно вернуться в много пользовательский режим. Или же вы просто можете перезагрузить систему.
Восстановление удалённых файлов при помощи /proc и lsof
Теперь давайте рассмотрим процесс восстановления удалённых файлов. Вообще, причиной тому что вы можете восстановить удалённый файл является тот факт, что «файл» — это лишь ссылка на индексный дескриптор файла (inode). Именно в inode хранится информация о физическом размещении файла. Когда вы удаляете файл, фактически вы просто удаляете ссылку на inode, в то время как сам дескриптор ещё какое-то время будет существовать: до тех пор, пока процесс, ранее открывший этот файл не освободит соответствующий дескриптор для записи. Таким образом, есть какое-то время, пусть и короткое, в течение которого можно восстановить содержимое удалённого файла. Ключом в этом процессе является файловая система /proc, содержащая среди всего прочего информацию обо всех выполняющихся в системе процессах и открытых ими файлах. Каждый процесс, работающий в системе имеет соответствующий его PID каталог в /proc. Зная PID процесса, всё ещё держащего открытым удалённый файл, мы всегда можем восстановить его содержимое из каталога /proc/[pid]/ открывшего его процесса. Давайте на простом примере посмотрим, как это делается.
Сперва давайте создадим какой-нибудь файл:
$ echo 'Очень важные данные' > ~/myfile.txt
Теперь у нас есть файл myfile.txt с важными данными, расположенный в домашнем каталоге. Давайте попробуем удалить его и затем восстановить следующим образом. Сначала мы откроем файл для просмотра командой less, после чего приостановим её работу, оставив таким образом нужный нам файл открытым. Итак, пошагово.
Откройте файл командой less для просмотра
$ less ~/myfile.txt
После того, как файл будет открыт и вы увидите его содержимое, нажмите Ctrl+z , чтобы приостановить выполнение less.
Удалите файл:
$ rm ~/myfile.txt
Убедитесь в том, что файла больше нет
$ ls -l ~/myfile.txt
Поскольку работа ранее запущенной нами less ещё не завершена, то файл остаётся для неё открытым и фактически не удалён. Давайте восстановим его.
Для начала необходимо узнать PID процесса, открывшего файл и номер файлового дескриптора. Сделать это можно при помощи программы lsof:
$ lsof | grep myfile.txt
less 2675 ashep 4r REG 8,1 37 294478 /home/ashep/myfile.txt (deleted)
Во втором поле вывода lsof содержится PID — 2675, а в четвёртом номер дескриптора — 4. Теперь можно приступать к восстановлению:
$ cp /proc/2675/fd/4 ~/recovered.txt
Проверьте, то ли содержимое находится в файле, которое нам нужно:
$ cat ~/recovered.txt
Очень важные данные
Как видим, всё прошло успешно и нам удалось восстановить удалённый файл.
Восстановление удалённых файлов при помощи Scalpel
После того как процесс, открывший файл, завершится, восстановление файла становится задачей потруднее, поскольку индексный дескриптор освобождается и всякая связь между данными в блоках на диске и файловой системой потеряна. До тех пор, пока данные физически не будут перезаписаны на диске, существует возможность их восстановления при помощи утилиты Scalpel. Этот инструмент последовательно, блока за блоком, обходит содержимое диска и анализирует его содержимое, пытаясь найти признаки существования там файлов. Для поиска Scalpel использует шаблоны из последовательности байт, присущих определённым типам файлов. Например, PNG-файлы содержат в заголовке последовательность байт \x50\x4e\x47.
Scalpel вы найдёте в репозиториях большинства современных дистрибутивов. После установки утилиты первым делом нужно определиться с тем, какие файлы программа будет искать при работе. Определения шаблонов для поиска находятся в файле/etc/scalpel/scalpel.conf. По умолчанию содержимое файла целиком закомментировано и прежде чем начать работу вам необходимо раскомментировать нужные шаблоны и/или добавить свои. Формат описания шаблона довольно прост:
extension case_sensitive size header [footer]
где
- extension определяет расширение файла, которое Scalpel будет дописывать при восстановлении;
- case_sensitive указывает утилите, имеет ли значение регистр символов в шаблоне поиска;
- при помощи size определяется максимальный размер восстанавливаемых файлов;
- в header и необязательном footer описываются последовательности заголовка файла и нижней его части соответственно.
Например, определение шаблона для JPG-файлов может выглядеть так:
jpg y 200000000 \xff\xd8\xff\xe0\x00\x10 \xff\xd9
После того, как внесёте необходимые изменения в конфигурационный файл Scalpel и подготовите пустую (обязательно!) директорию для сохранения найденных файлов, можно запускать процесс поиска и восстановления:
# scalpel -o ~/recovered /dev/sdb1
где при помощи опции '-o' определяется путь к каталогу для сохранения найденных файлов. Процесс работы утилиты как правило очень долгий, поскольку она сканирует всё устройство целиком, поэтому воспользуйтесь моментом и сходите прогуляться на улицу, свежий воздух ещё никому не мешал ;)
После того, как Scalpel завершит свою работу, изучите содержимое выходного каталога на предмет наличия в нём нужных вам файлов.
Заключение
Мало кто хотел бы попасть в ситуацию, когда важные данные окажутся случайно удалёнными или повреждёнными. И хотя Linux предлагает средства для восстановления утраченных данных, приятного в этом процессе мало. Поэтому будьте всегда предельно внимательны к своим данным и работе с ними. Ну и, конечно же, не забывайте про своевременное резервное копирование — старый и проверенный метод, спасший не одну тысячу нервных клеток от верной гибели.
По материалам с linux.com
