предотвратить перезапись его блоков во время попыток восстановления.
Если размонтировать файловую систему не удается (вы получили сообщение «device is busy»), то проверьте, какие процессы к ней обращаются, и прервите их. Это можно сделать с помощью команды
fuser -m <файловая_система>
Если удаленный файл находился на корневой файловой системе, то ее размонтировать нельзя. Вам придется выключить компьютер, извлечь жесткий диск и заняться восстановлением файла на другой Linux-машине. Отсюда мораль: при установке Linux разбивайте жесткий диск так, чтобы файловые системы /usr, /var и особенно /home (те, в которых данные меняются чаще всего) размешались на отдельных разделах.
Linux — тщательно документированная система, и пути решения распространенных проблем описываются в документах HOWTO. Восстановлению файлов посвящено руководство www.tldp.org/HOWTO/Ext2fs-Undeletion.html (его русский перевод можно найти, например, на http://linux.vitebsk.by/howto/Ext2fs-Undeletion.html).
Для восстановления файлов на файловой системе ext2 (не ext3!) разработана утилита e2undel (http://e2undel.sourceforge.net). С ней вы разберетесь сами, а сейчас я скажу пару слов о средствах, входящих в состав обыкновенного дистрибутива.
10.1.1. Midnight Commander
Любимый многими файловый менеджер mc имеет в своем составе средство восстановления файлов, которое иногда может помочь. Запустите mc от имени суперпользователя. Выполните команду меню Команда→Восстановление файлов. Затем введите имя файла устройства, на котором находится нужный раздел, без /dev: например, hda4. Через некоторое время Midnight Commander представит вам список удаленных индексных дескрипторов. Если вы не знаете номер i-узла удаленного файла, вам придется просмотреть их все, чтобы найти нужный вам файл. Но гарантии того, что вы его найдете, нет никакой.
10.1.2. Утилита debugfs
Эта утилита входит в состав пакета e2fsprogs и служит для интерактивного исследования и изменения состояния файловых систем типа ext2 и ext3. Порядок ваших действий будет следующим:
1. Размонтируйте файловую систему с удаленным файлом.
2. Откройте ее в режиме «только чтение»:
debugfs <файл_устройства>
3. В ответ на приглашение введите подкоманду lsdel, чтобы получить список удаленных i-узлов. Попытайтесь определить свой файл по атрибутам: владельцу, размеру, дате удаления и т.п.
4. Сохраните содержимое i-узла в файл на другой файловой системе, введя подкоманду dump <inode> имя_нового_файла. Номер i-узла указывайте в угловых скобках!
5. Выйдите по подкоманде quit.
Список остальных подкоманд debugfs вы можете получить по подкоманде help или узнать на man-странице.
10.2. Стратегия резервного копирования
Чтобы героически спасать файлы приходилось не слишком часто, следует заранее позаботиться об их надежной защите. Важнейшим средством защиты является резервное копирование.
Вам нужно хорошо продумать следующие пункты:
1. Какая информация будет резервироваться (архивироваться)?
В первую очередь вам нужно архивировать данные пользователей, то есть каталог /home. Эти данные относятся к наиболее критичной категории данных. Восстановить систему вы сможете в течение не более чем двух-трех часов, а вот данные пользователей уже не восстановишь… На втором месте — файлы настройки системы, находящиеся в каталоге /etc. Архивирование этих данных позволит существенно сэкономить время, которое вам потребуется на восстановление системы после сбоя.
И, наконец, на третьем месте — дистрибутивы программ, не входящих в состав дистрибутива Linux. Эти данные, как правило, не нуждаются в частом обновлении.
2. Когда будет происходить создание резервных копий?
Самое удачное время для этого мероприятия — ночь. Во-первых, архивирование обычно не требует вмешательства оператора и поэтому его можно выполнять автоматически (п.9.4.2). Во-вторых, оно создает дополнительную нагрузку на систему, чему не обрадуются пользователи. В-третьих, открытые этими пользователями файлы создадут при копировании массу проблем.
3. Кто этим будет заниматься?
Если речь идет о вашем домашнем компьютере, то этой ответственной задачей будете заниматься вы сами. На предприятии (особенно большом) необходимо определить, кто будет архивировать данные с каждого сервера сети: не будете же вы бегать по зданию со стримером, контролируя процесс создания резервных копий? В идеале, за каждым сервером должен быть закреплен человек, ответственный за процесс создания архива и поддержания его в должном состоянии.
4. Как часто будет производиться архивирование?
Дома можно архивировать диск еженедельно и после обширных изменений. На предприятии зарекомендовала себя шестидневная схема. Вам понадобится шесть сменных носителей (кассет для стримера или магнитооптических дисков). В пятницу, после конца рабочей недели, создается резервная копия всего диска на первой ленте. С понедельника по четверг архивируются только новые и обновленные данные (каждый день — на свою ленту), и в следующую пятницу создается новая копия всего диска на шестую ленту. Таким образом, всегда можно восстановить данные на любой день последней недели.
Архивирование только новых данных обычно называется инкрементным. Отбирать файлы, дата последнего изменения которых свежее заданной, умеет архиватор tar (см. man- страницу).
10.3. Оборудование для резервного копирования
При выборе стратегии резервного копирования решающим фактором может оказаться соотношение размера диска и емкости имеющихся у вас внешних носителей. Привычные диски CD-RW вмещают всего 640 Мбайт, поэтому резервирование сколько-нибудь значительного объема данных нельзя организовать автоматически: кто-то должен менять диски вручную. Вот почему стоит обратить внимание на стримеры, позволяющие сохранять от 10 до 100 Гбайт сжатой информации на одном картридже. К тому же UNIX- программы резервного копирования создавались в те времена, когда ленточные накопители были единственным типом внешнего хранилища, и идеально приспособлены к работе с ними.
