Материал из Linuxformat.

Содержание 1 Восстанавливаем удаленные файлы 2 Профилактика лучше лечения 3 Совет 4 Разделиться и выжить 5 Проблеск надежды 6 Поиск файлов, недоступных другим утилитам 7 PhotoRec 8 Ох уж эти отговорки!

Восстанавливаем удаленные файлы

Сослав важный файл в цифровое забвение, не паникуйте. Его можно вернуть.

Задумавшись о том, как мощны и неумолимы команды типа rm *, можно только подивиться тому, как мало файлов я удаляю по ошибке. В этом руководстве мы рассмотрим методы, уменьшающие ущерб от нечаянных удалений файлов. Предполагается, что вы работаете в командной строке: в графических файловых менеджерах обычно есть папка Deleted Items [Удаленные], и вы можете просто выудить удаленные файлы из мусорной корзины.

Профилактика лучше лечения

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

1. Минимизируйте время, которое проводите в системе под пользователем root. При необходимости переключайтесь на него командой su, а после этого сразу возвращайтесь к своему обычному пользователю. Лучше всего запретить вход в систему под пользователем root и выполнять все административные операции через sudo.
2. Создайте псевдоним, который свяжет rm с командой, не удаляющей файлы, а помещающей их в каталог Deleted Files. Очищайте этот каталог ежедневной задачей Cron, удаляющей все ссылки, к которым не было обращений за последние 30 дней.
3. Защитите файлы второй ссылкой. При удалении файла в Linux с помощью rm удаляется лишь ссылка на файл. Если на файл есть другие ссылки, они уцелеют, и файл не исчезнет. Идея состоит в написании небольшого скрипта или функции, под названием, скажем, protect, которую вы вызовете явно, чтобы защитить файл от случайного удаления. Скрипт создаст дополнительную ссылку на файл в заданном каталоге, например, ~/.protected-files. Обратите внимание, что cимвольные ссылки не годятся для этой роли. И это не поможет в том случае, если вы случайно перезапишете файл.
4. Каталог можно защитить от удаления, сняв право на запись в него. Но это «защитит» вас и от создания в директории новых файлов.

Совет

Теперь обсудим методы восстановления файлов. Лучший совет, который я могу здесь дать, безусловно, таков: регулярно делайте резервные копии! Файлы можно копировать на флэшку или на другой компьютер с помощью rsync, писать сжатые архивы на CD или применить средство резервирования корпоративного уровня, типа Amanda или Backup PC. Главное – делать это, и делать постоянно. Проще и надежнее достать файл из резервной копии, чем запускать утилиты восстановления данных.

Разделиться и выжить

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

Проблеск надежды

Но предположим, что, при всей осторожности, вы удалили файл, которого нет в резервной копии. Во-первых, проверьте, нет ли процесса, где этот файл был открыт в момент удаления; если процесс еще выполняется, файл без труда можно восстановить. Почему? Такова особенность Linux (и Unix): если в момент удаления файла его открытый дескриптор принадлежал выполняющемуся процессу, файл продолжит существовать. У него не будет имени, но его индексный дескриптор и данные останутся нетронутыми. (Поэтому, когда вы выполняете ротацию файлов журналов, приходится отправлять сигнал или перезапускать демона, который пишет в журнал, чтобы он закрыл старый файл журнала и открыл новый.)

Чтобы восстановить файл, понадобятся идентификатор процесса, который открыл файл, и дескриптор файла. Потом этот файл можно будет просто скопировать из /proc. Вот пример. Скажем, я запускаю tail -f на файле журнала /var/log/messages и случайно удаляю файл. Следующая команда определит процесс, у которого этот файл еще открыт:

$ lsof | grep /var/log/messages
tail 26246 chris 3r REG 8,3 1783 6342095 /var/log/$ messages (deleted)

Но для всего, кроме процесса tail, этого файла уже не существует.

$ cat /var/log/messages
cat: /var/log/messages: No such file or directory

И вот наш трюк. Зная идентификатор процесса tail (26246) и файловый дескриптор, на котором у процесса еще открыт этот файл (3), мы просто скопируем файл из того дескриптора, который виден в /proc.

$ sudo cp /proc/26246/fd/3 /var/log/messages

Остается только исправить владельца и группу файла, и дело в шляпе.

Если так восстановить файл не получается, нужно как можно скорее перевести систему в однопользовательский режим. Можно также размонтировать файловую систему, содержавшую удаленный файл, или смонтировать ее в режиме только для чтения. Смысл в минимизации риска того, что Linux выделит блоки данных вашего файла для какой-то другой цели. Тогда уж файл точно погиб.

Можно попробовать восстановить данные, просто пройдя командой grep по разделу. Это не так глупо, как кажется. Например, я нарочно удалил файл с этим руководством (ну да, резервную копию-то я приберег) и сумел восстановить его командой:

$ sudo grep -a -A 100 -B 50 ‘MAKE REGULAR BACKUPS!’ /dev/sda2 > /tmp/recovered-file

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

Поиск файлов, недоступных другим утилитам

В поисках более методичных способов восстановления файлов мы найдем массу программ для Windows, но не так много для Linux. Я нашел пару утилит, R-Linux (http://www.data-recovery-software.net) и Easeus (http://www.easeus-linuxrecovery.com). Обе могут восстанавливать удаленные файлы из файловых систем ext2/ext3, но работают только в Windows. Кроме того, существуют «резчики файлов» (file carvers) – программы, использующие известные заголовки и концовки различных типов документов для восстановления файлов на разрушенных или нечаянно отформатированных разделах, а также тех, что были случайно удалены (Заголовки и концовки файлов в данном контексте – по существу последовательности байтов в предсказуемых позициях внутри файла, которые определяют тип файла и позволяют «резчику» определить, где начинается и заканчивается файл). Это область компьютерной «судебной медицины», и многие из таких утилит, например, Unrm и Lazarus (часть The Coroner Toolkit – см. http://www.porcupine.org/forensics/tct.html), Foremost (http://www.forensicswiki.org/wiki/Foremost) и Scalpel (http://www.digitalforensicssolutions.com/Scalpel) используются для раскрытия киберпреступлений.

Я решил попробовать Scalpel. У него есть конфигурационный файл, где определены заголовки и концовки файлов для всех типов файлов. Раскомментировав нужные строки, можно выбрать типы файлов, которые будет искать Scalpel. Для проверки я скопировал PDF-файл на раздел размером 10 ГБ и удалил его (там было много других файлов – раздел был заполнен на 15%).

В файле config я раскомментировал настройки для PDF, оставив остальное без изменений. Запустить Scalpel было нетрудно:

$ sudo scalpel -c /etc/scalpel/scalpel.conf -o scalpeldir /dev/sda2
Scalpel version 1.60
Written by Golden G. Richard III, based on Foremost 0.69.
Opening target “/dev/sda2”
Image file pass 1/2.
/dev/sda2: 100.0% |********************************| 10.0 GB
00:00 ETA
Allocating work queues...
Work queues allocation complete. Building carve lists...
Carve lists built. Workload:
pdf with header “\x25\x50\x44\x46” and footer “\x25\x45\x4f\x46\x0d” - - > 0 files
pdf with header “\x25\x50\x44\x46” and footer “\x25\x45\x4f\x46\x0a” - - > 1 files
Carving files from image.
Image file pass 2/2.
/dev/sda2: 100.0% |********************************| 10.0 GB
00:00 ETA
Processing of image file complete. Cleaning up...
Done.
Scalpel is done, files carved = 1, elapsed = 234 seconds.

Как вы видите по выводу, потребовалось минуты четыре, чтобы просканировать раздел размером 10 ГБ и найти мой (и единственный) PDF-файл, который был сохранен как /scalpeldir/pdf-1-0/00000000.pdf.

PhotoRec

Следует иметь в виду, что некоторые «резчики» найдут все файлы, а не только те, что были удалены. Я также попробовал программу PhotoRec (http://www.cgsecurity.org/wiki/PhotoRec), задуманную как средство для восстановления изображений, удаленных с цифровых камер, но с тех пор она стала понимать и файлы других типов, превратившись в настоящий «резчик». Однако в ней нельзя ограничить перечень типов обнаруживаемых файлов, что приводит к огромному количеству результатов. Так, на моем разделе размером 10 ГБ нашлось 113 200 файлов. Хотя у них остались расширения, означающие тип распознанного файла, имена вроде f9712256.txt делают их по сути безымянными. Поэтому здесь бывает трудно отличить цифровые зерна от плевел.

Ох уж эти отговорки!

Краткий период своей жизни я работал менеджером по продукции в известной компании, занимающейся обучением в сфере ИТ. В мои функции входило управление авторами курсов, когда они сдавали свои новые материалы и ежегодные редакции. Приближающиеся сроки сдачи напрягали многих авторов, и я был в восторге от гаммы происшествий, регулярно приводивших к потере данных. «В мой компьютер ударила молния». «Я забыл свой ноутбук в метро». «Я думал, что уже отправил их, и удалил оригиналы». И мое любимое: «Мой двухлетний сын уронил жесткий диск в унитаз».